On Jun 3, 2019, at 12:02 PM, Tom Rini trini@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@suse.de wrote:
On Mai 29 2019, Karsten Merker merker@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.