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

[Anup Patel <Anup.Patel@wdc.com>]

> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org <linux-kernel-
> owner@vger.kernel.org> On Behalf Of Troy Benjegerdes
> Sent: Wednesday, August 21, 2019 11:25 PM
> To: Atish Patra <Atish.Patra@wdc.com>
> Cc: hch@lst.de; paul.walmsley@sifive.com; linux-riscv@lists.infradead.org;
> Damien Le Moal <Damien.LeMoal@wdc.com>; linux-
> kernel@vger.kernel.org; palmer@sifive.com
> Subject: Re: [PATCH 15/15] riscv: disable the EFI PECOFF header for M-mode
> 
> 
> 
> > On Aug 21, 2019, at 10:31 AM, Atish Patra <Atish.Patra@wdc.com> wrote:
> >
> > On Tue, 2019-08-20 at 21:14 -0700, Troy Benjegerdes wrote:
> >>> On Aug 13, 2019, at 8:47 AM, Christoph Hellwig <hch@lst.de> 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.

I don't see why these things cannot be achieved in existing open-source
bootloaders. In fact, U-boot already has "Falcon" mode for fast booting.

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

For security, we have to get SW certified with various something like ISO2626
standard. This is very common practice in Automotive industry. To achieve such
a certification for any SW, the size of code base is very very important.

Due to this reason, even today Linux (and other big open-source project)
are very difficult to be security certified.

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

I don't by this last argument. These days it's just very few folks doing firmware,
bootloader, and Linux porting for any new SOC (any architecture). Most of
the things are already there in various open-source project so same person
can easily contribute to various projects.

Regards,
Anup