From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-vk1-f173.google.com (mail-vk1-f173.google.com [209.85.221.173]) by mx.groups.io with SMTP id smtpd.web10.3382.1689270087613604133 for ; Thu, 13 Jul 2023 10:41:27 -0700 Authentication-Results: mx.groups.io; dkim=fail reason="signature has expired" header.i=@gmail.com header.s=20221208 header.b=BmbOx6P7; spf=pass (domain: gmail.com, ip: 209.85.221.173, mailfrom: pedro.falcato@gmail.com) Received: by mail-vk1-f173.google.com with SMTP id 71dfb90a1353d-48137084a66so396073e0c.3 for ; Thu, 13 Jul 2023 10:41:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689270086; x=1691862086; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=yYTlP+gwac6dOTHSYvcvcWUwWngmveGIgIEXR5cRGMk=; b=BmbOx6P7SIMsOvKQT/uCLmpn2avHDWmsZg2iMYAnvNSO5zgGmxIhiTrQM5o2/ESXIX 0nOw7nkJKOWd93xPIUTZueNzNcTSUO0IzKeF2JcwBQviWSyvKb7n72uWR/LyDTzz3XAS ww31b6KhQ2Ix/GPOYsvHNVWqXKyzLqe6O1weEl3W1RpwDdne5b40BYcL5KSmQZa/X2D3 9flMgiuswrOnOf/94ltjeEi9Np4yneZWM97EuC4P/LqVw7r7/lzU2hpCgCWIkb1SyoEr WEx0uH8bcWVo6n8uUoGzYcEPk8SIpS+4suGioEEF4Hp9xJ4JRf2zCnkt2VCfCf7ta3jF ft+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689270086; x=1691862086; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=yYTlP+gwac6dOTHSYvcvcWUwWngmveGIgIEXR5cRGMk=; b=gnn+7U4gYRwVeGoIZX+lQy4IENS2VXRFf8PIKTpalPFZ6Kf0AblsUULwmLJxshwWwx +NMfiUU1oKcpAOE4ocYnWScR/HtJzntcKNc/EqKBk1Ae/kZwBYenhtpJLht4sBNja/Nx M130zs9PjTGchhdTg8KVEuu9PnRF8MUsNEflxixSwtWiX3kKdSwaFjQpRo2u6dEHjyNa 7UA0FSlsu79MbeH7Mm2haZMubtRt9LRNaZEjwzwMVJQeajK9NPzqhH9ofJ5nSGCzAgEI 7z9e4Ug5y6Shj4AFeA+biBJ3WBzB/EtIxm2fa/+FeNMWpxGAm1HvoiSXQvrEYrBrnw0a H/+A== X-Gm-Message-State: ABy/qLacNCMV/lnvFoeQnBWwIVoPsfmyMEhMM+5cad4eWWRpa1I9HGvU iF6VuJPxeNLdesLDk9aDqRGDL4cCrlIlPW4oUzQ= X-Google-Smtp-Source: APBJJlFwnO+EGyh4qO5eanQjbJMAK6BrStcGiitFl4UfywVHap+YiG+xPIpATDrm3b1tUEetg8fa851XAW+Y5wGF0Yw= X-Received: by 2002:a1f:df41:0:b0:481:5793:9ca8 with SMTP id w62-20020a1fdf41000000b0048157939ca8mr1204130vkg.1.1689270086590; Thu, 13 Jul 2023 10:41:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Pedro Falcato" Date: Thu, 13 Jul 2023 18:41:15 +0100 Message-ID: Subject: Re: [edk2-devel] ArmVirtPkg: non-executable EFI_LOADER_DATA breaks GRUB on Ubuntu 22.04 To: Ard Biesheuvel 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, Jul 13, 2023 at 6:20=E2=80=AFPM Ard Biesheuvel wr= ote: > > On Thu, 13 Jul 2023 at 18:57, Pedro Falcato wro= te: > > > > 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 mach= ine which I've decided to update the UEFI firmware. After doing so, GRUB no= longer boots ("Synchronous Exception" message seen). After a git bisect se= ssion, I found the problematic 2997ae38739756ecba9b0de19e86032ebc689ef9. Th= e comment says GRUB should have been fixed in 2017, but for one reason or a= nother, my VM which was built in 2022 still had the issue. Regardless, I do= n't think it's a good idea to break GRUB, even if it's fixed in 2017. In th= e very least, a better error message would be preferable to crashing with a= n "Synchronous Exception." Googling this error message shows that other peo= ple 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 handli= ng > > > 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 t= here? > > > > 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. 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?). 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 Pedro