From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mx.groups.io with SMTP id smtpd.web11.69.1689272554248659114 for ; Thu, 13 Jul 2023 11:22:34 -0700 Authentication-Results: mx.groups.io; dkim=fail reason="body hash did not verify" header.i=@linux.microsoft.com header.s=default header.b=dGKC5NGH; spf=pass (domain: linux.microsoft.com, ip: 13.77.154.182, mailfrom: osde@linux.microsoft.com) Received: from [10.137.194.171] (unknown [131.107.1.171]) by linux.microsoft.com (Postfix) with ESMTPSA id 8603C21C4504; Thu, 13 Jul 2023 11:22:33 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 8603C21C4504 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1689272553; bh=VGNxkwI5D/p98AgLcchIYJX7BQ4OOnJohvi6bxGY9JA=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=dGKC5NGH9h9j5YUzffYo8uNUHvKr/UgiauOdH/+tBKEtomXzOmUtMi86AyYZb90mC k2jNvxRl9NUHDSmSpO12IxAkOSnZu8lNdqQcbNfsiSxF3womFmMoPmMqjTJYugfxng YnAFU5K7bcll9tZ9HPqOPrFK0EYhHwwOnFuccDhE= Message-ID: <3e95a9b9-a0d7-7178-db3c-28db31b95ecd@linux.microsoft.com> Date: Thu, 13 Jul 2023 11:22:33 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [edk2-devel] ArmVirtPkg: non-executable EFI_LOADER_DATA breaks GRUB on Ubuntu 22.04 To: devel@edk2.groups.io, pedro.falcato@gmail.com, Ard Biesheuvel Cc: Gerd Hoffmann , osy@turing.llc, Leif Lindholm , dann frazier References: From: "Oliver Smith-Denny" In-Reply-To: Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 7/13/2023 10:41 AM, Pedro Falcato wrote: > On Thu, Jul 13, 2023 at 6:20=E2=80=AFPM Ard Biesheuvel wrote: >> >> 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 machi= ne which I've decided to update the UEFI firmware. After doing so, GRUB n= o longer boots ("Synchronous Exception" message seen). After a git bisect= session, I found the problematic 2997ae38739756ecba9b0de19e86032ebc689ef= 9. The comment says GRUB should have been fixed in 2017, but for one reas= on or another, my VM which was built in 2022 still had the issue. Regardl= ess, 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 cr= ashing with an "Synchronous Exception." Googling this error message shows= that other people may be hitting this issue as well but the vague error = symptom means its impossible 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 handl= ing >>>> 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= there? >>> >> >> 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. >=20 > I understand your sentiment, but I don't see how this can work. Let's > say Fedora has a fixed GRUB (I have no idea if this is the case), so > they have a fully-NX'd edk2. Then someone tries to boot Ubuntu 22.04 - > it crashes because Ubuntu's GRUB is borked; what now? I don't know if > this case is super prevalent in virtualization, but it's definitely a > problem (and it seems to have happened to osy here?). >=20 > I agree that turning off NX sucks, but so does not being able to boot > into distros as recent as Ubuntu 22.04. It might be that a single > Sleep(10); + a nice loud error message gets the idea across? maybe > over a stable tag or so, then we remove the hack and add full-NX. What > do you think? >=20 I agree with Ard here. If other software is buggy and outdated, our general approach should be fix your outdated and buggy software, especially when there are security and safety implications to bending backwards for broken code. A downstream platform may well need to support buggy OSes, etc. for the lifespan of the device, but upstream edk2 is not the right place to add hacks for buggy external software. edk2 is our opportunity to do the right thing and help encourage the community to the right place. When distros have the maintenance burden of working with downstream platforms to support their lack of updating grub etc., they may decide it is worthwhile to actually update grub... Thanks, Oliver