U-Boot environment management from userspace

[Thomaiyar, Richard Marian]

Vernon,

I just started a daemon for the same as i needed it for RestrictionMode 
(provisioning) . At this point of time, the daemon uses the fw_setenv & 
printenv internally, but atleast application will access the same in D-Bus

Regards,

Richard

On 5/29/2019 12:10 AM, Vernon Mauery wrote:
> Reading U-Boot environment variables from userspace is not difficult, 
> but to do it in a standard way, (fw_printenv), it requires a fork and 
> exec. We don't have any permissions problems because reading from the 
> MTD partition is not restricted. It might be nice, however to have 
> these variables exported on D-Bus so that a fork/exec is not 
> necessary, just a property fetch.
>
> But writing is a different story. That requires root privileges. To 
> architect with a separation of privileges mechanism, this should 
> probably be running as a daemon or service that could be spawned via 
> D-Bus or something so that ipmid doesn't need root permission to set a 
> U-Boot variable.
>
> I see a couple of options:
> 1) Shoehorn U-Boot variables into the settings daemon so they just 
> show up as settings. I am not sure on the details of how this would be 
> done, but it might work.
>
> 2) Create yet another daemon that would provide a R/W interface 
> (probably just using the D-Bus properties interface) that would act as 
> a manager of U-Boot environment variables. It might even be able to 
> place an inotify watch to get notified when an external process 
> (fw_setenv) modifies the environment (like from a script or something) 
> so the D-Bus properties could send out a PropertiesChanged notification.
>
> 3) Use a one-shot service that parses the 'instance' to extract a 
> variable name and variable value. Then the variable could be activated 
> by launching ubootenv at foo=bar.service. This would require some fancy 
> parameter encoding to make it all work correctly to avoid string 
> injections.
> Am I the only one that has a need for this or is there a wider 
> audience that would benefit?
>
> Does anyone else already have a solution for this or an opinion on 
> what path might be the best?
>
> --Vernon