From nobody Sun Feb 8 17:24:16 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B70FAC6379F for ; Tue, 10 Jan 2023 05:57:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231388AbjAJF5h (ORCPT ); Tue, 10 Jan 2023 00:57:37 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58252 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234856AbjAJF4T (ORCPT ); Tue, 10 Jan 2023 00:56:19 -0500 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C1CFC3A1 for ; Mon, 9 Jan 2023 21:55:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1673330151; x=1704866151; h=from:to:subject:date:message-id:in-reply-to:references: mime-version:content-transfer-encoding; bh=4Rwgi+OKzj2DOZptaBAy1t4dcVeX1NSbFy3ySQuJdfs=; b=lOZAkj8TRLY+vA+brpUAZJ9/hla4vgGB4WjLEOUxXhtjifY0QNAXE1Ux SL+m5WpwZlHWH20Xi77XY5p6B+HVATgTKX/wnZvwX42rcOHUCykFCkCOA LiclG8a5Oq2xOFeXfOqJFU9c9/WAXyPz/0Su2fIziobVAk40hNT7ASdxa HZgWeQg62QGmfo9Nq8pVYGq6fyf1y1+ddxJpnQczwLqWGEv8ZgEshC+J9 If6iRdFNayLA3OaoEDcEOvChrwRA4IzHp+HjE2Jd8H9vscGJ1Gps9tF6D N6zMivVa6yjiz55d/WwLwzU0SUr/HS3+rGE9/+Z44HbAKThnXK9meWnAT w==; X-IronPort-AV: E=McAfee;i="6500,9779,10585"; a="350289961" X-IronPort-AV: E=Sophos;i="5.96,314,1665471600"; d="scan'208";a="350289961" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Jan 2023 21:55:40 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10585"; a="634483745" X-IronPort-AV: E=Sophos;i="5.96,314,1665471600"; d="scan'208";a="634483745" Received: from oux.sc.intel.com ([10.3.52.57]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Jan 2023 21:55:40 -0800 From: Yian Chen To: linux-kernel@vger.kernel.org, x86@kernel.org, Andy Lutomirski , Dave Hansen , Ravi Shankar , Tony Luck , Sohil Mehta , Paul Lai , Yian Chen Subject: [PATCH 4/7] x86/vsyscall: Setup vsyscall to compromise LASS protection Date: Mon, 9 Jan 2023 21:52:01 -0800 Message-Id: <20230110055204.3227669-5-yian.chen@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230110055204.3227669-1-yian.chen@intel.com> References: <20230110055204.3227669-1-yian.chen@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" Kernel enables LASS automatically at starting time in LASS capable platforms. Any access to kernel addresses or upper half addresses from user space triggers a #GP fault. Legacy vsyscall does not comply with LASS, because the vsyscall functions are mapped in the range 0xffffffffff600000-0xffffffffff601000. In theory, it would be possible to write a #GP fault handler to emulate the old vsyscall behavior, but vsyscall has been deprecated for some time, so this has not been done. Therefore, when kernel enforces LASS, vsyscall does not work and should be disabled. On the other hand, the user can relax the enforcement by clearing lass cpu id (clearcpuid=3Dlass/390) or enabling vsyscall (vsyscall=3Dxxx) from kernel command line. The user can also opt-out LASS in config file to build kernel binary. Signed-off-by: Yian Chen Reviewed-by: Tony Luck --- Documentation/admin-guide/kernel-parameters.txt | 12 ++++++++---- arch/x86/entry/vsyscall/vsyscall_64.c | 14 ++++++++++++++ 2 files changed, 22 insertions(+), 4 deletions(-) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentatio= n/admin-guide/kernel-parameters.txt index 6cfa6e3996cf..3988e0c8c175 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -6755,10 +6755,14 @@ versions of glibc use these calls. Because these functions are at fixed addresses, they make nice targets for exploits that can control RIP. - - emulate [default] Vsyscalls turn into traps and are - emulated reasonably safely. The vsyscall - page is readable. + In newer versions of Intel platforms that come with + LASS(Linear Address Space separation) protection, + vsyscall is disabled by default. Enabling vsyscall + via the parameter overrides LASS protection. + + emulate [default if not LASS capable] Vsyscalls + turn into traps and are emulated reasonably + safely. The vsyscall page is readable. =20 xonly Vsyscalls turn into traps and are emulated reasonably safely. The vsyscall diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c b/arch/x86/entry/vsyscal= l/vsyscall_64.c index 4af81df133ee..2691f26835d1 100644 --- a/arch/x86/entry/vsyscall/vsyscall_64.c +++ b/arch/x86/entry/vsyscall/vsyscall_64.c @@ -63,6 +63,12 @@ static int __init vsyscall_setup(char *str) else return -EINVAL; =20 + if (cpu_feature_enabled(X86_FEATURE_LASS) && + vsyscall_mode !=3D NONE) { + setup_clear_cpu_cap(X86_FEATURE_LASS); + pr_warn("LASS disabled by command line enabling vsyscall\n"); + } + return 0; } =20 @@ -379,6 +385,14 @@ void __init map_vsyscall(void) extern char __vsyscall_page; unsigned long physaddr_vsyscall =3D __pa_symbol(&__vsyscall_page); =20 + /* + * When LASS is on, vsyscall triggers a #GP fault, + * so that force vsyscall_mode to NONE. + */ + if (cpu_feature_enabled(X86_FEATURE_LASS)) { + vsyscall_mode =3D NONE; + return; + } /* * For full emulation, the page needs to exist for real. In * execute-only mode, there is no PTE at all backing the vsyscall --=20 2.34.1