| Message ID | 20190813154747.24256-16-hch@lst.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [01/15] irqchip/sifive-plic: set max threshold for ignored handlers | expand |
On Tue, 2019-08-13 at 17:47 +0200, Christoph Hellwig wrote: > No point in bloating the kernel image with a bootloader header if > we run bare metal. > > Signed-off-by: Christoph Hellwig <hch@lst.de> > --- > arch/riscv/kernel/head.S | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/riscv/kernel/head.S b/arch/riscv/kernel/head.S > index 670e5cacb24e..09fcf3d000c0 100644 > --- a/arch/riscv/kernel/head.S > +++ b/arch/riscv/kernel/head.S > @@ -16,6 +16,7 @@ > > __INIT > ENTRY(_start) > +#ifndef CONFIG_M_MODE > /* > * Image header expected by Linux boot-loaders. The image > header data > * structure is described in asm/image.h. > @@ -47,6 +48,7 @@ ENTRY(_start) > > .global _start_kernel > _start_kernel: > +#endif /* CONFIG_M_MODE */ > /* Mask all interrupts */ > csrw CSR_XIE, zero > csrw CSR_XIP, zero Reviewed-by: Atish Patra <atish.patra@wdc.com>
> 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. 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, which seem most logical to me to start using the vmlinux elf binaries using something like kexec() > > Signed-off-by: Christoph Hellwig <hch@lst.de> > --- > arch/riscv/kernel/head.S | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/riscv/kernel/head.S b/arch/riscv/kernel/head.S > index 670e5cacb24e..09fcf3d000c0 100644 > --- a/arch/riscv/kernel/head.S > +++ b/arch/riscv/kernel/head.S > @@ -16,6 +16,7 @@ > > __INIT > ENTRY(_start) > +#ifndef CONFIG_M_MODE > /* > * Image header expected by Linux boot-loaders. The image header data > * structure is described in asm/image.h. > @@ -47,6 +48,7 @@ ENTRY(_start) > > .global _start_kernel > _start_kernel: > +#endif /* CONFIG_M_MODE */ > /* Mask all interrupts */ > csrw CSR_XIE, zero > csrw CSR_XIP, zero > -- > 2.20.1 > > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv
On Tue, Aug 20, 2019 at 09:14:41PM -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. 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, which seem most logical to me > to start using the vmlinux elf binaries using something like kexec() Strictly speaking we could just add another option for the header so that you could also disable it for S-mode. But then again the header is not very harmful, as you don't have to use it. It just eats up a little more kernel space. And as that aspace is very tight for my M-mode target (the Kendryte KD210) and it is totally pointless for M-mode I just remove it there. The idea of using M-mode Linux as the SBI sounds cool.
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. > which seem most logical to me > to start using the vmlinux elf binaries using something like kexec() > > > Signed-off-by: Christoph Hellwig <hch@lst.de> > > --- > > arch/riscv/kernel/head.S | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/arch/riscv/kernel/head.S b/arch/riscv/kernel/head.S > > index 670e5cacb24e..09fcf3d000c0 100644 > > --- a/arch/riscv/kernel/head.S > > +++ b/arch/riscv/kernel/head.S > > @@ -16,6 +16,7 @@ > > > > __INIT > > ENTRY(_start) > > +#ifndef CONFIG_M_MODE > > /* > > * Image header expected by Linux boot-loaders. The image > > header data > > * structure is described in asm/image.h. > > @@ -47,6 +48,7 @@ ENTRY(_start) > > > > .global _start_kernel > > _start_kernel: > > +#endif /* CONFIG_M_MODE */ > > /* Mask all interrupts */ > > csrw CSR_XIE, zero > > csrw CSR_XIP, zero > > -- > > 2.20.1 > > > > > > _______________________________________________ > > linux-riscv mailing list > > linux-riscv@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-riscv > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv
> 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. 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.
> -----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
> 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.
diff --git a/arch/riscv/kernel/head.S b/arch/riscv/kernel/head.S index 670e5cacb24e..09fcf3d000c0 100644 --- a/arch/riscv/kernel/head.S +++ b/arch/riscv/kernel/head.S @@ -16,6 +16,7 @@ __INIT ENTRY(_start) +#ifndef CONFIG_M_MODE /* * Image header expected by Linux boot-loaders. The image header data * structure is described in asm/image.h. @@ -47,6 +48,7 @@ ENTRY(_start) .global _start_kernel _start_kernel: +#endif /* CONFIG_M_MODE */ /* Mask all interrupts */ csrw CSR_XIE, zero csrw CSR_XIP, zero
No point in bloating the kernel image with a bootloader header if we run bare metal. Signed-off-by: Christoph Hellwig <hch@lst.de> --- arch/riscv/kernel/head.S | 2 ++ 1 file changed, 2 insertions(+)