From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BE753C4363D for ; Tue, 22 Sep 2020 17:46:12 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 38F5E2311C for ; Tue, 22 Sep 2020 17:46:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 38F5E2311C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 6EBC88E0003; Tue, 22 Sep 2020 13:46:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6753E8E0001; Tue, 22 Sep 2020 13:46:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5639D8E0003; Tue, 22 Sep 2020 13:46:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0169.hostedemail.com [216.40.44.169]) by kanga.kvack.org (Postfix) with ESMTP id 3D22A8E0001 for ; Tue, 22 Sep 2020 13:46:11 -0400 (EDT) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id B6238181AC9CC for ; Tue, 22 Sep 2020 17:46:10 +0000 (UTC) X-FDA: 77291426100.19.pull75_41020f62714f Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin19.hostedemail.com (Postfix) with ESMTP id 7A5431AD1B4 for ; Tue, 22 Sep 2020 17:46:10 +0000 (UTC) X-HE-Tag: pull75_41020f62714f X-Filterd-Recvd-Size: 6536 Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by imf26.hostedemail.com (Postfix) with ESMTP for ; Tue, 22 Sep 2020 17:46:08 +0000 (UTC) IronPort-SDR: RPDFL1iyC4dGYCKajcqVgz+4BR8vWl0mN18YF1jZndIjNr5wJ4tKnpPRtGVS3MDlpuNd5jTbcJ l/M6BT6wv/UQ== X-IronPort-AV: E=McAfee;i="6000,8403,9752"; a="159963440" X-IronPort-AV: E=Sophos;i="5.77,291,1596524400"; d="scan'208";a="159963440" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Sep 2020 10:46:07 -0700 IronPort-SDR: cl3J1vrQxK6j9eatSzkcM3aWlDAGlEZlhvCyZw5bQHzatpPHt4Eyde/NhcZaceDzlVC+tQSURd ndgIUZ9ibZrA== X-IronPort-AV: E=Sophos;i="5.77,291,1596524400"; d="scan'208";a="511310613" Received: from yyu32-mobl1.amr.corp.intel.com (HELO [10.212.107.156]) ([10.212.107.156]) by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Sep 2020 10:46:06 -0700 Subject: Re: [PATCH v12 8/8] x86: Disallow vsyscall emulation when CET is enabled To: Andy Lutomirski Cc: X86 ML , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , LKML , "open list:DOCUMENTATION" , Linux-MM , linux-arch , Linux API , Arnd Bergmann , Balbir Singh , Borislav Petkov , Cyrill Gorcunov , Dave Hansen , Eugene Syromiatnikov , Florian Weimer , "H.J. Lu" , Jann Horn , Jonathan Corbet , Kees Cook , Mike Kravetz , Nadav Amit , Oleg Nesterov , Pavel Machek , Peter Zijlstra , Randy Dunlap , "Ravi V. Shankar" , Vedvyas Shanbhogue , Dave Martin , Weijiang Yang References: <20200918192312.25978-1-yu-cheng.yu@intel.com> <20200918192312.25978-9-yu-cheng.yu@intel.com> <24718de58ab7bc6d7288c58d3567ad802eeb6542.camel@intel.com> From: "Yu, Yu-cheng" Message-ID: Date: Tue, 22 Sep 2020 10:45:54 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 9/21/2020 4:48 PM, Andy Lutomirski wrote: > On Mon, Sep 21, 2020 at 3:37 PM Yu-cheng Yu wrote: >> >> On Mon, 2020-09-21 at 09:22 -0700, Yu, Yu-cheng wrote: [...] >> >> Here is the patch: >> >> ------ >> >> From dfdee39c795ee5dcee2c77f6ba344a61f4d8124b Mon Sep 17 00:00:00 2001 >> From: Yu-cheng Yu >> Date: Thu, 29 Nov 2018 14:15:38 -0800 >> Subject: [PATCH 34/43] x86/vsyscall/64: Fixup Shadow Stack and Indirect Branch >> Tracking for vsyscall emulation >> >> Vsyscall entry points are effectively branch targets. Mark them with >> ENDBR64 opcodes. When emulating the RET instruction, unwind the shadow >> stack and reset IBT state machine. >> >> Signed-off-by: Yu-cheng Yu >> --- >> arch/x86/entry/vsyscall/vsyscall_64.c | 29 +++++++++++++++++++++++ >> arch/x86/entry/vsyscall/vsyscall_emu_64.S | 9 +++++++ >> arch/x86/entry/vsyscall/vsyscall_trace.h | 1 + >> 3 files changed, 39 insertions(+) >> >> diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c >> b/arch/x86/entry/vsyscall/vsyscall_64.c >> index 44c33103a955..0131c9f7f9c5 100644 >> --- a/arch/x86/entry/vsyscall/vsyscall_64.c >> +++ b/arch/x86/entry/vsyscall/vsyscall_64.c >> @@ -38,6 +38,9 @@ >> #include >> #include >> #include >> +#include >> +#include >> +#include >> >> #define CREATE_TRACE_POINTS >> #include "vsyscall_trace.h" >> @@ -286,6 +289,32 @@ bool emulate_vsyscall(unsigned long error_code, >> /* Emulate a ret instruction. */ >> regs->ip = caller; >> regs->sp += 8; >> + >> + if (current->thread.cet.shstk_size || >> + current->thread.cet.ibt_enabled) { >> + u64 r; >> + >> + fpregs_lock(); >> + if (test_thread_flag(TIF_NEED_FPU_LOAD)) >> + __fpregs_load_activate(); > > Wouldn't this be nicer if you operated on the memory image, not the registers? Do you mean writing to the XSAVES area? > >> + >> +#ifdef CONFIG_X86_INTEL_BRANCH_TRACKING_USER >> + /* Fixup branch tracking */ >> + if (current->thread.cet.ibt_enabled) { >> + rdmsrl(MSR_IA32_U_CET, r); >> + wrmsrl(MSR_IA32_U_CET, r & ~CET_WAIT_ENDBR); >> + } >> +#endif > > Seems reasonable on first glance. > >> + >> +#ifdef CONFIG_X86_INTEL_SHADOW_STACK_USER >> + /* Unwind shadow stack. */ >> + if (current->thread.cet.shstk_size) { >> + rdmsrl(MSR_IA32_PL3_SSP, r); >> + wrmsrl(MSR_IA32_PL3_SSP, r + 8); >> + } >> +#endif > > What happens if the result is noncanonical? A quick skim of the SDM > didn't find anything. This latter issue goes away if you operate on > the memory image, though -- writing a bogus value is just fine, since > the FP restore will handle it. > At this point, the MSR's value can still be valid or is already saved to memory. If we are going to write to memory, then the MSR must be saved first. So I chose to do __fpregs_load_activate() and write the MSR. Maybe we can check the address before writing it to the MSR? Yu-cheng