From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.zytor.com (terminus.zytor.com [198.137.202.136]) (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 7654C33F8A4; Wed, 12 Nov 2025 16:29:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.137.202.136 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762964988; cv=none; b=OF+27crK6HiBHwwu6svUang67QWwsnX1icYIeoHyBXmA4AKK/D3B+RcF/87dplOBSy4vXZqvkp+eQHegqFL3RiEk+4txhRFSaqTXAhLlOaZqClZFlm3c3JMHY4c907cFdQ4yEkwYSGCptiTDAd8BrcLfA1YX0ikKGjVSYanZhUI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762964988; c=relaxed/simple; bh=CE16kltFzFqjrddLzR7/Ik/75YYEnP3wOW2uBkiaABM=; h=Date:From:To:CC:Subject:In-Reply-To:References:Message-ID: MIME-Version:Content-Type; b=nGn/jF2Qw8IUIkPDwVjwmVkXhcJdOaVj+XXTULhzYbkbFoIsMisx7SjcZgCf5eOhBwNaooKzD1AqGBn4s8iNGXC5zVQ2gs+r0nIMlEf4ZVLLftZHZPPluKNiFNAkemVCmhiIkj9OqdTv5XQZ2UuGxFojbyHRmhID/QtDH/hiTdg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com; spf=pass smtp.mailfrom=zytor.com; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b=Lex7gHuB; arc=none smtp.client-ip=198.137.202.136 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=zytor.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b="Lex7gHuB" Received: from ehlo.thunderbird.net (c-76-133-66-138.hsd1.ca.comcast.net [76.133.66.138]) (authenticated bits=0) by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 5ACGT53V870373 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 12 Nov 2025 08:29:06 -0800 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 5ACGT53V870373 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2025102301; t=1762964947; bh=CE16kltFzFqjrddLzR7/Ik/75YYEnP3wOW2uBkiaABM=; h=Date:From:To:CC:Subject:In-Reply-To:References:From; b=Lex7gHuBbvK5cqsPYm7W/VXfOJuAR1NRyMhcQaqPG9PemQgiXgrJYsOmznbsnt3W5 i0YkCz88MeUXYPLmbMaSsOQbG3OJzxfcbEoL+xc1O7IzrvAed+gqC0CDixOS4qlO+c zUDwJEyxDElDMrBAbF/c4Q8tCp5/u5hANGJqkgQcZoZj+DXQxs/AdnQviySwjSMXOK KMGoQVXgHDERu+0sinl9ZSqFy0NkpGkG9NVzzcCx+npfx+ilkKyghDSUxT5ugkgqfO ap8JFS6hXAGK+ALMLR+LkFgJPyx3pZlzFQSCHYobhQqMG+6cdsFyriNEDSO6cV69uX F/HgSnHyA17GA== Date: Wed, 12 Nov 2025 08:29:05 -0800 From: "H. Peter Anvin" To: Sohil Mehta , Ard Biesheuvel CC: Dave Hansen , x86@kernel.org, Borislav Petkov , Jonathan Corbet , Andy Lutomirski , Josh Poimboeuf , Peter Zijlstra , "Kirill A . Shutemov" , Xin Li , David Woodhouse , Sean Christopherson , Rick Edgecombe , Vegard Nossum , Andrew Cooper , Randy Dunlap , Geert Uytterhoeven , Kees Cook , Tony Luck , Alexander Shishkin , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, Dave Hansen , Thomas Gleixner , Ingo Molnar Subject: =?US-ASCII?Q?Re=3A_=5BPATCH_v11_4/9=5D_x86/alternatives=3A_?= =?US-ASCII?Q?Disable_LASS_when_patching_kernel_code?= User-Agent: K-9 Mail for Android In-Reply-To: <6ab6e4d3-0caa-41e6-8231-2f3f45949876@intel.com> References: <20251029210310.1155449-1-sohil.mehta@intel.com> <20251029210310.1155449-5-sohil.mehta@intel.com> <29f2d16f-361f-475c-957e-0ebcefcd1a8c@intel.com> <7c26ae81-3495-457b-9f64-f5b2e169a63b@intel.com> <6ab6e4d3-0caa-41e6-8231-2f3f45949876@intel.com> Message-ID: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On November 12, 2025 8:18:20 AM PST, Sohil Mehta wrote: >On 11/12/2025 7:28 AM, Ard Biesheuvel wrote: > >>>> d) calling SetVirtualAddressMap() does not result in all 1:1 >>>> references being converted to the new mapping=2E >>>> >>>> >>>> To address d), the x86_64 implementation of efi_map_region() indeed >>>> maps an 1:1 alias of each remapped runtime regions, so that stray >>>> accesses don't fault=2E But the code addresses are all remapped, and = so >>>> the firmware routines are always invoked via their remapped aliases i= n >>>> the kernel VA space=2E Not calling SetVirtualAddressMap() at all, or >>>> calling it with a 1:1 mapping is not feasible, essentially because >>>> Windows doesn't do that, and that is the only thing that is tested on >>>> all x86 PCs by the respective OEMs=2E >>>> >>>> Given that remapping the code is dealt with by the firmware's PE/COFF >>>> loader, whereas remapping [dynamically allocated] data requires effor= t >>>> on the part of the programmer, I'd hazard a guess that 99=2E9% of tho= se >>>> bugs do not involve attempts to execute via the lower mapping, but >>>> stray references to data objects that were not remapped properly=2E >>>> >>>> So we might consider >>>> a) remapping those 1:1 aliases NX, so we don't have those patches of >>>> RWX memory around >>>> b) keeping LASS enabled during ordinary EFI runtime calls, as you sug= gest=2E >>> >>> Unless someone has a code pointer in their code=2E >>=20 >> That is a good point, especially because the EFI universe is >> constructed out of GUIDs and so-called protocols, which are just >> structs with function pointers=2E >>=20 >> However, EFI protocols are only supported at boot time, and the >> runtime execution context is much more restricted=2E So I'd still expec= t >> the code pointer case to be much less likely=2E > >But, that still leaves the stray data accesses=2E We would still need to >disable the LASS data access enforcement by toggling RFLAGS=2EAC during >the runtime calls=2E > >Can we rely on EFI to not mess up RFLAGS and keep the AC bit intact? Let's not muck with this now; it is lately pointless and as you can see it= 's a rathole=2E