> On Aug 21, 2019, at 4:02 PM, Anup Patel <anup.pa...@wdc.com> wrote:
>
>
>
>> -----Original Message-----
>> From: linux-kernel-ow...@vger.kernel.org <linux-kernel-
>> ow...@vger.kernel.org> On Behalf Of Troy Benjegerdes
>> Sent: Wednesday, August 21, 2019 11:25 PM
>> To: Atish Patra <atish.pa...@wdc.com>
>> Cc: h...@lst.de; paul.walms...@sifive.com; linux-ri...@lists.infradead.org;
>> Damien Le Moal <damien.lem...@wdc.com>; linux-
>> ker...@vger.kernel.org; pal...@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.pa...@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 <h...@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.
