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.19580.1684755095677171751 for ; Mon, 22 May 2023 04:31:35 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=ZJw+6vwE; 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 1288261FD6 for ; Mon, 22 May 2023 11:31:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 758E8C4339B for ; Mon, 22 May 2023 11:31:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1684755094; bh=tnW412qteSBwKWUOZ+LX3UIOSyNfLjwl1JDgxSt0ON0=; h=From:Date:Subject:To:From; b=ZJw+6vwEyfOkE3B4WhoQs1QI5OBWhAcmjpf1jMVE89FrAfcaC2ZKyyEzUaf1UK68e bg77wDXnha93vgM3dMyg2XvEOF0sbS2YXSCdVXH6N+hwQ1etWsdZJTwY2G2fzj1pOy kEdGU5D4sB2iFOXEIX1jq+vEB1nWaDjXQ1AMQW1KP+GXBcrijKqy/OfoIY4mTP4BjW SJz6ZyD0D4ep8kKIJRr+lbPQGHFQjvFWiADcD5zTYOJfMIqPI5Vu968Bv/qDziQ+92 Tto93GdhW/JdcxrCDL/DrNNb7a1NnJTHHX6OWgqbO56TCzoYcsxfGiKvBJkWGBxE2w aYiIZmOQLv4LQ== Received: by mail-lf1-f41.google.com with SMTP id 2adb3069b0e04-4f4b256a0c9so823027e87.2 for ; Mon, 22 May 2023 04:31:34 -0700 (PDT) X-Gm-Message-State: AC+VfDyIrMZZqrHfOPLEnL77Yq6Q/vIPND5eo1nWvMCffqfyLTQIWYZb rGE6KD7sGNK0z3Jf9E4w2QOTqSWsvqY+UABiWmA= X-Google-Smtp-Source: ACHHUZ7tVaBLr1eDMwBaC+/igmnIeo6RjzliNLgOLIYBLTXetC+6lEbCNXmolmlKVVJ72eO4QdJWBCEJFH0epgYcfTU= X-Received: by 2002:ac2:42ce:0:b0:4f3:8143:765 with SMTP id n14-20020ac242ce000000b004f381430765mr3092539lfl.27.1684755092515; Mon, 22 May 2023 04:31:32 -0700 (PDT) MIME-Version: 1.0 From: "Ard Biesheuvel" Date: Mon, 22 May 2023 13:31:21 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: managing memory attributes in PEI To: edk2-devel-groups-io , Ray Ni , Jiewen Yao , Gerd Hoffmann , Laszlo Ersek , Taylor Beebe , Oliver Smith-Denny Content-Type: text/plain; charset="UTF-8" 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) - 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.