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

From: Troy Benjegerdes <troy.benjegerdes@sifive.com>
To: Anup Patel <Anup.Patel@wdc.com>
Cc: Damien Le Moal <Damien.LeMoal@wdc.com>,
	"palmer@sifive.com" <palmer@sifive.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Atish Patra <Atish.Patra@wdc.com>,
	"paul.walmsley@sifive.com" <paul.walmsley@sifive.com>,
	"linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>, "hch@lst.de" <hch@lst.de>
Subject: Re: [PATCH 15/15] riscv: disable the EFI PECOFF header for M-mode
Date: Wed, 21 Aug 2019 16:32:58 -0700	[thread overview]
Message-ID: <CCBE0CC0-76B2-415B-B987-0110F3CBEE70@sifive.com> (raw)
In-Reply-To: <MN2PR04MB6061794D39900E038F9FCF218DAA0@MN2PR04MB6061.namprd04.prod.outlook.com>

> On Aug 21, 2019, at 4:02 PM, Anup Patel <Anup.Patel@wdc.com> wrote:
> 
> 
> 
>> -----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.

There’s security certified, and then there’s what I personally consider secure.

The second category is code that I know is widely audited by lots of people,
and gets quickly updated when there is a problem. I like U-boot, and I think
its a great solution for industry, it’s just not the only solution that could be 
used.

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

What I see though is we’re duplicating code and work between bootloaders
and kernel, for example the SPI-NOR code, and if it was all linux, it would be
one driver model to learn/remember/track, and one place to fix things.

U-boot is great because you can boot other !linux things (like FreeBSD),
however if I was purpose building a linux cluster, I would want to be running
linux as early as possible so I can use linux scripting in bash/go/python and
talk to the queue/workload manager over a native high performance network
instead of the extremely limited ‘hush’ shell and having to discover which
user image to boot with something old and slow like dhcp/tftp/etc.
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv