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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED 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 CBAC6C5CFC1 for ; Tue, 19 Jun 2018 17:03:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8F30120652 for ; Tue, 19 Jun 2018 17:03:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8F30120652 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S967044AbeFSRDK (ORCPT ); Tue, 19 Jun 2018 13:03:10 -0400 Received: from mga12.intel.com ([192.55.52.136]:22922 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966775AbeFSRDI (ORCPT ); Tue, 19 Jun 2018 13:03:08 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jun 2018 10:03:07 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,243,1526367600"; d="scan'208";a="48294842" Received: from 2b52.sc.intel.com ([143.183.136.147]) by fmsmga007.fm.intel.com with ESMTP; 19 Jun 2018 10:03:07 -0700 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 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 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" X-Mailer: Evolution 3.18.5.2-0ubuntu3.2 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 don’t get what “relaxed” is for.  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.  If the loader has CET in its ELF header, it is executed with CET on.  The loader will turn off CET if the application being loaded does not support it (in the ELF header).  The loader calls ARCH_CET_LOCK before passing to the application.  But how do we handle dlopen? > > > > Ptrace gets new APIs to turn CET on and off and to lock and unlock > > it.  If an attacker finds a “ptrace me and turn off CET” gadget, > > then they might as well just do “ptrace me and write shell code” > > instead. It’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