Re: [PATCH 15/15] riscv: disable the EFI PECOFF header for M-mode

[Troy Benjegerdes]

> On Aug 21, 2019, at 10:31 AM, Atish Patra <Atish.Patra@xxxxxxx> wrote:
> 
> On Tue, 2019-08-20 at 21:14 -0700, Troy Benjegerdes wrote:
>>> On Aug 13, 2019, at 8:47 AM, Christoph Hellwig <hch@xxxxxx> wrote:
>>> 
>>> No point in bloating the kernel image with a bootloader header if
>>> we run bare metal.
>> 
>> I would say the same for S-mode. EFI booting should be an option, not
>> a requirement. 
> 
> EFI booting is never a requirement on any board. When EFI stub will be
> added for kernel, it will be enabled with CONFIG_EFI_STUB only. 
> 
> The current additional header is only 64 bytes and also required for
> booti in U-boot. So it shouldn't disabled for S-mode.
> 
> Disabling it for M-Mode Linux is okay because of memory constraint and
> M-Mode linux won't use U-boot anyways.
> 
>> I have M-mode U-boot working with bootelf to start BBL,
>> and at some point, Iâm hoping we can have a M-mode linux kernel be
>> the SBI provider for S-mode kernels, 
> 
> Why do you want bloat a M-Mode software with Linux just for SBI
> implementation?
> 
> Using Linux as a last stage boot loader i.e. LinuxBoot may make sense
> though.
> 

Boot time, and ease of development, and simplified system management.

Having M-mode linux as a supervisor/boot kernel can get us to responding
to HTTPS/SSH/etc requests within seconds of power-on, while the âbootâ
kernel can be loading guest S-mode kernels from things like NVME flash
drives that are going to be a lot more code and development to support in
U-boot or any other non-linux dedicated boot loader.

Thereâs also a very strong security argument, as Linux is going to get the
largest and broadest security review, and will likely get software updates
a lot faster than dedicated boot firmwares will.

Another reason would be sharing the same kernel binary (elf file) for both
M-mode, and S-mode, and using the device tree passed to each to specify
which mode it should be running it. There are probably a bunch of gotchas
with this idea, and even so I suspect someone will decide to go ahead and
just do it eventually because it could make testing, validation, and security
updates a lot easier from an operational/deployment point of view.

Linuxbios convinced me that if you want to do a really large cluster,
you can build, manage, and run such a thing with fewer people and
engineering cost than if you have all these extra layers of boot firmware
that require some company to have firmware engineers and lots of extra
system testing on the firmware.