From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mx.groups.io with SMTP id smtpd.web11.10506.1672999628425680803 for ; Fri, 06 Jan 2023 02:07:08 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=DjdPHlSK; spf=pass (domain: redhat.com, ip: 170.10.129.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1672999627; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=U6JvTI1sjuTMQNx7UWTR6ejbwr1ruRwmjpWM20lPY8M=; b=DjdPHlSKNPoeRhJ8Ng7LSIDJrM8atX7pl2jV9TgQ3Blp+fHrS5Y2SSIu8uK1xZ7pGrKWVa f7+Fyi3pf0xEgZGEpWmIK8TqcXpZqLZFAm7AvBg8ZOpyYfAuiVOM6CZsigzur+qMycPrwn 3IQ/x6cGxgWH52owX43S1maS8eY250s= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-245-MbXzMUl7NZKhxffBFClOoQ-1; Fri, 06 Jan 2023 05:07:02 -0500 X-MC-Unique: MbXzMUl7NZKhxffBFClOoQ-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id C65922999B31; Fri, 6 Jan 2023 10:07:01 +0000 (UTC) Received: from [10.39.192.26] (unknown [10.39.192.26]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6AC1C40C945A; Fri, 6 Jan 2023 10:07:00 +0000 (UTC) Message-ID: <2f89fc97-6c11-20fd-9585-51842d274745@redhat.com> Date: Fri, 6 Jan 2023 11:06:59 +0100 MIME-Version: 1.0 Subject: Re: [edk2-devel] [PATCH v3 03/16] ArmVirtPkg: make EFI_LOADER_DATA non-executable From: "Laszlo Ersek" To: devel@edk2.groups.io, kraxel@redhat.com, Ard Biesheuvel Cc: dann frazier , Alexander Graf , Leif Lindholm , Sean Brogan 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> <52d39285-1df3-f39a-4155-46fdf2f5043e@redhat.com> In-Reply-To: <52d39285-1df3-f39a-4155-46fdf2f5043e@redhat.com> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.2 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 1/6/23 10:55, Laszlo Ersek wrote: > On 1/4/23 12:11, Gerd Hoffmann wrote: > >> 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 ... > > See also: commit d20b06a3afdf ("OvmfPkg: disable no-exec DXE stack by > default", 2015-09-15). That was more than seven years ago, and it's what > > git blame master -- OvmfPkg/OvmfPkgX64.dsc | grep PcdSetNxForStack > > reports today. On a more constructive note. By the book, this guest OS-level quirk should be exposed from the firmware up to libosinfo / osinfo-db. Starting with a dynamic PCD or HOB exposed via fw_cfg (with the fw_cfg filename conforming to "docs/specs/fw_cfg.rst" in QEMU), handled by libvirtd and other management applications (domain XML and other config formats, matching code, etc), and ultimately recorded in a "w^x" capability entry in the libosinfo schema and the osinfo database. All other guest OS compatibility settings are tracked in osinfo nowadays, security related or not, and they are so important that recent virt-install even refuses (by default) to install a domain if it doesn't recognize (and the user doesn't say) what the guest OS is. https://github.com/virt-manager/virt-manager/commit/26ecf8a5e3e4721488159605afd10e39f68e6382 Those settings control various CPU vulnerability mitigations even, IIUC, so it's almost certainly the right place to implement this new quirk too. Let us not sweep it under the carpet, and heap on more technical debt. Storing grub hashes in the firmware is similar to Windows video drivers tailoring themselves to the game the user happens to start. "Tailoring" is fine, but not from the bottom up. Here's what we could do for, and in, ArmVirtQemu *upstream*: - file the proper RFEs for the above-described components, - get their maintainers publicly commit to implementing them (that will take a while), - once each RFE has been committed to, and we think the whole picture is covered, downgrade the "w^x" default in ArmVirtQemu as follows: - list the ticket links near the code that does the downgrade - *gate* the downgrade on the platform RTC reading a date that's before a specific, open-coded constant. We'll forget about the downgrade, but the RTC won't forget about time passing. This will make us revise the concession in time (unlike how we've completely forgotten about PcdSetNxForStack). Once all the RFEs have been fixed upstream, and widely shipped in products, we can remove the downgrade. Laszlo