LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Andy Lutomirski <luto@kernel.org>
To: "H. J. Lu" <hjl.tools@gmail.com>
Cc: Andrew Lutomirski <luto@kernel.org>,
	Yu-cheng Yu <yu-cheng.yu@intel.com>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-doc@vger.kernel.org, Linux-MM <linux-mm@kvack.org>,
	linux-arch <linux-arch@vger.kernel.org>, X86 ML <x86@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	"Shanbhogue, Vedvyas" <vedvyas.shanbhogue@intel.com>,
	"Ravi V. Shankar" <ravi.v.shankar@intel.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Jonathan Corbet <corbet@lwn.net>, Oleg Nesterov <oleg@redhat.com>,
	Arnd Bergmann <arnd@arndb.de>,
	mike.kravetz@oracle.com
Subject: Re: [PATCH 06/10] x86/cet: Add arch_prctl functions for shadow stack
Date: Thu, 7 Jun 2018 21:38:03 -0700	[thread overview]
Message-ID: <CALCETrWhMmqGWKx-yw55YKHMJwGyLZio5f8Pskh8X69zfQMy7A@mail.gmail.com> (raw)
In-Reply-To: <CAMe9rOpeDrkwi-AG0vsiZy4NwkmavhB5Empv58FSHxtr3rpapw@mail.gmail.com>

On Thu, Jun 7, 2018 at 9:10 PM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Thu, Jun 7, 2018 at 4:01 PM, Andy Lutomirski <luto@kernel.org> wrote:
> > On Thu, Jun 7, 2018 at 3:02 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> >>
> >> On Thu, Jun 7, 2018 at 2:01 PM, Andy Lutomirski <luto@kernel.org> wrote:
> >> > On Thu, Jun 7, 2018 at 1:33 PM Yu-cheng Yu <yu-cheng.yu@intel.com> 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 <yu-cheng.yu@intel.com> 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
> >> >> > >
> >> >> > > ARCH_CET_ALLOC_SHSTK and ARCH_CET_PUSH_SHSTK are intended only for
> >> >> > > the implementation of GLIBC ucontext related APIs.
> >> >> >
> >> >> > Please document exactly what these all do and why.  I don't understand
> >> >> > what purpose ARCH_CET_LOCK and ARCH_CET_EXEC serve.  CET is opt in for
> >> >> > each ELF program, so I think there should be no need for a magic
> >> >> > override.
> >> >>
> >> >> CET is initially enabled if the loader has CET capability.  Then the
> >> >> loader decides if the application can run with CET.  If the application
> >> >> cannot run with CET (e.g. a dependent library does not have CET), then
> >> >> the loader turns off CET before passing to the application.  When the
> >> >> loader is done, it locks out CET and the feature cannot be turned off
> >> >> anymore until the next exec() call.
> >> >
> >> > Why is the lockout necessary?  If user code enables CET and tries to
> >> > run code that doesn't support CET, it will crash.  I don't see why we
> >> > need special code in the kernel to prevent a user program from calling
> >> > arch_prctl() and crashing itself.  There are already plenty of ways to
> >> > do that :)
> >>
> >> On CET enabled machine, not all programs nor shared libraries are
> >> CET enabled.  But since ld.so is CET enabled, all programs start
> >> as CET enabled.  ld.so will disable CET if a program or any of its shared
> >> libraries aren't CET enabled.  ld.so will lock up CET once it is done CET
> >> checking so that CET can't no longer be disabled afterwards.
> >
> > Yeah, I got that.  No one has explained *why*.
>
> It is to prevent malicious code from disabling CET.
>

By the time malicious code issue its own syscalls, you've already lost
the battle.  I could probably be convinced that a lock-CET-on feature
that applies *only* to the calling thread and is not inherited by
clone() is a decent idea, but I'd want to see someone who understands
the state of the art in exploit design justify it.  You're also going
to need to figure out how to make CRIU work if you allow locking CET
on.

A priori, I think we should just not provide a lock mechanism.

> > (Also, shouldn't the vDSO itself be marked as supporting CET?)
>
> No. vDSO is loaded by kernel.  vDSO in CET kernel is CET
> compatible.
>

I think the vDSO should do its best to act like a real DSO.  That
means that, if the vDSO supports CET, it should advertise support for
CET using the Linux ABI.  Since you're going to require GCC 8 anyway,
this should be a single line of code in the Makefile.

  reply	other threads:[~2018-06-08  4:38 UTC|newest]

Thread overview: 98+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-07 14:37 [PATCH 00/10] Control Flow Enforcement - Part (3) Yu-cheng Yu
2018-06-07 14:37 ` [PATCH 01/10] x86/cet: User-mode shadow stack support Yu-cheng Yu
2018-06-07 16:37   ` Andy Lutomirski
2018-06-07 17:46     ` Yu-cheng Yu
2018-06-07 17:55       ` Dave Hansen
2018-06-07 18:23       ` Andy Lutomirski
2018-06-12 11:56   ` Balbir Singh
2018-06-12 15:03     ` Yu-cheng Yu
2018-06-07 14:37 ` [PATCH 02/10] x86/cet: Introduce WRUSS instruction Yu-cheng Yu
2018-06-07 16:40   ` Andy Lutomirski
2018-06-07 16:51     ` Yu-cheng Yu
2018-06-07 18:41     ` Peter Zijlstra
2018-06-07 20:31       ` Yu-cheng Yu
2018-06-11  8:17     ` Peter Zijlstra
2018-06-11 15:02       ` Yu-cheng Yu
2018-06-14  1:30   ` Balbir Singh
2018-06-14 14:43     ` Yu-cheng Yu
2018-06-07 14:38 ` [PATCH 03/10] x86/cet: Signal handling for shadow stack Yu-cheng Yu
2018-06-07 18:30   ` Andy Lutomirski
2018-06-07 18:58     ` Florian Weimer
2018-06-07 19:51       ` Yu-cheng Yu
2018-06-07 20:07     ` Cyrill Gorcunov
2018-06-07 20:57       ` Andy Lutomirski
2018-06-08 12:07         ` Cyrill Gorcunov
2018-06-07 20:12     ` Yu-cheng Yu
2018-06-07 20:17       ` Dave Hansen
2018-06-07 14:38 ` [PATCH 04/10] x86/cet: Handle thread " Yu-cheng Yu
2018-06-07 18:21   ` Andy Lutomirski
2018-06-07 19:47     ` Florian Weimer
2018-06-07 20:53       ` Andy Lutomirski
2018-06-08 14:53         ` Florian Weimer
2018-06-08 15:01           ` Andy Lutomirski
2018-06-08 15:50             ` Yu-cheng Yu
2018-06-07 14:38 ` [PATCH 05/10] x86/cet: ELF header parsing of Control Flow Enforcement Yu-cheng Yu
2018-06-07 18:38   ` Andy Lutomirski
2018-06-07 20:40     ` Yu-cheng Yu
2018-06-07 14:38 ` [PATCH 06/10] x86/cet: Add arch_prctl functions for shadow stack Yu-cheng Yu
2018-06-07 18:48   ` Andy Lutomirski
2018-06-07 20:30     ` Yu-cheng Yu
2018-06-07 21:01       ` Andy Lutomirski
2018-06-07 22:02         ` H.J. Lu
2018-06-07 23:01           ` Andy Lutomirski
2018-06-08  4:09             ` H.J. Lu
2018-06-08  4:38               ` Andy Lutomirski [this message]
2018-06-08 12:24                 ` H.J. Lu
2018-06-08 14:57                   ` Andy Lutomirski
2018-06-08 15:52                     ` Cyrill Gorcunov
2018-06-08  4:22           ` H.J. Lu
2018-06-08  4:35             ` Andy Lutomirski
2018-06-08 12:17               ` H.J. Lu
2018-06-12 10:03           ` Thomas Gleixner
2018-06-12 11:43             ` H.J. Lu
2018-06-12 16:01               ` Andy Lutomirski
2018-06-12 16:05                 ` H.J. Lu
2018-06-12 16:34                   ` Andy Lutomirski
2018-06-12 16:51                     ` H.J. Lu
2018-06-12 18:59                       ` Thomas Gleixner
2018-06-12 19:34                         ` H.J. Lu
2018-06-18 22:03                           ` Andy Lutomirski
2018-06-19  0:52                             ` Kees Cook
2018-06-19  6:40                               ` Florian Weimer
2018-06-19 14:50                               ` Andy Lutomirski
2018-06-19 16:44                                 ` Kees Cook
2018-06-19 16:59                                   ` Yu-cheng Yu
2018-06-19 17:07                                     ` Kees Cook
2018-06-19 17:20                                       ` Andy Lutomirski
2018-06-19 20:12                                         ` Kees Cook
2018-06-19 20:47                                           ` Andy Lutomirski
2018-06-19 22:38                                             ` Yu-cheng Yu
2018-06-20  0:50                                               ` Andy Lutomirski
2018-06-21 23:07                                                 ` Yu-cheng Yu
2018-06-07 14:38 ` [PATCH 07/10] mm: Prevent mprotect from changing " Yu-cheng Yu
2018-06-07 14:38 ` [PATCH 08/10] mm: Prevent mremap of " Yu-cheng Yu
2018-06-07 18:48   ` Andy Lutomirski
2018-06-07 20:18     ` Yu-cheng Yu
2018-06-07 14:38 ` [PATCH 09/10] mm: Prevent madvise from changing " Yu-cheng Yu
2018-06-07 20:54   ` Andy Lutomirski
2018-06-07 21:09   ` Nadav Amit
2018-06-07 21:18     ` Yu-cheng Yu
2018-06-07 14:38 ` [PATCH 10/10] mm: Prevent munmap and remap_file_pages of " Yu-cheng Yu
2018-06-07 18:50   ` Andy Lutomirski
2018-06-07 20:15     ` Yu-cheng Yu
2018-06-12 10:56 ` [PATCH 00/10] Control Flow Enforcement - Part (3) Balbir Singh
2018-06-12 15:03   ` Yu-cheng Yu
2018-06-12 16:00     ` Andy Lutomirski
2018-06-12 16:21       ` Yu-cheng Yu
2018-06-12 16:31         ` Andy Lutomirski
2018-06-12 17:24           ` Yu-cheng Yu
2018-06-12 20:15             ` Yu-cheng Yu
2018-06-14  1:07     ` Balbir Singh
2018-06-14 14:56       ` Yu-cheng Yu
2018-06-17  3:16         ` Balbir Singh
2018-06-18 21:44           ` Andy Lutomirski
2018-06-19  8:52             ` Balbir Singh
2018-06-26  2:46 ` Jann Horn
2018-06-26 14:56   ` Yu-cheng Yu
2018-06-26  5:26 ` Andy Lutomirski
2018-06-26 14:56   ` Yu-cheng Yu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CALCETrWhMmqGWKx-yw55YKHMJwGyLZio5f8Pskh8X69zfQMy7A@mail.gmail.com \
    --to=luto@kernel.org \
    --cc=arnd@arndb.de \
    --cc=corbet@lwn.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=hjl.tools@gmail.com \
    --cc=hpa@zytor.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mike.kravetz@oracle.com \
    --cc=mingo@redhat.com \
    --cc=oleg@redhat.com \
    --cc=ravi.v.shankar@intel.com \
    --cc=tglx@linutronix.de \
    --cc=vedvyas.shanbhogue@intel.com \
    --cc=x86@kernel.org \
    --cc=yu-cheng.yu@intel.com \
    --subject='Re: [PATCH 06/10] x86/cet: Add arch_prctl functions for shadow stack' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).