From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp-relay-internal-1.canonical.com (smtp-relay-internal-1.canonical.com [185.125.188.123]) by mx.groups.io with SMTP id smtpd.web10.33.1672336853384849705 for ; Thu, 29 Dec 2022 10:00:54 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@canonical.com header.s=20210705 header.b=TLeQGQiv; spf=pass (domain: canonical.com, ip: 185.125.188.123, mailfrom: dann.frazier@canonical.com) Received: from mail-io1-f69.google.com (mail-io1-f69.google.com [209.85.166.69]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-1.canonical.com (Postfix) with ESMTPS id 38057418CF for ; Thu, 29 Dec 2022 18:00:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1672336851; bh=2d+OeeDa1Y/rtMVatsOOza3hO5VrDATedk+XlbFihCY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=TLeQGQiv3O+VSbRJE/b7FuXRvm1z55lQE7DINrvnES3PiRAEkyN6lOqwQrcz+wDjN sBjByrjwxCR5YWl/OQXo0tp4VRVg2LBbiOosrR77duqfZjsBjflMdsQy25cbrPXnCj iz1ZqtleqfIizg3rI7aVhD7ICD/zDGdP9Z1nnHL7yn1NaziHgLIIWDMuwptfzLUeBj iH+st+NLyJD6gw9E0O30wNtudtpEu4MAj2xf5RTZrQDAsrfAPCqfp10cq/wH8PiKvw Z78tvSMXik3a0A1Pn1sLtDGFUemjYTVNVSku/2Zu+0vgwrgXjedjQNTH0aD3Ta2lnE hE3kHwd88dr2g== Received: by mail-io1-f69.google.com with SMTP id y24-20020a5ec818000000b006e2c0847835so6065006iol.12 for ; Thu, 29 Dec 2022 10:00:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=2d+OeeDa1Y/rtMVatsOOza3hO5VrDATedk+XlbFihCY=; b=2OvJJgJDpAVVwD99wRepzbALKJWnJs/yPq0SYrnykytdVCxU02wM5HvJLWdiGhCovD M9xzY+srnPkRPdoTk7Isx09vmeW1+goGJs+9kT0jGlbCLdaqML6w41h9qABmvn7XgPwv FxTmges1pVyiCMWgFeTniYYGSALRhzkkFmwCHedtZYYIiKsdvMayPDG3jknXrEGAZmKE jXhb+ynd32rlNbqt0hPJmkvt3Ck1e3GQrkgh5tZxbjdcB9MBgpyL3Cj0QfrAr2BIgATo LesCum3FWv2eMCbpg5L9+4zd+BUlLRkGpjX6eCjWgas/HGEC7N5ql0YBlYrgjoGUQpkJ VH5A== X-Gm-Message-State: AFqh2krkiOb67T3xb9xyAeasp4MOhy5SddPGO1qBUboxHy4NbK+xYetg Ro0RznrnTEFs0MRzB3JAizobFldJEyI4FrDWv1BS3E6gAKOsY13trEupI3R+9ZHT2ETQjEpuBBW OMP3qywpCDETJuYhVFMil5Ph+qbahOY8= X-Received: by 2002:a05:6e02:13ee:b0:30c:2dda:3fa8 with SMTP id w14-20020a056e0213ee00b0030c2dda3fa8mr941797ilj.16.1672336849585; Thu, 29 Dec 2022 10:00:49 -0800 (PST) X-Google-Smtp-Source: AMrXdXs4unkKzIU+C30gyk+t/+tQ3ysR2v2jM7b4vkS6c9yC6RE55JDNW87rR2n6kbJA3dhL66c2fg== X-Received: by 2002:a05:6e02:13ee:b0:30c:2dda:3fa8 with SMTP id w14-20020a056e0213ee00b0030c2dda3fa8mr941779ilj.16.1672336849313; Thu, 29 Dec 2022 10:00:49 -0800 (PST) Received: from xps13.dannf ([38.15.56.166]) by smtp.gmail.com with ESMTPSA id r6-20020a02aa06000000b00389b6c71347sm6189212jam.60.2022.12.29.10.00.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Dec 2022 10:00:48 -0800 (PST) Date: Thu, 29 Dec 2022 11:00:46 -0700 From: "dann frazier" To: devel@edk2.groups.io, kraxel@redhat.com Cc: ardb@kernel.org, Leif Lindholm , Alexander Graf Subject: Re: [edk2-devel] [PATCH v3 03/16] ArmVirtPkg: make EFI_LOADER_DATA non-executable Message-ID: References: <20220926082511.2110797-1-ardb@kernel.org> <20220926082511.2110797-4-ardb@kernel.org> <20221128154610.wik3f65bhbfrdpva@sirius.home.kraxel.org> MIME-Version: 1.0 In-Reply-To: <20221128154610.wik3f65bhbfrdpva@sirius.home.kraxel.org> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Nov 28, 2022 at 04:46:10PM +0100, Gerd Hoffmann wrote: > On Mon, Sep 26, 2022 at 10:24:58AM +0200, Ard Biesheuvel wrote: > > When the memory protections were implemented and enabled on ArmVirtQemu > > 5+ years ago, we had to work around the fact that GRUB at the time > > expected EFI_LOADER_DATA to be executable, as that is the memory type it > > allocates when loading its modules. > > > > This has been fixed in GRUB in August 2017, so by now, we should be able > > to tighten this, and remove execute permissions from EFI_LOADER_DATA > > allocations. > > Data point: https://bugzilla.redhat.com/show_bug.cgi?id=2149020 > tl;dr: fedora 37 grub.efi is still broken. This is also the case with existing Ubuntu releases, as well as AlmaLinux 9.1 and RHEL 8.7[*]. While it does appear to be fixed for the upcoming Ubuntu 23.04 (presumably via [**]), I plan to revert this patch in Debian/Ubuntu until it is more ubiquitous. Do you want to do the same upstream? I'm not sure at what point it would make sense to reintroduce it, given we can't force users to upgrade their bootloaders. -dann [*] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025656 [**] https://git.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/commit/?id=a0ee822f1c85fcf55066996ab51c5cf77e2728b2)