From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (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 A05D317D355; Tue, 29 Oct 2024 17:15:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730222103; cv=none; b=awjg/v+DniR5yjSa/QjimRqEWlIjE0U4huiKWt5lJE4mISyY4NbcaABKpc64eUKF6H1Zk4RGsBIFguNGkhopVRwO7BjAwarOBYivCRFGtjOjtosKtAmuggRybozI9VmFf31fdA6BGvUkuRwvkpysMY7sQvQYebXYaTN9o1qcms8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730222103; c=relaxed/simple; bh=LqBQA0ivqqH8ZyZKx0n8JFFG1U13mopJfiR3HfDtNN8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=p1+uIZ/xCowFLb8aloz5DEynaEnnvxKfHXNxxVNFrTBz/p5+AS3wBiqvumLyIpwseT523SpVYwc+DuIp5xFQT1bdXQ8VNukgUP15Wgx4Rvo+g1CSOQcIXoApcWUc5G8wmi/q93u3Up3rgCTAhOrgZaR/hVPo34D2ze9euE1XLNA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=qtaDdZ5z; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="qtaDdZ5z" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=xq2/wRVUsy2jaJ29qDqN+mT7DMusIDqIZXNyENoMByg=; b=qtaDdZ5zpgOd3Fw3eXc6aoAx08 7t8FDzzNCE0NIsKqBHdowmPclK+I/eJDA6qgV0AheD0UMouI0NmMmSWmTb5921yCpVk2vjYVoGv2/ bpRTRLxm0o8Vh7eUQG78LVeUYniTIz7yHeGs5gdP8MIOxVkZdlF9Y2B6TZ4t+wcL8yrKJkOHPwShV scBms6uZyZ84HMIbFXBaiwD3uEAhFRzDhr1GQgdiJkAD4a66u7wwPFCvn1K4VR43CZHaYbn1j7SnH pK+WudxVw9mP218BIiDoYZUIgSIGRBdhsl+aXUvBXIkuMQSWQnh2kHC8V2BJkkCHqWqq7AAVNMM49 /fjt8Eow==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1t5pnG-0000000A2WL-0jJ5; Tue, 29 Oct 2024 17:14:10 +0000 Date: Tue, 29 Oct 2024 17:14:09 +0000 From: Matthew Wilcox To: Alexander Shishkin Cc: Andy Lutomirski , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Peter Zijlstra , Ard Biesheuvel , "Paul E. McKenney" , Josh Poimboeuf , Xiongwei Song , Xin Li , "Mike Rapoport (IBM)" , Brijesh Singh , Michael Roth , Tony Luck , "Kirill A. Shutemov" , Alexey Kardashevskiy , Jonathan Corbet , Sohil Mehta , Ingo Molnar , Pawan Gupta , Daniel Sneddon , Kai Huang , Sandipan Das , Breno Leitao , Rick Edgecombe , Alexei Starovoitov , Hou Tao , Juergen Gross , Vegard Nossum , Kees Cook , Eric Biggers , Jason Gunthorpe , "Masami Hiramatsu (Google)" , Andrew Morton , Luis Chamberlain , Yuntao Wang , Rasmus Villemoes , Christophe Leroy , Tejun Heo , Changbin Du , Huang Shijie , Geert Uytterhoeven , Namhyung Kim , Arnaldo Carvalho de Melo , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org Subject: Re: [PATCH v5 00/16] Enable Linear Address Space Separation support Message-ID: References: <20241028160917.1380714-1-alexander.shishkin@linux.intel.com> 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=us-ascii Content-Disposition: inline In-Reply-To: <20241028160917.1380714-1-alexander.shishkin@linux.intel.com> On Mon, Oct 28, 2024 at 06:07:48PM +0200, Alexander Shishkin wrote: > Linear Address Space Separation (LASS) is a security feature that intends to > prevent malicious virtual address space accesses across user/kernel mode. > > Such mode based access protection already exists today with paging and features > such as SMEP and SMAP. However, to enforce these protections, the processor > must traverse the paging structures in memory. Malicious software can use > timing information resulting from this traversal to determine details about the > paging structures, and these details may also be used to determine the layout > of the kernel memory. > > The LASS mechanism provides the same mode-based protections as paging but > without traversing the paging structures. Because the protections enforced by > LASS are applied before paging, software will not be able to derive > paging-based timing information from the various caching structures such as the > TLBs, mid-level caches, page walker, data caches, etc. LASS can avoid probing > using double page faults, TLB flush and reload, and SW prefetch instructions. > See [2], [3] and [4] for some research on the related attack vectors. > > In addition, LASS prevents an attack vector described in a Spectre LAM (SLAM) > whitepaper [7]. > > LASS enforcement relies on the typical kernel implemetation to divide the > 64-bit virtual address space into two halves: > Addr[63]=0 -> User address space > Addr[63]=1 -> Kernel address space > Any data access or code execution across address spaces typically results in a > #GP fault. > > Kernel accesses usually only happen to the kernel address space. However, there > are valid reasons for kernel to access memory in the user half. For these cases > (such as text poking and EFI runtime accesses), the kernel can temporarily > suspend the enforcement of LASS by toggling SMAP (Supervisor Mode Access > Prevention) using the stac()/clac() instructions and in one instance a downright > disabling LASS for an EFI runtime call. > > User space cannot access any kernel address while LASS is enabled. > Unfortunately, legacy vsyscall functions are located in the address range > 0xffffffffff600000 - 0xffffffffff601000 and emulated in kernel. To avoid > breaking user applications when LASS is enabled, extend the vsyscall emulation > in execute (XONLY) mode to the #GP fault handler. > > In contrast, the vsyscall EMULATE mode is deprecated and not expected to be > used by anyone. Supporting EMULATE mode with LASS would need complex > intruction decoding in the #GP fault handler and is probably not worth the > hassle. Disable LASS in this rare case when someone absolutely needs and > enables vsyscall=emulate via the command line. I lack the wit to read & understand these patches to answer this question, so I'll just ask it: What happens when the kernel does a NULL pointer dereference (due to a bug)? It's not an attempt to access userspace, but it should result in a good bug report. Normally this would be outside a STAC/CLAC region, but I suppose technically it could be within one.