From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot0-f197.google.com (mail-ot0-f197.google.com [74.125.82.197]) by kanga.kvack.org (Postfix) with ESMTP id C52496B0007 for ; Fri, 8 Jun 2018 08:17:40 -0400 (EDT) Received: by mail-ot0-f197.google.com with SMTP id h3-v6so8555491otj.15 for ; Fri, 08 Jun 2018 05:17:40 -0700 (PDT) Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id i25-v6sor7388558otc.94.2018.06.08.05.17.39 for (Google Transport Security); Fri, 08 Jun 2018 05:17:39 -0700 (PDT) MIME-Version: 1.0 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> From: "H.J. Lu" Date: Fri, 8 Jun 2018 05:17:38 -0700 Message-ID: Subject: Re: [PATCH 06/10] x86/cet: Add arch_prctl functions for shadow stack Content-Type: text/plain; charset="UTF-8" Sender: owner-linux-mm@kvack.org List-ID: To: Andy Lutomirski Cc: Yu-cheng Yu , LKML , linux-doc@vger.kernel.org, Linux-MM , linux-arch , X86 ML , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , "Shanbhogue, Vedvyas" , "Ravi V. Shankar" , Dave Hansen , Jonathan Corbet , Oleg Nesterov , Arnd Bergmann , mike.kravetz@oracle.com On Thu, Jun 7, 2018 at 9:35 PM, Andy Lutomirski wrote: > On Thu, Jun 7, 2018 at 9:22 PM H.J. Lu wrote: >> >> On Thu, Jun 7, 2018 at 3:02 PM, H.J. Lu wrote: >> > On Thu, Jun 7, 2018 at 2:01 PM, Andy Lutomirski wrote: >> >> On Thu, Jun 7, 2018 at 1:33 PM Yu-cheng Yu wrote: >> >>> >> >>> On Thu, 2018-06-07 at 11:48 -0700, Andy Lutomirski wrote: >> >>> > On Thu, Jun 7, 2018 at 7:41 AM Yu-cheng Yu wrote: >> >>> > > >> >>> > > The following operations are provided. >> >>> > > >> >>> > > ARCH_CET_STATUS: >> >>> > > return the current CET status >> >>> > > >> >>> > > ARCH_CET_DISABLE: >> >>> > > disable CET features >> >>> > > >> >>> > > ARCH_CET_LOCK: >> >>> > > lock out CET features >> >>> > > >> >>> > > ARCH_CET_EXEC: >> >>> > > set CET features for exec() >> >>> > > >> >>> > > ARCH_CET_ALLOC_SHSTK: >> >>> > > allocate a new shadow stack >> >>> > > >> >>> > > ARCH_CET_PUSH_SHSTK: >> >>> > > put a return address on shadow stack >> >>> > > >> >> >> And why do we need ARCH_CET_EXEC? >> >> >> >> For background, I really really dislike adding new state that persists >> >> across exec(). It's nice to get as close to a clean slate as possible >> >> after exec() so that programs can run in a predictable environment. >> >> exec() is also a security boundary, and anything a task can do to >> >> affect itself after exec() needs to have its security implications >> >> considered very carefully. (As a trivial example, you should not be >> >> able to use cetcmd ... sudo [malicious options here] to cause sudo to >> >> run with CET off and then try to exploit it via the malicious options. >> >> >> >> If a shutoff is needed for testing, how about teaching ld.so to parse >> >> LD_CET=no or similar and protect it the same way as LD_PRELOAD is >> >> protected. Or just do LD_PRELOAD=/lib/libdoesntsupportcet.so. >> >> >> > >> > I will take a look. >> >> We can use LD_CET to turn off CET. Since most of legacy binaries >> are compatible with shadow stack, ARCH_CET_EXEC can be used >> to turn on shadow stack on legacy binaries: > > Is there any reason you can't use LD_CET=force to do it for > dynamically linked binaries? We need to enable shadow stack from the start. Otherwise function return will fail when returning from callee with shadow stack to caller without shadow stack. > I find it quite hard to believe that forcibly CET-ifying a legacy > statically linked binary is a good idea. We'd like to provide protection as much as we can. -- H.J.