U-Boot environment management from userspace

U-Boot environment management from userspace

[Vernon Mauery]

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@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

Re: 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@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

Re: U-Boot environment management from userspace

[Adriana Kobylak]

> Am I the only one that has a need for this or is there a wider
> audience that would benefit?

The software manager (phosphor-bmc-code-mgmt) relies on U-Boot 
environment
variables for managing the images like for determining which image to 
boot
from.

> 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@foo=bar.service. This would require some fancy
> parameter encoding to make it all work correctly to avoid string
> injections.

Yeah, we went that route with an obmc-flash-bmc-setenv@.service[1], with
like you mentioned uses some 'fancy parameter encoding', ex:
"obmc-flash-bmc-setenv@" + entryId + "\\x3d" + std::to_string(value) + 
".service";

This has worked so far but I'd be open on having a mapping of the env
variables to D-Bus properties.

> 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're actually reading the mtd device to get the values of the variables
to avoid having a 'system' or 'fork/exec' call, then we put those values
in D-Bus properties under the software/ path. Having some other app do 
that
parsing would be nice especially if we're to expand the use of the 
U-Boot
env vars.

---
[1] 
https://github.com/openbmc/phosphor-bmc-code-mgmt/blob/master/obmc-flash-bmc-setenv%40.service

Re: U-Boot environment management from userspace

[Vernon Mauery]

On 29-May-2019 10:30 AM, Adriana Kobylak wrote:
>>Am I the only one that has a need for this or is there a wider
>>audience that would benefit?
>
>The software manager (phosphor-bmc-code-mgmt) relies on U-Boot 
>environment
>variables for managing the images like for determining which image to 
>boot
>from.
>
>>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@foo=bar.service. This would require some fancy
>>parameter encoding to make it all work correctly to avoid string
>>injections.
>
>Yeah, we went that route with an obmc-flash-bmc-setenv@.service[1], with
>like you mentioned uses some 'fancy parameter encoding', ex:
>"obmc-flash-bmc-setenv@" + entryId + "\\x3d" + std::to_string(value) + 
>".service";
>
>This has worked so far but I'd be open on having a mapping of the env
>variables to D-Bus properties.
>
>>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're actually reading the mtd device to get the values of the variables
>to avoid having a 'system' or 'fork/exec' call, then we put those values
>in D-Bus properties under the software/ path. Having some other app do 
>that
>parsing would be nice especially if we're to expand the use of the 
>U-Boot
>env vars.
>
>---
>[1] https://github.com/openbmc/phosphor-bmc-code-mgmt/blob/master/obmc-flash-bmc-setenv%40.service
>
>

Brad,

It sounds like Intel is not the only ones that might benefit from a 
service like this, so it might be a good time for a new project/repo. 

Could you create a new repo for us: phosphor-u-boot-env-mgr

--Vernon

Re: U-Boot environment management from userspace

[Ed Tanous]

On 5/28/19 11:40 AM, Vernon Mauery wrote:
> 
> 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.

This would be my preference.  It keeps the functionality self contained,
and allows at least some security around adjusting parameters, given
that said daemon could whitelist/blacklist certain parameters at some
point in the future.

Re: U-Boot environment management from userspace

[Joel Stanley]

On Tue, 28 May 2019 at 18:41, Vernon Mauery
<vernon.mauery@linux.intel.com> 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.

I came across libubootenv the other day. Whatever solution you come up
with to manage the variables could use this library. It's in
tools/env/ in the u-boot sources.

I would caution against the u-boot environment being used as a general
purpose settings store. We should use it for configuring u-boot, and
keep other settings somewhere else in the system.

Cheers,

Joel

Re: U-Boot environment management from userspace

[Brad Bishop]

Hi Vernon

> Brad,
> 
> It sounds like Intel is not the only ones that might benefit from a 
> service like this, so it might be a good time for a new
> project/repo. 
> 
> Could you create a new repo for us: phosphor-u-boot-env-mgr

Will do.

It sounds like you are working on something that needs a new repo, will
generate a new dbus API and have applications providing and consuming
that API.  That sounds like a non-trivial enhancement to OpenBMC.

Please consider having someone submit a completed design template and
opening a github issue.  This enables the rest of the community to know
what Intel is working on and when, and thus have input, possibly help,
and avoid duplicate work.  Please let me know if any of my thinking
here is flawed.

thx - brad

Re: U-Boot environment management from userspace

[krtaylor]

On 6/5/19 7:35 AM, Brad Bishop wrote:
> Hi Vernon
> 
>> Brad,
>>
>> It sounds like Intel is not the only ones that might benefit from a
>> service like this, so it might be a good time for a new
>> project/repo.
>>
>> Could you create a new repo for us: phosphor-u-boot-env-mgr
> 
> Will do.
> 
> It sounds like you are working on something that needs a new repo, will
> generate a new dbus API and have applications providing and consuming
> that API.  That sounds like a non-trivial enhancement to OpenBMC.

Yes. Non trivial changes require designs.

> Please consider having someone submit a completed design template and
> opening a github issue.  This enables the rest of the community to know
> what Intel is working on and when, and thus have input, possibly help,
> and avoid duplicate work.  Please let me know if any of my thinking
> here is flawed.

Not flawed at all. It has been discussed and agreed upon by all 
participating companies. It also greatly reduces the review time for new 
features being contributed, because the community already knows what to 
expect.

Kurt Taylor (krtaylor)

> 
> thx - brad
> 

Re: U-Boot environment management from userspace

[Brad Bishop]

On Wed, Jun 05, 2019 at 08:35:16AM -0400, Brad Bishop wrote:
>Hi Vernon
>
>> Brad,
>>
>> It sounds like Intel is not the only ones that might benefit from a
>> service like this, so it might be a good time for a new
>> project/repo.
>>
>> Could you create a new repo for us: phosphor-u-boot-env-mgr
>
>Will do.
>
>It sounds like you are working on something that needs a new repo, will
>generate a new dbus API and have applications providing and consuming
>that API.  That sounds like a non-trivial enhancement to OpenBMC.
>
>Please consider having someone submit a completed design template and
>opening a github issue.  This enables the rest of the community to know
>what Intel is working on and when, and thus have input, possibly help,
>and avoid duplicate work.  Please let me know if any of my thinking
>here is flawed.
>
>thx - brad

Hi Vernon

I created this today.

I would still love to hear about what Intel is cooking up that would 
make use of this.

Thanks! - brad