From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mx.groups.io with SMTP id smtpd.web11.2831.1689268819523558207 for ; Thu, 13 Jul 2023 10:20:19 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=klcvmvHD; spf=pass (domain: kernel.org, ip: 139.178.84.217, mailfrom: ardb@kernel.org) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id DA9E361ADB for ; Thu, 13 Jul 2023 17:20:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4BD5DC433C8 for ; Thu, 13 Jul 2023 17:20:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1689268818; bh=XE9EBW257v3s7u59wU75KB4IhzIVU3xgrLZq+OO3z6k=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=klcvmvHD+0F4ujOnMpiEjDwNpRRdBoCJTIL/03pasTEkALkxOAs1qm0NVKYmDH7A/ 6xlQNliLLuys3Kt71Kj3GUOlKnFWTy1AGfPjfzd+OYa7S3UQzlFx2q1/8a14NFL24z 8mh7/44jHJZzR+IOPCM+Y4T9GBz1GW0EXtp6IzONSRjeL78f8PbSvYMgW7MWmkK7et IHoPZ7JJdatfoGaHe+38zJXWxP5yC5qO+9DKETpAj4Kejm0p/YyM4bKAcSs1DpVZD2 i31WkT5Kj/nkPy+oM5Un/YefvW+JIDCx77bJ9E6z47HlpFrpXbRV2I2WzFvG/qMp2V /+oBfmzyPPjMg== Received: by mail-lf1-f41.google.com with SMTP id 2adb3069b0e04-4fba86f069bso1730949e87.3 for ; Thu, 13 Jul 2023 10:20:18 -0700 (PDT) X-Gm-Message-State: ABy/qLb2xsHV2PiDQyNNXr5nFaIE0Vv5L5+FcQhAPIod0Sm8OY5J7P9r 1xMcnmTzpgPds3FhUvmGBOR/cH0QOwXwc3CWPq0= X-Google-Smtp-Source: APBJJlHmQiB19gkQHKQtWP7kb7SpI78fNIFIt73XNtzSg4lFeOzlghGdUXK8XiShWnrcZARE/Ebjon71sVCBvWuXpBk= X-Received: by 2002:ac2:5e28:0:b0:4fb:8a0a:31f2 with SMTP id o8-20020ac25e28000000b004fb8a0a31f2mr1720525lfg.69.1689268816207; Thu, 13 Jul 2023 10:20:16 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Ard Biesheuvel" Date: Thu, 13 Jul 2023 19:20:04 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] ArmVirtPkg: non-executable EFI_LOADER_DATA breaks GRUB on Ubuntu 22.04 To: Pedro Falcato Cc: Gerd Hoffmann , devel@edk2.groups.io, osy@turing.llc, Leif Lindholm , dann frazier Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 13 Jul 2023 at 18:57, Pedro Falcato wrote= : > > On Tue, Jul 11, 2023 at 7:58=E2=80=AFAM Gerd Hoffmann = wrote: > > > > On Mon, Jul 10, 2023 at 04:58:15PM +0100, Pedro Falcato wrote: > > > On Mon, Jul 10, 2023 at 2:28=E2=80=AFPM wrote: > > > > > > > > I have an existing install of Ubuntu 22.04 on a QEMU virtual machin= e which I've decided to update the UEFI firmware. After doing so, GRUB no l= onger boots ("Synchronous Exception" message seen). After a git bisect sess= ion, I found the problematic 2997ae38739756ecba9b0de19e86032ebc689ef9. The = comment says GRUB should have been fixed in 2017, but for one reason or ano= ther, my VM which was built in 2022 still had the issue. Regardless, I don'= t think it's a good idea to break GRUB, even if it's fixed in 2017. In the = very least, a better error message would be preferable to crashing with an = "Synchronous Exception." Googling this error message shows that other peopl= e may be hitting this issue as well but the vague error symptom means its i= mpossible to know if it's the same issue or not. > > > > > > +CC Some of the folks involved in the original discussion > > > > > > In the original thread, people discussed some alternative behavior to > > > just crashing on a NX fault. Is this still an alternative? > > > > The idea is: Improve page fault handler to (a) print a big'n'fat > > warning, and (b) loosening up memory permissions for the faulting > > page address. > > > > No patch for that emerged (yet?). > > Ack. I can work on that. > > > > I'm kind of thinking this should be addressed by distros anyway.... > > > How is $CURRENT_YEAR Ubuntu still shipping bad GRUBs? I know the > > > situation around GRUB and distro patching is complicated but... > > > Do we have any idea of how many distros/GRUBs are affected by this? > > > > Too many :( > > Ugh, even the latest releases? > > > > Personally, I would like to avoid loosening up memory permissions. > > > > Well, you can't have both. You have to pick between strict nx handling > > and grub bug compatibility ... > > Yes. IMO it should be ok to add a hack around NX handling if there's a > solid plan for dealing with this from the distros' side (and phasing > this out). And I'm assuming upstream GRUB has this fixed. > This whole situation is kind of messy as firmware people add new > restrictions that weren't really there in the first place. > > Also, what's the situation on this for x86? I assume it's a lot worse the= re? > To be honest, I have little sympathy for the gigantic mess that the distros have created for themselves with GRUB, shim, etc. Mainline GRUB works fine with mainline EDK2, and secure boot in a arm64 VM is rather pointless, given that the [emulated] NOR flash is writable by the guest OS. The breakage is in the downstream GRUB changes that make it interoperate with shim, and its hacked up PE loader. If we are going to accommodate every broken GRUB build that the distros ever released, we won't be able to make any progress on this front. I understand that the distros need to support their existing user bases, so I am willing to consider facilities that make it easier to create builds that work around such issues. However, just turning off NX support is not one of the options. Upstream is not what the distros are shipping, this applies to GRUB and shim as well as EDK2: so if their downstream GRUB breaks EDK2, they can fix it in their EDK2 builds, either by carrying a code change, or by enabling an upstream build flag that is off by default.