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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <F4C28F0F-7385-432E-A766-64A3F8B8C381@sifive.com>
Date:   Wed, 21 Aug 2019 10:54:44 -0700
From:   Troy Benjegerdes <troy.benjegerdes@...ive.com>
To:     Atish Patra <Atish.Patra@....com>
Cc:     "hch@....de" <hch@....de>,
        "paul.walmsley@...ive.com" <paul.walmsley@...ive.com>,
        "linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
        Damien Le Moal <Damien.LeMoal@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "palmer@...ive.com" <palmer@...ive.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@....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@....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.

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.