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.133.124]) by mx.groups.io with SMTP id smtpd.web11.14445.1684819891945236548 for ; Mon, 22 May 2023 22:31:34 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=ZxxjAWTi; spf=pass (domain: redhat.com, ip: 170.10.133.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1684819890; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=YsHw+Hl+DshLNS5q44/tdNPcg/ZPyh/F/EhC9DHCfN4=; b=ZxxjAWTiBnp4sh4CtB6z4IM3jM6xZU5rV7O/5YFSRnFMRRt4IisgFbhROd7i6yr7rTKav8 2B2ssc6BseFEfBJdKCI9lEl+Xn95XOQHp6giRFrMTd/UIXoXdm5Qf/7ZrpB3igtqElP3ip z7ap9gOtKk7vmShJKyPotsM5aaZqgps= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-592-HFSmRIFgNw2eusbw-gcRuQ-1; Tue, 23 May 2023 01:31:26 -0400 X-MC-Unique: HFSmRIFgNw2eusbw-gcRuQ-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 4FCBC8007D9; Tue, 23 May 2023 05:31:26 +0000 (UTC) Received: from [10.39.192.98] (unknown [10.39.192.98]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 9C410C1ED99; Tue, 23 May 2023 05:31:24 +0000 (UTC) Message-ID: <1718e8ad-6ba3-5da8-85c5-76e48c42110d@redhat.com> Date: Tue, 23 May 2023 07:31:22 +0200 MIME-Version: 1.0 Subject: Re: managing memory attributes in PEI To: Ard Biesheuvel , edk2-devel-groups-io , Ray Ni , Jiewen Yao , Gerd Hoffmann , Taylor Beebe , Oliver Smith-Denny References: From: "Laszlo Ersek" In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.8 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 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. 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. Thanks, Laszlo > - if we need to retain it, could we run PEI in long mode but with > 32-bit compatibility enabled, so that we don't need two or three > incompatible sets of page tables? > > In the latter case, the PPI in question would carry the same logic for > IA32 and X64 builds, and create 4-level page tables with the code > still being 32-bit. > > Once we clear this up, I'm happy to look into extending my prototype > to x86 as well. > > Thanks, > Ard. >