[PATCH openbmc 30/32] init: Add a hook to download files

[Andrew Jeffery]

On Mon, 2016-03-07 at 11:03 +1030, Joel Stanley wrote:
> On Sat, Mar 5, 2016 at 11:00 PM, OpenBMC Patches
> <openbmc-patches at stwcx.xyz> wrote:
> > From: "Milton D. Miller II" <miltonm at us.ibm.com>
> >
> > Add a hook to run a shell command line that is stored in a u-boot
> > environment variable.  Only execute this command if the previously
> > established options file has a keyword trigger.  Do not even consider
> > the option if a build option flag is not set to y.
> 
> This patch should not be merged. It creates a worrying backdoor into
> our system where the boot process will run arbitrary commands from
> untrusted u-boot variables.

+1

> 
> If we need to set state in u-boot in order to trigger an update, then
> I can imagine we might allow a flag to be set that says "do_update=1",
> and the system can pick up on this and grab updates from it's
> configured update source.

+1

However, how should we define the update source? Is burning it into the
current boot environment too restrictive? Can we make it less
restrictive but not go as far as arbitrary command execution? I take it
there's something driving the inclusion of a automated network-fetch
-and-update-at-init feature for it to be included at all? We can
already update the partitions during shutdown, and if we boot from the
flash to trigger this process then we won't be running an updated
kernel or initrd until the following reboot, right? I guess it does
avoid multiple reboots to, say, resolve a kernel bug and then update
the remaining partitions (i.e. update the kernel/initrd at shutdown,
update the remainder at init), but I don't think that's worth executing
arbitrary untrusted commands if it's the only use-case.

Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20160307/97f7da20/attachment.sig>