From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl0-f70.google.com (mail-pl0-f70.google.com [209.85.160.70]) by kanga.kvack.org (Postfix) with ESMTP id CAB476B0005 for ; Tue, 19 Jun 2018 13:03:09 -0400 (EDT) Received: by mail-pl0-f70.google.com with SMTP id z5-v6so133035pln.20 for ; Tue, 19 Jun 2018 10:03:09 -0700 (PDT) Received: from mga18.intel.com (mga18.intel.com. [134.134.136.126]) by mx.google.com with ESMTPS id h8-v6si158071plr.268.2018.06.19.10.03.08 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Jun 2018 10:03:08 -0700 (PDT) Message-ID: <1529427588.23068.7.camel@intel.com> Subject: Re: [PATCH 06/10] x86/cet: Add arch_prctl functions for shadow stack From: Yu-cheng Yu Date: Tue, 19 Jun 2018 09:59:48 -0700 In-Reply-To: References: <20180607143807.3611-1-yu-cheng.yu@intel.com> <20180607143807.3611-7-yu-cheng.yu@intel.com> <1528403417.5265.35.camel@2b52.sc.intel.com> <569B4719-6283-4575-A16E-D0A78D280F4E@amacapital.net> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-mm@kvack.org List-ID: To: Kees Cook , Andy Lutomirski Cc: Andy Lutomirski , "H. J. Lu" , Thomas Gleixner , LKML , linux-doc@vger.kernel.org, Linux-MM , linux-arch , X86 ML , "H. Peter Anvin" , Ingo Molnar , "Shanbhogue, Vedvyas" , "Ravi V. Shankar" , Dave Hansen , Jonathan Corbet , Oleg Nesterov , Arnd Bergmann , mike.kravetz@oracle.com, Florian Weimer On Tue, 2018-06-19 at 09:44 -0700, Kees Cook wrote: > On Tue, Jun 19, 2018 at 7:50 AM, Andy Lutomirski > wrote: > > > > > > > > On Jun 18, 2018, at 5:52 PM, Kees Cook > > > wrote: > > > Following Linus's request for "slow introduction" of new security > > > features, likely the best approach is to default to "relaxed" > > > (with a > > > warning about down-grades), and allow distros/end-users to pick > > > "forced" if they know their libraries are all CET-enabled. > > I still dona??t get what a??relaxeda?? is for.A A I think the right design > > is: > > > > Processes start with CET on or off depending on the ELF note, but > > they start with CET unlocked no matter what. They can freely switch > > CET on and off (subject to being clever enough not to crash if they > > turn it on and then return right off the end of the shadow stack) > > until they call ARCH_CET_LOCK. > I'm fine with this. I'd expect modern loaders to just turn on CET and > ARCH_CET_LOCK immediately and be done with it. :P This is the current implementation. A If the loader has CET in its ELF header, it is executed with CET on. A The loader will turn off CET if the application being loaded does not support it (in the ELF header). A The loader calls ARCH_CET_LOCK before passing to the application. A But how do we handle dlopen? > > > > Ptrace gets new APIs to turn CET on and off and to lock and unlock > > it.A A If an attacker finds a a??ptrace me and turn off CETa?? gadget, > > then they might as well just do a??ptrace me and write shell codea?? > > instead. Ita??s basically the same gadget. Keep in mind that the > > actual sequence of syscalls to do this is incredibly complicated. > Right -- if an attacker can control ptrace of the target, we're way > past CET. The only concern I have, though, is taking advantage of > expected ptracing. For example: browsers tend to have crash handlers > that launch a ptracer. If ptracing disabled CET for all threads, this > won't by safe: an attacker just gains control in two threads, crashes > one to get the ptracer to attach, which disables CET in the other > thread and the attacker continues ROP as normal. As long as the > ptrace > disabling is thread-specific, I think this will be okay. If ptrace can turn CET on/off and it is thread-specific, do we still need ptrace lock/unlock? Yu-cheng