From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f176.google.com (mail-pf1-f176.google.com [209.85.210.176]) by mx.groups.io with SMTP id smtpd.web11.45663.1689008980581292863 for ; Mon, 10 Jul 2023 10:09:40 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: gmail.com, ip: 209.85.210.176, mailfrom: osy86dev@gmail.com) Received: by mail-pf1-f176.google.com with SMTP id d2e1a72fcca58-6682909acadso2458506b3a.3 for ; Mon, 10 Jul 2023 10:09:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689008980; x=1691600980; 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=pbSQvL2HAYWkN8fTD+y7A8gjk+WrjOirUiO+FwnHbBY=; b=MQvjmez1YBffIrm2Qk23CmdACWjHVlb672gBkbaU8edOnTBdZq61Up+7spVbgiItnR eEeepFBOZcdnJX9BhgDx5qIJXEDq9epjPpJ5Dn6xtC5BWDmUnPg7bKRIUAbP4DIJ0ZAz +Y8YE3MBuo+Ct68Kjb6m44HFqDOj2JR/lnV5rFTr3gnV1o+w4r5xm09ZNNg6p0TGPbpM +LEnp8JsnsJ/yFkno8+kU9eJzlKF7R6e0Hl4lONsWRDKjntzS79XmtlfdLOzewiS7eOF DsLyt8n0Jd75+HDIrJQNNov5QDRxnTFeuAQ5oYNNrrUHdLrsynYFXLicEFf4QkgQGQ9z 2NMw== X-Gm-Message-State: ABy/qLbFJerIb5OLas4gC/AliawxApuo6RhH9GPK5DLwmxG9z+QvdJz8 fqFZCpQIG/GXr3FRFCiHlCDnBZI4oQY= X-Google-Smtp-Source: APBJJlHONOcSQ9rBfM9MlV3QjVpMpGsLuzpyLxBmQ36l47iM4gJAHf73MEPzcHZm+468C9njzMFuVA== X-Received: by 2002:a05:6a20:3d92:b0:126:9539:ec30 with SMTP id s18-20020a056a203d9200b001269539ec30mr12200141pzi.19.1689008979577; Mon, 10 Jul 2023 10:09:39 -0700 (PDT) Return-Path: Received: from mail-pg1-f170.google.com (mail-pg1-f170.google.com. [209.85.215.170]) by smtp.gmail.com with ESMTPSA id j9-20020a62b609000000b00678afd4824asm24040pff.175.2023.07.10.10.09.39 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 10 Jul 2023 10:09:39 -0700 (PDT) Received: by mail-pg1-f170.google.com with SMTP id 41be03b00d2f7-55ae51a45deso2307584a12.3 for ; Mon, 10 Jul 2023 10:09:39 -0700 (PDT) X-Received: by 2002:a17:90a:9dc2:b0:263:feab:2804 with SMTP id x2-20020a17090a9dc200b00263feab2804mr10218560pjv.37.1689008979057; Mon, 10 Jul 2023 10:09:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: osy@turing.llc Date: Mon, 10 Jul 2023 10:09:28 -0700 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: devel@edk2.groups.io, Ard Biesheuvel , Gerd Hoffmann , Leif Lindholm , dann frazier Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jul 10, 2023 at 8:58=E2=80=AFAM 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 machine wh= ich I've decided to update the UEFI firmware. After doing so, GRUB no longe= r boots ("Synchronous Exception" message seen). After a git bisect session,= I found the problematic 2997ae38739756ecba9b0de19e86032ebc689ef9. The comm= ent says GRUB should have been fixed in 2017, but for one reason or another= , my VM which was built in 2022 still had the issue. Regardless, I don't th= ink 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 "Syn= chronous Exception." Googling this error message shows that other people ma= y be hitting this issue as well but the vague error symptom means its impos= sible 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? > 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? > > Personally, I would like to avoid loosening up memory permissions. > > -- > Pedro I agree with the desire to be more secure, but the way I see it is that the firmware's first priority is to load the bootloader and gracefully hand off control. The fact that a bootloader is "too old" shouldn't be a reason to just crash and die. Once downstream projects like QEMU start picking up this change, this could potentially become an issue for a lot of users. If the EDK2 project decides that there is no technical way to both have secure memory permissions and support older GRUB installs, I think this breakage must be communicated effectively and be made explicit. I agree that distros probably shouldn't ship bad GRUBs (here's a bug report in Fedora addressing the same issue https://bugzilla.redhat.com/show_bug.cgi?id=3D2149020) and perhaps they have already fixed it but at the end of the day, the UEFI firmware likely isn't maintained by the distros. When a user updates their firmware (from QEMU or from a board vendor), they don't expect their OS to stop booting. If this happened on real hardware, it could actually be a real pain to downgrade the firmware or recover and update GRUB.