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.15821.1684827297424121924 for ; Tue, 23 May 2023 00:34:58 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=OPIc0EZZ; 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=1684827296; 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=MvxVYITA/eomH36exGFNxL4bIx6j30XxtB3k1kmSC0o=; b=OPIc0EZZAGjHrVALhKmYT9AJId/N+ho7EkmcExA0ToqG/ICAMACsjHvWGoY3Hm7xIjzbBr 9bfDoXKV0OXrXlpwsWJEc2t/XIenLH/WWsIPL5lxF8xGN9egkwJrB0MNLuqEXpgtNi/aMO wo0Z4Mf06cHbglXN3qHRMkPhD9HmudQ= 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-663-Y6jq8icbNuWWAztl8R1Ylg-1; Tue, 23 May 2023 03:34:50 -0400 X-MC-Unique: Y6jq8icbNuWWAztl8R1Ylg-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 6FBE13814947; Tue, 23 May 2023 07:34:50 +0000 (UTC) Received: from [10.39.192.237] (unknown [10.39.192.237]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 892CD9D73; Tue, 23 May 2023 07:34:47 +0000 (UTC) Message-ID: <2e04e9da-5b5a-9c00-76fe-c149538ddc80@redhat.com> Date: Tue, 23 May 2023 09:34:45 +0200 MIME-Version: 1.0 Subject: Re: managing memory attributes in PEI To: "Ni, Ray" , Ard Biesheuvel , edk2-devel-groups-io , "Yao, Jiewen" , Gerd Hoffmann , Taylor Beebe , Oliver Smith-Denny References: <1718e8ad-6ba3-5da8-85c5-76e48c42110d@redhat.com> From: "Laszlo Ersek" In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.5 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/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. Laszlo