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.10323.1672833896997078565 for ; Wed, 04 Jan 2023 04:04:57 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=ZNkxWHGX; 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.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 1ECCC613E9 for ; Wed, 4 Jan 2023 12:04:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 830D2C433F2 for ; Wed, 4 Jan 2023 12:04:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1672833895; bh=1HR//ajnTYRF0lVdBK5TLPuAiG6J+HRN7PgyqohCVVc=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=ZNkxWHGXXoB+OnIH3uBnQ28OxJgBASYcDNmbWPCcyTo119IOsTzZnXfpgFkILAMPR JAGUnqx2cl67lZxRPbqxhmTyUeSXSG+T1uCrKh3s1aM/TERByKGjskUjkG0yDazt47 23ku+fIv/zQY+hR9EHWiiwcUEtLu1gA2wd/aah+U52NPu46/tDLLtL+dPPFOZNmAcg jYQSegho7qlKgwmnDP0OW1bF6jpn/QnJVbtWzB4L0bDgoXda1//iv+SmkdEkIXvswq BB9J/5zhmzSePgA6vNeGMG1exB60HQv3RvmIE+0A5J+4ZVkN48WxxtGtsdUkYERJSW crm79ammvKRkQ== Received: by mail-lf1-f46.google.com with SMTP id v25so2668315lfe.12 for ; Wed, 04 Jan 2023 04:04:55 -0800 (PST) X-Gm-Message-State: AFqh2koJuzMwviUKVmpetUdNJiB1I9rSfFG0hF21XouYE/4mT26+I/wx tmef2d9gFVYuOaJCBlLE1GP7AoNQmRGvxgRvlc8= X-Google-Smtp-Source: AMrXdXuDFxyelAS6qBBqgnppE1GvwJ+3d66Iy98j0zu9NrT3UyLGm66NIL2PuIgVgwKFjIAkGvJljbQ1MsUpu5R3DVQ= X-Received: by 2002:ac2:5e65:0:b0:4a2:740b:5b02 with SMTP id a5-20020ac25e65000000b004a2740b5b02mr1868252lfr.122.1672833893492; Wed, 04 Jan 2023 04:04:53 -0800 (PST) MIME-Version: 1.0 References: <20220926082511.2110797-1-ardb@kernel.org> <20220926082511.2110797-4-ardb@kernel.org> <20221128154610.wik3f65bhbfrdpva@sirius.home.kraxel.org> <7bba7344-fc37-abde-a792-5ae40621c70f@csgraf.de> <20230104111134.ewioietmprrrprad@sirius.home.kraxel.org> In-Reply-To: <20230104111134.ewioietmprrrprad@sirius.home.kraxel.org> From: "Ard Biesheuvel" Date: Wed, 4 Jan 2023 13:04:41 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [PATCH v3 03/16] ArmVirtPkg: make EFI_LOADER_DATA non-executable To: Gerd Hoffmann Cc: dann frazier , Alexander Graf , devel@edk2.groups.io, Leif Lindholm Content-Type: text/plain; charset="UTF-8" On Wed, 4 Jan 2023 at 12:11, Gerd Hoffmann wrote: > > Hi, > > > > > > You can override PCDs on the build command line, so I suggest you use > > > > > that for building these images as long as it is needed. > > > > > > > > > > E.g,, append this to the build.sh command line > > > > > > > > > > --pcd PcdDxeNxMemoryProtectionPolicy=0xC000000000007FD1 > > > > > > > > > > to undo the effects of this patch. > > Can this also be flipped at runtime? Currently, it is fixed or patchable, which means that you can override it at build time only. I don't think making this a dynamic PCD would be difficult, and on QEMU, we can set the value early enough if we key it off fw_cfg or something like that. But that implies that you need a 'permissive' mode to invoke QEMU, which ends up being always enabled, most likely, so I'm not sure this is an improvement. > Does this pcd work the same way on all architectures? > In principle, yes. However, I cannot vouch for the X86 code not doing dodgy things with data regions, so whether the same *value* works reliably across all architectures is a separate matter. > > I don't think having different versions of the image makes sense, tbh, > > but of course, this is up to the distros. > > Fedora has reverted the patch for now, and I don't see how we can enable > that anytime soon given that RHEL-8,9 with loooooong support times ship > broken grub binaries today. > Yeah. This is really disappointing. > > Compatibility with ancient downstream GRUB builds is not a goal of the > > EDK2 upstream, so as long as distros can tweak the build to their > > needs, I don't see a reason to revert this change upstream. > > The versions are not that ancient. The problem is more that upstream > grub is really slow on integrating patches so every distro does carry > a huge pile of downstream patches. And they seem to re-introduce the > bug ... > > But, yes, just reverting upstream too doesn't look like a good option > either, we need at least a little pressure to get things fixed. > Indeed.