From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1jT9bf-0001DM-Pg for mharc-grub-devel@gnu.org; Mon, 27 Apr 2020 15:39:55 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45874) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jT9bd-0001Cb-7U for grub-devel@gnu.org; Mon, 27 Apr 2020 15:39:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jT9bc-00067J-Hj for grub-devel@gnu.org; Mon, 27 Apr 2020 15:39:52 -0400 Received: from mail.kernel.org ([198.145.29.99]:33748) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jT9bb-00066D-0H for grub-devel@gnu.org; Mon, 27 Apr 2020 15:39:52 -0400 Received: from mail-il1-f182.google.com (mail-il1-f182.google.com [209.85.166.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 7372A214D8 for ; Mon, 27 Apr 2020 19:39:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1588016389; bh=HtxzwF2d+NWvLRdLIm4Tgun5n8B6JitNVyJRX9pGpV0=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=Q9q0z+bELbl009LELlLpYhGJGekc1m55m4oXk57FgfXWwEpjM4CApgoxE8oK0XYG7 fCNRcaxRuFL0NP3xIgsD9ZlUnSZVY6KMoB8DZaBiUtwtrC/ej0zw0jmiG6JyipQlAm LdMwzHbcn3yRnBNW2kDrOFa0CzVQ2IlJpzD36kPk= Received: by mail-il1-f182.google.com with SMTP id b18so17920647ilf.2 for ; Mon, 27 Apr 2020 12:39:49 -0700 (PDT) X-Gm-Message-State: AGi0PubI9FYTZauxRRBUq8AKi5iVfFoXTYH7q3wxRsws5/glKQemEHT3 jOc3oU7sJVEVTbX73bm49lf5mSaQJLYJ62xkLzA= X-Google-Smtp-Source: APiQypL0HvxN9+Nd3x9UlnbZEIO4fI/n/Q2o2EMIm37BWBjFWmWs9J+9AWiVOxIVAxGhw9w124R7q79VFE8cvW4Jr9w= X-Received: by 2002:a92:607:: with SMTP id x7mr20815580ilg.218.1588016388845; Mon, 27 Apr 2020 12:39:48 -0700 (PDT) MIME-Version: 1.0 References: <20200426194007.382925-1-atish.patra@wdc.com> <20200427110106.r2jqkaeheiw3lunl@tomti.i.net-space.pl> <68c6f6a8-6c13-f2f4-f2ca-287c3f5330f4@gmx.de> In-Reply-To: <68c6f6a8-6c13-f2f4-f2ca-287c3f5330f4@gmx.de> From: Ard Biesheuvel Date: Mon, 27 Apr 2020 21:39:38 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH RFC/RFT 0/3] Add grub loader support for RISC-V Linux To: Heinrich Schuchardt Cc: Daniel Kiper , Atish Patra , grub-devel@gnu.org, David Abdurachmanov , Leif Lindholm , Alexander Graf , Chester Lin , Ilias Apalodimas Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=198.145.29.99; envelope-from=ardb@kernel.org; helo=mail.kernel.org X-detected-operating-system: by eggs.gnu.org: First seen = 2020/04/27 15:11:06 X-ACL-Warn: Detected OS = Linux 3.11 and newer X-Received-From: 198.145.29.99 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 19:39:53 -0000 On Mon, 27 Apr 2020 at 21:36, Heinrich Schuchardt wrote: > > On 4/27/20 1:01 PM, Daniel Kiper wrote: > > On Mon, Apr 27, 2020 at 08:15:41AM +0200, Ard Biesheuvel wrote: > >> On Sun, 26 Apr 2020 at 21:40, Atish Patra wrote: > >>> > >>> This series adds grub loader support for RISC-V Linux. Thanks to the awesome > >>> initial RISC-V support added by Alex, we just needed a loader for RISC-V to > >>> load and execute Linux using UEFI protocol. > >>> > >>> Fortunately, ARM64 Linux loader is written in an architecture agnostic manner > >>> so thatgeneric RISC-V can easily reuse the loader code. Thus, the first patch > >>> just moves the ARM64 code to common code. I have compile tested for > >>> ARM64/ARM32. Even though it doesn't introduce any functional change > >>> for ARM/ARM64, any real testing will be helpful. > >> > >> May I suggest that we not blindly adopt the ARM code here, but > >> instead, use the new initrd loading protocol that removes the need for > >> GRUB to modify or even know about the device tree at all? > > Does this protocol exist in EDK2 by now? > Yes. It exists as a shell command, and as a load option for OVMF. > In U-Boot there is a basic implementation which can provide a single > initrd image with a hardcoded file name. The file_path argument passed > to U-Boot is ignored due to Ilias' security concerns when he wrote the > patch. > > GRUB is only needed if we have multiple kernels to choose from with > distinct initial ramdisks. > > Please, describe what you expect the initrd loading protocol to do when > called from GRUB. How will the ramdisk fitting the kernel chosen in GRUB > be identified? > The same what GRUB's 'initrd' command does. Whichever initrd you select with it is the one that gets returned by the protocol. > How do you deal with Ilias' security concerns expressed as follows in > U-boot commit ec80b4735a59 ("efi_loader: Implement FileLoad2 for > initramfs loading"): > > "The file location is intentionally only supported as a config option > argument(CONFIG_EFI_INITRD_FILESPEC), in an effort to enhance security. > Although U-boot is not responsible for verifying the integrity of the > initramfs, we can enhance the offered security by only accepting a > built-in option, which will be naturally verified by UEFI Secure Boot." > That is an implementation detail of u-boot. This is one way to address security concerns. Another way might be for U-Boot to check a signature before it allows a file to be selected as the one to be returned by the LoadFile2 protocol.