Linux-RISC-V Archive on lore.kernel.org
 help / color / Atom feed
From: Anup Patel <Anup.Patel@wdc.com>
To: Troy Benjegerdes <troy.benjegerdes@sifive.com>,
	Atish Patra <Atish.Patra@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>,
	"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 23:02:09 +0000
Message-ID: <MN2PR04MB6061794D39900E038F9FCF218DAA0@MN2PR04MB6061.namprd04.prod.outlook.com> (raw)
In-Reply-To: <F4C28F0F-7385-432E-A766-64A3F8B8C381@sifive.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
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply index

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-13 15:47 RISC-V nommu support v3 Christoph Hellwig
2019-08-13 15:47 ` [PATCH 01/15] irqchip/sifive-plic: set max threshold for ignored handlers Christoph Hellwig
2019-08-13 17:44   ` Paul Walmsley
2019-08-14  9:06     ` Marc Zyngier
2019-08-13 15:47 ` [PATCH 02/15] riscv: use CSR_SATP instead of the legacy sptbr name in switch_mm Christoph Hellwig
2019-08-13 16:36   ` Paul Walmsley
2019-08-13 16:42     ` Christoph Hellwig
2019-08-13 16:51       ` Paul Walmsley
2019-08-13 19:44   ` Paul Walmsley
2019-08-13 15:47 ` [PATCH 03/15] riscv: refactor the IPI code Christoph Hellwig
2019-08-14  4:41   ` Paul Walmsley
2019-08-19 10:18     ` Christoph Hellwig
2019-09-01  8:03     ` Christoph Hellwig
2019-08-13 15:47 ` [PATCH 04/15] riscv: abstract out CSR names for supervisor vs machine mode Christoph Hellwig
2019-08-13 15:47 ` [PATCH 05/15] riscv: improve the default power off implementation Christoph Hellwig
2019-08-13 15:47 ` [PATCH 06/15] riscv: provide a flat entry loader Christoph Hellwig
2019-08-13 15:47 ` [PATCH 07/15] riscv: read the hart ID from mhartid on boot Christoph Hellwig
2019-08-13 15:47 ` [PATCH 08/15] riscv: provide native clint access for M-mode Christoph Hellwig
2019-08-13 16:29   ` Mark Rutland
2019-08-19 10:16     ` Christoph Hellwig
2019-08-27 23:37       ` Palmer Dabbelt
2019-08-28  6:11         ` Christoph Hellwig
2019-09-03 18:48           ` Palmer Dabbelt
2019-09-04  2:05             ` Alan Kao
2019-08-21  0:24   ` Atish Patra
2019-08-21  0:42     ` hch
2019-08-13 15:47 ` [PATCH 09/15] riscv: implement remote sfence.i natively " Christoph Hellwig
2019-08-20 21:04   ` Atish Patra
2019-08-13 15:47 ` [PATCH 10/15] riscv: poison SBI calls " Christoph Hellwig
2019-08-20 21:05   ` Atish Patra
2019-08-13 15:47 ` [PATCH 11/15] riscv: don't allow selecting SBI-based drivers " Christoph Hellwig
2019-08-13 15:47 ` [PATCH 12/15] riscv: use the correct interrupt levels " Christoph Hellwig
2019-08-13 15:47 ` [PATCH 13/15] riscv: clear the instruction cache and all registers when booting Christoph Hellwig
2019-08-14  1:00   ` Alan Kao
2019-08-14  1:07     ` Alan Kao
2019-08-14  4:35     ` Christoph Hellwig
2019-08-13 15:47 ` [PATCH 14/15] riscv: add nommu support Christoph Hellwig
2019-08-13 15:47 ` [PATCH 15/15] riscv: disable the EFI PECOFF header for M-mode Christoph Hellwig
2019-08-20 21:07   ` Atish Patra
2019-08-21  4:14   ` Troy Benjegerdes
2019-08-21  7:12     ` Christoph Hellwig
2019-08-21 17:31     ` Atish Patra
2019-08-21 17:54       ` Troy Benjegerdes
2019-08-21 23:02         ` Anup Patel [this message]
2019-08-21 23:32           ` Troy Benjegerdes
2019-10-17 17:37 RISC-V nommu support v5 Christoph Hellwig
2019-10-17 17:37 ` [PATCH 15/15] riscv: disable the EFI PECOFF header for M-mode Christoph Hellwig
2019-10-18  3:06   ` Anup Patel

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=MN2PR04MB6061794D39900E038F9FCF218DAA0@MN2PR04MB6061.namprd04.prod.outlook.com \
    --to=anup.patel@wdc.com \
    --cc=Atish.Patra@wdc.com \
    --cc=Damien.LeMoal@wdc.com \
    --cc=hch@lst.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@sifive.com \
    --cc=paul.walmsley@sifive.com \
    --cc=troy.benjegerdes@sifive.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-RISC-V Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-riscv/0 linux-riscv/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-riscv linux-riscv/ https://lore.kernel.org/linux-riscv \
		linux-riscv@lists.infradead.org
	public-inbox-index linux-riscv

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.infradead.lists.linux-riscv


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git