Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp3562260pxk; Mon, 21 Sep 2020 17:59:07 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyfNXSb5FFD36rAmx/gYtvrueyTdSRiU1hW9xlAmmQ4oBk6PsMULp3UJksVv6/BifHuhN6f X-Received: by 2002:a17:906:4bc4:: with SMTP id x4mr2342077ejv.240.1600736347542; Mon, 21 Sep 2020 17:59:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600736347; cv=none; d=google.com; s=arc-20160816; b=CXtwfxK8jt60FQ/ZuwR/K6yUQRSwcYcPZYtAweNy5JAOzkO24SWEvTepfj3nRDAQdE cLsHeu5/6VQ3NlojP08ePwfgA29es0v22DP8Ma8JCWc3NzcfyKAV3xguMxdaVFlMqK36 +ZUBr6389SoezceTBZ230ua04Qu76tLUMJMaoDRiOWraOXLWLpWmdd4CycQOxJKywk/2 VSrApL9f3/GwfhzMN7GGayg+URKMwVSyjcityNLKG/OF9299gUqGvPxy2qd9XbrRyWdU fHmMDzZi4ytSUjapxia0Y2yABAQ2vGmhDHZ7WflJosYjjvLSeB+HC+O876tWr5/5gRWi 1tzA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=00GSF6BtcKe7nkys25ldBGygRjLxKO0pud1j1TnbyXc=; b=dlgsZHrBCvvcdJ0Zs0tFnauuJ/CKHqa+h1LNfzTACJNjaR10mBIEYI3SroGefCfMVc xqC+kXoxy/apX8vZueRWlO/QHLuvBxemFrSCsYfTYArJemxWEpDpK2qpejFuA5PY7Fwp zrJKp/a0Nd5su13ZcG44KnsUqvPOnnRvB5WbETZKgVeHl64eWUe8+dtNU57tu+c2O+uX dc0XRMbrsZl7LR2+w8ExaKeS3kW8P4X1gm1x0Jsk6oVFllFJpSD1dpW2BfHss82zzebo hEPLrBqyz/E9Qyb/NjAx3ckElsMquDrbFzKSwcJuTKcCzaQzSlir3QeDPdQfd/tO/H8R q2Ew== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=goDxIMoD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i21si9251359edv.439.2020.09.21.17.58.43; Mon, 21 Sep 2020 17:59:07 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=goDxIMoD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728745AbgIUXsj (ORCPT + 99 others); Mon, 21 Sep 2020 19:48:39 -0400 Received: from mail.kernel.org ([198.145.29.99]:59210 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728672AbgIUXsj (ORCPT ); Mon, 21 Sep 2020 19:48:39 -0400 Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) (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 7D05123A82 for ; Mon, 21 Sep 2020 23:48:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1600732118; bh=N8vHQdEHpTHWvUHKpDbNH8Yi1jVK5l/yl5V+P+NE0OA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=goDxIMoDoxVa3C64VsVsoO1jj5SNv4S6MzZHZ98rF+dlRwaM2zylky7OMs58V0cIt 0k34+7+qqV1O1on10uR7KTin37l5HHeADO5pXJZJTKNV4jiznZr/kCqEdpy6SoWJMv J+loS6sIAobeIhC7PKoJMovzXnqu/F07k7RzKvZA= Received: by mail-wr1-f46.google.com with SMTP id z1so15012498wrt.3 for ; Mon, 21 Sep 2020 16:48:38 -0700 (PDT) X-Gm-Message-State: AOAM533/OFrz9t//CL2bjJPsHuwe5xcTTE0X8oDjP+TiwH4hgPFOrp5F 2i7aa/wQooRpGb/8U209p0mQYFHW765+gYY3DZPe8g== X-Received: by 2002:a5d:6a47:: with SMTP id t7mr2138226wrw.75.1600732116993; Mon, 21 Sep 2020 16:48:36 -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: <24718de58ab7bc6d7288c58d3567ad802eeb6542.camel@intel.com> From: Andy Lutomirski Date: Mon, 21 Sep 2020 16:48:25 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v12 8/8] x86: Disallow vsyscall emulation when CET is enabled To: Yu-cheng Yu 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-kernel@vger.kernel.org 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: > > On 9/18/2020 5:11 PM, Andy Lutomirski wrote: > > > On Fri, Sep 18, 2020 at 12:23 PM Yu-cheng Yu wrote: > > > > Emulation of the legacy vsyscall page is required by some programs > > > > built before 2013. Newer programs after 2013 don't use it. > > > > Disable vsyscall emulation when Control-flow Enforcement (CET) is > > > > enabled to enhance security. > > > > > > > > Signed-off-by: Yu-cheng Yu > [...] > > > > > > Nope, try again. Having IBT on does *not* mean that every library in > > > the process knows that we have indirect branch tracking. The legacy > > > bitmap exists for a reason. Also, I want a way to flag programs as > > > not using the vsyscall page, but that flag should not be called CET. > > > And a process with vsyscalls off should not be able to read the > > > vsyscall page, and /proc/self/maps should be correct. > > > > > > So you have some choices: > > > > > > 1. Drop this patch and make it work. > > > > > > 2. Add a real per-process vsyscall control. Either make it depend on > > > vsyscall=xonly and wire it up correctly or actually make it work > > > correctly with vsyscall=emulate. > > > > > > NAK to any hacks in this space. Do it right or don't do it at all. > > > > > > > We can drop this patch, and bring back the previous patch that fixes up > > shadow stack and ibt. That makes vsyscall emulation work correctly, and > > does not force the application to do anything different from what is > > working now. I will post the previous patch as a reply to this thread > > so that people can make comments on it. > > > > Yu-cheng > > 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? > + > +#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.