barebox hooks in userspace

barebox hooks in userspace

[Gerz Burak LCPF-CH]

Hi

I'm thinking of integrating something like a very simple "hook executer" in barebox - so that it can execute scripts which live in the rootfs.
This would facilitate updating the barebox hooks by a simple RAUC rootfs update.
Since I have an A/B setup, I do not know which partition will be booted by barebox beforehand - so currently I just execute all scripts twice

e.g, I have:

/defaultenv/defaultenv-2-base/init/zzbarebox-hook-exec
@@ -0,0 +1,18 @@
#!/bin/sh

#Execute all scripts found
#TODO: Get next boot target from bootchooser and execute scripts located
#      only on one target

SYSTEM0=${bootsource}${bootsource_instance}.0
SYSTEM1=${bootsource}${bootsource_instance}.1

HOOKS_DIR=boot/barebox-hooks/

for i in /mnt/$SYSTEM0/$HOOKS_DIR/*; do
        . $i
done

for i in /mnt/$SYSTEM1/$HOOKS_DIR/*; do
        . $i
done

I see that bootchooser -i prints the next to be booted system:
barebox@Juno phyCORE-i.MX6 ULL eMMC SOM:/ bootchooser -i
Good targets (first will be booted next):
system0
...


My Question:
Would it make sense to extend the bootchooser command, e.g. with bootchooser -n (get and store next boot target in a global variable), so that it can be used by the hush shell?

Regards

Re: barebox hooks in userspace

[Sascha Hauer]

On Mon, Dec 05, 2022 at 04:34:55PM +0000, Gerz Burak LCPF-CH wrote:
> Hi
> 
> I'm thinking of integrating something like a very simple "hook executer" in barebox - so that it can execute scripts which live in the rootfs.
> This would facilitate updating the barebox hooks by a simple RAUC rootfs update.
> Since I have an A/B setup, I do not know which partition will be booted by barebox beforehand - so currently I just execute all scripts twice
> 
> e.g, I have:
> 
> /defaultenv/defaultenv-2-base/init/zzbarebox-hook-exec
> @@ -0,0 +1,18 @@
> #!/bin/sh
> 
> #Execute all scripts found
> #TODO: Get next boot target from bootchooser and execute scripts located
> #      only on one target
> 
> SYSTEM0=${bootsource}${bootsource_instance}.0
> SYSTEM1=${bootsource}${bootsource_instance}.1
> 
> HOOKS_DIR=boot/barebox-hooks/
> 
> for i in /mnt/$SYSTEM0/$HOOKS_DIR/*; do
>         . $i
> done
> 
> for i in /mnt/$SYSTEM1/$HOOKS_DIR/*; do
>         . $i
> done
> 
> I see that bootchooser -i prints the next to be booted system:
> barebox@Juno phyCORE-i.MX6 ULL eMMC SOM:/ bootchooser -i
> Good targets (first will be booted next):
> system0
> ...
> 
> 
> My Question:
> Would it make sense to extend the bootchooser command, e.g. with
> bootchooser -n (get and store next boot target in a global variable),
> so that it can be used by the hush shell?

When do you want to execute the scripts? When you want to execute them
during booting then I think we'll find a better way for this. When you
want to execute them at barebox init time then the way you describe
sounds good to me.

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: barebox hooks in userspace

[Trent Piepho]

On Mon, Dec 5, 2022 at 11:19 PM Sascha Hauer <sha@pengutronix.de> wrote:
>
> When do you want to execute the scripts? When you want to execute them
> during booting then I think we'll find a better way for this.

Section in FIT image containing scripts to run at boot?  That way they
are linked to updates to the kernel, which should already be linked to
rootfs if there are any modules.  FIT image already has a way to store
multiple kernels/devicetrees/etc for different hardware variants and
boot types (normal, recovery), which is probably useful.  FIT image
already has a system for hashes and signatures.  If one cares about
security, then this is very important for any scripts run by the
bootloader.  I think most U-Boot style boots with partition switching
done by changing the boot scripts stored in an unsigned environment
sector have a massive security hole here.

There's a problem that can happen when the interface between the
bootloader and the kernel/rootfs change.  E.g., the kernel command
line arguments change for a new kernel.  One needs to update the
scripts that create those arguments in Barebox.  Having RAUC update
Barebox is easy and solves that.  But what if there is a fallback to
the previous A/B partition?  Then one gets a new Barebox + new kernel
command line trying to boot an old kernel.  If one has not been
careful to make the changes to the kernel command line backward
compatible then the old kernel might not boot.

Putting the scripts in the FIT image would be a way to tie them to the
kernel rather than to the bootloader.