GNUtoo has quit [Remote host closed the connection]
GNUtoo has joined #u-boot
__ad has quit [Read error: Connection reset by peer]
ad__ has joined #u-boot
mmu_man has quit [Ping timeout: 240 seconds]
persmule has quit [Remote host closed the connection]
torez has joined #u-boot
mmu_man has joined #u-boot
prabhakarlad has quit [Quit: Client closed]
<Jacmet>
maybe an odd question, but what is the "normal way to use boot scripts with signed boot (FIT_SIGNATURE)?
<Jacmet>
the source command doesn't work very well with required = "conf" for signed configuration like you would normally use for the FIT images
prabhakarlad has joined #u-boot
<Jacmet>
the "nicest" interface would IMHO to bundle the script in the FIT image and then verity and source it as part of bootm (E.G. list it in the configuration). This can be done by abusing the "loadables" functionality by adding a handler for a "script" loadables in my board code, but it would be nicer to have something like that working out of the box - E.G. http://paste.debian.net/hidden/1ce2c324/
<Jacmet>
am I missing some generic infrastructure for this somewhere?
persmule has joined #u-boot
torez has quit [Quit: torez]
ikarso has quit [Quit: Connection closed for inactivity]
<cambrian_invader>
Jacmet: I have a patch for that
umbramalison has quit [Quit: %So long and thanks for all the fish%]
<cambrian_invader>
but at the moment there's not an easy way to do this
umbramalison has joined #u-boot
<Jacmet>
cambrian_invader: OK, so that solves the config vs images issue. To connect that to bootm you would end your script with bootm $somevar rather than triggering the script from bootm like I do?
<Jacmet>
cambrian_invader: my patch above is really trivial, but it is a bit annoying that a patch is needed
<cambrian_invader>
I think you can just run `bootm`
<cambrian_invader>
if you load your combined image/script to $loadaddr
<cambrian_invader>
actually, I think I have a similar use case to yours
<cambrian_invader>
I use a script to load dm-verity parameters
<Jacmet>
cambrian_invader: yes, me too
<Jacmet>
with the above patch
<Jacmet>
E.G. just embed a script that sets up bootargs with dm-mod.create= based on the A/B mode
<cambrian_invader>
I use a separate image to avoid circular dependencies
<Jacmet>
cambrian_invader: sorry, what do you mean?
<cambrian_invader>
although I originally intended to do everything in one image
<Jacmet>
the FIT image is signed and "binds" to a rootfs through dm-verity. The FIT image is created after the kernel and rootfs are built
<cambrian_invader>
yeah, but it's easier in yocto
<Jacmet>
I'm a Buildroot guy ;)
<Jacmet>
but ok, if it is a single FIT image or 2 doesn't change things a lot
<Jacmet>
1 file is just a bit simpler
<qschulz>
Jacmet: if I remember correctly how I did it years ago, source was working on images inside a fitImage
<qschulz>
so if you sign the image within the fitImage, it should be fine?
<qschulz>
that would mean a call to source before a call to bootm
<Jacmet>
qschulz: yes, source is working, but it uses /images/$foo, so it doesn't work very well with FIT_SIGNATURE and signed configuration rather than signed images
<Jacmet>
qschulz: so to have both then you need to add two certs in your control dtb, one with required = "conf" and one with required = "images" and sign both the images and the configuration, and you pay the RSA overhead twice (for source and for bootm), so it isn't really great
<Jacmet>
qschulz: referencing the source from the config would be a lot nicer as it would then be verified together with the kernel/dtb/initramfs/..
<qschulz>
Jacmet: I guess you could have this exact code in boot/image-board.c yes? register a handler for the script type in there
<qschulz>
you could also manually call the function instead of relying on the handler logic since anyways it should always be called if there is a loadable of type script to be loaded
<Jacmet>
qschulz: indeed, if that is the way we want to handle it
<Jacmet>
qschulz: doing it through the handlers means no extra explicit code, which is IMHO nice
<qschulz>
yes but somewhat hidden/non-obvious logic for something that is always called, makes debugging a bit harder
<qschulz>
Jacmet: I can anticipate maintianers will want a unit test for that BTW :)
<Jacmet>
qschulz: sure, and documentation ;)
guillaume_g has quit [Quit: Konversation terminated!]
<Jacmet>
cambrian_invader: as you are also using dm-mod.create= to setup dm-verity, did you run into issues with it getting configured before the underlying block device is available (E.G. mmc/usb/.. gets probed asynchronously)
<cambrian_invader>
yes
<cambrian_invader>
I found a kludge for it, let me dig it up