[U-Boot] Distro bootcmd: Re: 5.2-rc1 boot on Unleashed

[Troy Benjegerdes]

> On Jun 3, 2019, at 12:02 PM, Tom Rini <trini at konsulko.com> wrote:
> 
> On Mon, Jun 03, 2019 at 09:44:28AM -0500, Troy Benjegerdes wrote:
>> 
>> 
>>> On Jun 3, 2019, at 5:49 AM, Andreas Schwab <schwab at suse.de> wrote:
>>> 
>>> On Mai 29 2019, Karsten Merker <merker at debian.org> wrote:
>>> 
>>>> Mainline U-Boot already uses the distro bootcmd environment for
>>>> the qemu "virt" machine and it works well.
>>> 
>>> The distro_bootcmd doesn't work for the sifive platform yet because it
>>> doesn't set the correct MAC address for booting.
>>> 
>>> Andreas.
>>> 
>> 
>> Before we go an use distro_bootcmd and drag in a bunch of legacy stuff 
>> we really should not be using, can we make some kind of effort to decide
>> what the design goals and boot flow should look like instead using the 
>> default legacy behavior of a bunch of hard to read and maintain CPP
>> macros?
> 
> I feel like you're calling "what everyone agreed on and uses today"
> legacy just because it already exists.  It is a bit complex because
> devices are so complex, rather than it having to support one-off
> situations or similar things people usually call "legacy”.

My biggest complaint is all the CPP macros, which are really hard to
maintain and read.

I should probably be more careful to quantify ‘legacy’ much more
specifically as “legacy proprietary ROM code”. Or maybe that’s not 
the right term at all

For the first time I know of, we have a (mostly) blank slate to write
the ROM boot code to help manage boot complexity. So I’d like to
make sure we can tease out all the reasons we have all this important
logic and knowledge tied up in a single header file, and at least
re-examine is there a better way to do this than abusing CPP.

> 
>> The first thing I notice is that the default dhcp target is ‘boot.scr.uimg’.
>> 
>> What good does it do linux distros on RiscV to keep using the old boot
>> script format, rather than just load a text file and use ‘env import’? Is there
>> some benefit to this? Do we gain something from the .scr format, like
>> maybe cryptographic signature support?
> 
> Writing things out in script format ends up being more natural (and
> easier to understand) than writing things out in environment format.
> This is why while I wish the "uEnv.txt" hook had become more popular and
> widely used, at this point I also understand why it wasn't.  Doing
> a=foo
> b=bar
> c=baz
> magic_name=do this;do that
> 
> Was not easier nor more understandable than:
> setenv a foo
> setenv b bar
> setenv c baz
> do this; do that

uEnv has the significant user experience advantage of being editable with
a plain old text editor, which is why I used it in freedom-u-sdk. If we can get
a ’script’ format that can be edited by a non-technical user on a windows or
mac box without requiring mkimage, then we have an improvement. Can
this be done with .scr currently?

> 
>> How do we want to support secure boot into Debian, Fedora, and Suse,
>> and does distro_bootcmd have a way to do this, or can we come up with
>> some improvement that doesn’t depend on trying to do all the work in
>> CPP macros and U-boot runtime scripts?
> 
> I think the general answer about "secure boot" is that distros want
> "UEFI secure boot".  And I want to make sure that's done in such a way
> that things like user-owned secure boot aren't any more difficult than
> vendor secured boot.  It seems like making use of existing secure boot
> mechanisms has set aside as, well, I don't want to throw snark around
> myself, so I'll refrain from speculating.
> 
> -- 
> Tom

The problematic issue with ‘user-owned secure boot’ is it’s never been a
major ‘business critical’ need, so it’s always ended up lower on the priority
list from anyone who’s looking at what their clients are paying for.

Now on that note, I think maybe the best way to approach this is to start
with a clear community consensus that we MUST support a user experience
where an end-user with an open RiscV device MUST be able to edit the
boot parameters (boot script? uEnv.txt?), and then be able to resign the
script with their key(s), so the system can boot and maintain a secured 
state when it gets to userspace where we are running distro-signed
binaries.

I honestly don’t know of anyone that’s really looked at this in a commercial
setting other than maybe purism, and they are a pretty niche vendor, and
stuck with a lot of x86 legacy to deal with.