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.web10.16288.1684828463333080155 for ; Tue, 23 May 2023 00:54:23 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=V8Eh0YWk; 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 C8AC662175 for ; Tue, 23 May 2023 07:54:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3421CC433EF for ; Tue, 23 May 2023 07:54:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1684828462; bh=bcvIQfoESVKun+FC4hYraLVf6X4Y+/kImuwhhoX++6I=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=V8Eh0YWklpBZB4Sizp/nez2OF+heuZQZLI2EOpHdC4edWH4u7+QOlla+qU9zdBh/p HQRXbG0+5GfWxex8nE1XCq1KG6wGV0GZGw/bCVxxZxDWgmE8ZGBDuXf1SlAm8OrObf SV/MHDCiiGjg4VSVFj29yHIir1uyFomQU7ouJJK90ycfe3V2JsCLr8bPIxSQ9Yz3uk NtQvIMb0CtmvMNKiYKLAKjLgj8KG3NbevDAAKpxdyPqMvlO6uBO+kNA9YogvT+80TL lzj8L1ebGiKelD+XRKPznfFdXmwLDEPmCzUpncfPMf0PHPIvaNVOtzUHxykDbqeWk5 FPEM7VBy31yEA== Received: by mail-lf1-f41.google.com with SMTP id 2adb3069b0e04-4f3b5881734so3955537e87.0 for ; Tue, 23 May 2023 00:54:22 -0700 (PDT) X-Gm-Message-State: AC+VfDy7pJS8tfdMAvRwjIAkJ7brtc7sjrgSHG0mYksItEBjGLnpld58 XMDv8faeAUu8Gozz5WjeuMkcjX5R/vQngk/I01A= X-Google-Smtp-Source: ACHHUZ7pmUjw5fb2A67USSAH6Pb2Sr9BhSHy2rsy8fbjlMmaw1yaDWGGW4Sxu37OEcWX+9qc+c6+yt7ilqng+yKJles= X-Received: by 2002:ac2:5298:0:b0:4f1:5010:4b34 with SMTP id q24-20020ac25298000000b004f150104b34mr4673100lfm.18.1684828460117; Tue, 23 May 2023 00:54:20 -0700 (PDT) MIME-Version: 1.0 References: <1718e8ad-6ba3-5da8-85c5-76e48c42110d@redhat.com> <2e04e9da-5b5a-9c00-76fe-c149538ddc80@redhat.com> In-Reply-To: <2e04e9da-5b5a-9c00-76fe-c149538ddc80@redhat.com> From: "Ard Biesheuvel" Date: Tue, 23 May 2023 09:54:08 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: managing memory attributes in PEI To: Laszlo Ersek Cc: "Ni, Ray" , edk2-devel-groups-io , "Yao, Jiewen" , Gerd Hoffmann , Taylor Beebe , Oliver Smith-Denny Content-Type: text/plain; charset="UTF-8" On Tue, 23 May 2023 at 09:34, Laszlo Ersek wrote: > > On 5/23/23 07:39, Ni, Ray wrote: > > > > > >> -----Original Message----- > >> From: Laszlo Ersek > >> Sent: Tuesday, May 23, 2023 1:31 PM > >> To: Ard Biesheuvel ; edk2-devel-groups-io > >> ; Ni, Ray ; Yao, Jiewen > >> ; Gerd Hoffmann ; Taylor Beebe > >> ; Oliver Smith-Denny > >> Subject: Re: managing memory attributes in PEI > >> > >> On 5/22/23 13:31, Ard Biesheuvel wrote: > >>> Hello all, > >>> > >>> (OVMF specific questions below - please keep reading) > >>> > >>> As a follow-up to the discussion we had last week regarding DXE core, > >>> I'd like to raise the issue of managing memory permissions in PEI, > >>> including the mapping attributes of the code and data regions of DXE > >>> core itself. > >>> > >>> This is about good hygiene in general, but on arm64 in particular, > >>> limiting execution permissions to memory regions that are mapped > >>> read-only allows the MMU to be enabled in WXN mode, where all writable > >>> regions are non-executable by default. > >>> > >>> I have implemented a proof-of-concept of this for ArmVirtQemu and > >>> Raspberry Pi 4 (the former using PEI and the latter PEI-less), and > >>> this seems quite feasible in practice, but there are a few issues that > >>> I have identified: > >>> > >>> - PEI shadowing is currently disabled entirely - this is actually an > >>> advantage for the [virtual] platform in question, given that shadowing > >>> is more work for no benefit, but it is something that needs to be > >>> addressed in the general case; > >>> - no generic method exists to manage page table permissions. > >>> > >>> So what I would like to propose (and what I intend to prototype) is a > >>> PPI that abstracts this capability, and which can be used by the PEI > >>> image loader as well as the DxeIpl to manage read-only and non-exec > >>> permissions. Most PEIMs only have a code region anyway, so hopefully > >>> there is some room for optimization where not all PEIMs need 4k > >>> alignment. > >>> > >>> That leaves one big issue, and this is related to OVMF's use of IA32 > >>> PEI with X64 DXE. This complicates the DxeIpl substantially already, > >>> but would make this effort rather tricky as well. > >>> > >>> So my questions are: > >>> - do we need to retain mixed IA32 / X64 support, and if so, why? (I > >>> think it is related to SMM emulation but I need someone to confirm > >>> this) > >> > >> For a long time, IA32X64 had been required if you wanted (a) X64 DXE, > >> (b) SMM, and (c) ACPI S3 resume. The reason was that > >> UefiCpuPkg/Universal/Acpi/S3Resume2Pei didn't support SMM on X64, only > >> on IA32. > >> > >> See commit 5133d1f1d297 ("OvmfPkg: replace README fine print about X64 > >> SMM S3 with PlatformPei check", 2015-11-30). > >> > >> This S3Resume2Pei limitation got lifted last year, in commit > >> 6acf72901a2e ("UefiCpuPkg: Supporting S3 in 64bit PEI", 2022-12-19), for > >> . > >> > >> Gerd tested the according removal of S3Verification() in OVMF > >> , but that code > >> is not upstream (or downstream at that, IIUC), yet. > >> > >> Once S3Verification() is removed, OVMF IA32X64 will remain useful for > >> exercising a particular IA32X64 combination of modules that physical > >> platforms use, but I reckon IA32X64 will no longer be required for > >> virtualization purposes per se. > > > > Wow. I didn't realize OVMF had S3Verification() to explicitly educate users > > X64 PEI + SMM doesn't support S3.:) > > That will be great to remove the code today. > > > >> > >> Before we enabled SMM for OVMF, we had never really used IA32X64 OVMF -- > >> SMM-less ACPI S3 resume had just worked fine with X64-only OVMF. IA32X64 > >> only proved a great platform option to fall back to, when we realized > >> that on X64 OVMF, ACPI S3 resume wouldn't just seamlessly extend to SMM. > > > > I don't quite understand. So, what's the conclusion of IA32X64 OVMF? Keep it? Remove it? > > > > As long as edk2 (core modules) will continue supporting IA32X64 firmware > platforms, I think keeping OVMF IA32X64 is useful, minimally as a test > bed for those core modules / PCDs / boot paths. If it becomes difficult > / costly to maintain OVMF IA32X64, then removing it might make sense at > some point, but I don't think it's time for that already. > > So right now I'd just consider "shifting emphasis" from OVMF IA32X64 to > OVMF X64. > > And of course this is just my opinion. > Thanks Laszlo. I tend to agree. It will just mean that IA32X64 will be left behind in terms of future enhancements. IOW, I am not going to bother catering for IA32X64 when proposing a memory attributes PPI that manages page table permissions for shadowed PEIMs and the DXE core. I don't think anyone would mind that.