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,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 7BAA7C4363D for ; Wed, 23 Sep 2020 21:35:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 30EB62311A for ; Wed, 23 Sep 2020 21:35:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1600896902; bh=K3EiV2+i9l9fYhhP6vZIZ7TO6ZkrF/uEBL+okHQVlPQ=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=QTZ2lL0A73usQczZ1WB+CswsFavqR+kHUqT69udFz2WwvQa0kedxAWKxQmV0n/jZX qC1eHqkifN2WBzM3rb0GttI7QRuKrimy+kI00r2rdBaaoKw8pp160FaaoVJuZSKyqS qNXn3AklBssuuDRCX+7k5jaHy3AqEj2NCS1Dq2Cg= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726691AbgIWVe6 (ORCPT ); Wed, 23 Sep 2020 17:34:58 -0400 Received: from mail.kernel.org ([198.145.29.99]:56300 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726572AbgIWVe6 (ORCPT ); Wed, 23 Sep 2020 17:34:58 -0400 Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id CD5F3238A1 for ; Wed, 23 Sep 2020 21:34:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1600896897; bh=K3EiV2+i9l9fYhhP6vZIZ7TO6ZkrF/uEBL+okHQVlPQ=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=Ujf5QnyE9ozyeO63lNVfcHgSuZWq4kLYhNj8yCH/l/GxggbLRqaHjG3tfyGsNwkAs /3eDOzWcZTh8f3gCOD8zu+ZTETyzg7Pd20RNC1LvCr9fRAu1YUJpj1QQUzQkr4di7N BAI02qlhlOGufa1Q/1PBd0f89tJvj4m4oXfajmTs= Received: by mail-wr1-f52.google.com with SMTP id g4so1549000wrs.5 for ; Wed, 23 Sep 2020 14:34:56 -0700 (PDT) X-Gm-Message-State: AOAM532izoaN7g94hLmiT2XDzmopIRKlJmvPUR6oCX347K2O9I92Tt7u XNQntwtiue0Z6Cs1cyKBO6gPk3ZaDM0MB3AaKxBW/Q== X-Google-Smtp-Source: ABdhPJyfQsGZbyi4V01pz1OVEaeeFMqLVS6c+RfyIwko8Czk8CD8ZGTZnfdpdZtjBo1QLuIeZl5Z60Sb9PZVsHax7bU= X-Received: by 2002:adf:a3c3:: with SMTP id m3mr1646948wrb.70.1600896895213; Wed, 23 Sep 2020 14:34:55 -0700 (PDT) MIME-Version: 1.0 References: <20200918192312.25978-1-yu-cheng.yu@intel.com> <20200918192312.25978-9-yu-cheng.yu@intel.com> <24718de58ab7bc6d7288c58d3567ad802eeb6542.camel@intel.com> In-Reply-To: From: Andy Lutomirski Date: Wed, 23 Sep 2020 14:34:43 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v12 8/8] x86: Disallow vsyscall emulation when CET is enabled To: "Yu, Yu-cheng" Cc: Andy Lutomirski , 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 Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org On Tue, Sep 22, 2020 at 10:46 AM Yu, Yu-cheng wrote: > > 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? Yes. > > > > >> + > >> +#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? Performance is almost irrelevant here, and the writing-to-XSAVES-area approach should have the benefit that the exception handling and signaling happens for free.