From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CBD192BE034 for ; Fri, 7 Nov 2025 10:17:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762510659; cv=none; b=k0H1SZcq4oXX2Rs7qWmCABy1DaWlwK8il3RDcm7PbOmDLfKsdVquhV5VPt7HCwqqbzFT9agnC4MiH0H0PnjOpvAzG3vVrtSU2AtrR7aTh3OlNy02b/thIYoTv1S7FjjQP+0rmQ5K+8hufbukKM8NNqcJ4VqR7JJVkGMd4GxkpgI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762510659; c=relaxed/simple; bh=arlVfPdYe3UiKIacT71hJyo52FEEmenfhFoMLnTXSxg=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=pHuAkjltwC8DW3aHzM//WEbTplLHbxAUllalGAWpg3lTnCZDlDRN1xBA/Kn0x7lDuyAiFLV7k5hQHceyL4LHwMQwszejLVv3t0Iuxk8d1lmBTH+VUV6z9e4XEZsLCcFMZZJ9OibXwGz107Bi3tZTGXGMckKJNSiT8lkD0F7StkI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=YKvIDht7; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="YKvIDht7" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6DC9EC116C6 for ; Fri, 7 Nov 2025 10:17:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1762510659; bh=arlVfPdYe3UiKIacT71hJyo52FEEmenfhFoMLnTXSxg=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=YKvIDht7l4oVHTr7yJEvsNIsb6BKJ3Q54wIifctbIk2EbgxotNt3ffPiqiNncuub0 XR76U/PZPV76GMSz6xsvjB30wuQL5sOH7pY2aC70OEoTRomaAV1cOheaqZufrvggXI pM2Sl+2Ds3hS4TTWARTssK3+qY/cOKhDwRjbLGgNab0USzt+xu4oqdwsnKOTEoZ8yE QKbu6E0Cc3Dok0IZ8hM9NuTa7qtA+YPBL45qVB4kRr34Itj9Qe4ERQY5SNNNzZh304 qggnqVtkudivimbpGnKG+r3q3gYEpN0tIvjn+FwY9qAjaPABGYyvV7xD8nUCN2YY6u tJWZ6qfVJGUuQ== Received: by mail-lf1-f54.google.com with SMTP id 2adb3069b0e04-591c74fd958so576234e87.3 for ; Fri, 07 Nov 2025 02:17:39 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCXChm3zfj1ALQ2JqqY1sy2DGp8lBj7bTeDiCxCJQLVgrLANxUUwQmN2y1pmmMFI/lPnPWJ+yoslC60=@vger.kernel.org X-Gm-Message-State: AOJu0YzQOOfxNLYRHrVMaV4FmhOMQhOdkxUR+1oKU0n6nIWWZ9tppe5t 2RddGiba6h6iSsXXfuhDeSMSACYy6yVtrqX3tV/IWIZolpKKKVMvKxNSKih2hwI7A/UTGfbzxRH BOEX/0eIfgUubojrqJUJn7Y7Myn7eiUk= X-Google-Smtp-Source: AGHT+IE/XYYxpOEX/Z7mBSZkdLHtJSOaW05OPzavoiOdoVqrUeqP4sb22fq75J96c7knabnGnpYkV8NFT+EOwV21q0U= X-Received: by 2002:a05:6512:114b:b0:58a:f865:d7a6 with SMTP id 2adb3069b0e04-59456ba0021mr819044e87.48.1762510657742; Fri, 07 Nov 2025 02:17:37 -0800 (PST) Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20251029210310.1155449-1-sohil.mehta@intel.com> <20251029210310.1155449-6-sohil.mehta@intel.com> <3e9c4fdd-88a8-4597-9405-d865fb837d95@intel.com> <6dec8398-3f7c-44db-a30d-33593af0217f@intel.com> <20251107090406.GU3245006@noisy.programming.kicks-ass.net> <20251107101003.GB1618871@noisy.programming.kicks-ass.net> In-Reply-To: <20251107101003.GB1618871@noisy.programming.kicks-ass.net> From: Ard Biesheuvel Date: Fri, 7 Nov 2025 11:17:26 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AWmQ_bnMcv5ykNOoKNY2OE119Vgn62Zu9BQlLgx3zSXeTiu2CQ91Pez_S2fCPXA Message-ID: Subject: Re: [PATCH v11 5/9] x86/efi: Disable LASS while mapping the EFI runtime services To: Peter Zijlstra Cc: Dave Hansen , Sohil Mehta , Andy Lutomirski , "the arch/x86 maintainers" , Dave Hansen , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Jonathan Corbet , "H. Peter Anvin" , Josh Poimboeuf , "Kirill A . Shutemov" , Xin Li , David Woodhouse , Sean Christopherson , Rick P Edgecombe , Vegard Nossum , Andrew Cooper , Randy Dunlap , Geert Uytterhoeven , Kees Cook , Tony Luck , Alexander Shishkin , linux-doc@vger.kernel.org, Linux Kernel Mailing List , linux-efi@vger.kernel.org Content-Type: text/plain; charset="UTF-8" On Fri, 7 Nov 2025 at 11:10, Peter Zijlstra wrote: > > On Fri, Nov 07, 2025 at 10:22:30AM +0100, Ard Biesheuvel wrote: > > > There is also PRM, which is much worse, as it permits devices in the > > ACPI namespace to call firmware routines that are mapped privileged in > > the OS address space in the same way. I objected to this at the time, > > and asked for a facility where we could at least mark such code as > > unprivileged (and run it as such) but this was ignored, as Intel and > > MS had already sealed the deal and put this into production. This is > > much worse than typical EFI routines, as the PRM code is ODM/OEM code > > rather than something that comes from the upstream EFI implementation. > > It is basically a dumping ground for code that used to run in SMM > > because it was too ugly to run anywhere else. > > 'https://uefi.org/sites/default/files/resources/Platform Runtime Mechanism - with legal notice.pdf' > > Has on page 16, section 3.1: > > 8. PRM handlers must not contain any privileged instructions. > > So we should be able to actually run this crap in ring3, right? How interesting! This wasn't in the draft that I reviewed at the time, so someone did listen. So it does seem feasible to drop privileges and reacquire them in principle, as long as we ensure that all the memory touched by the PRM services (stack, code, data, MMIO regions) is mapped appropriately in the EFI memory map.