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>,
	Cyrill Gorcunov <gorcunov@openvz.org>,
	Dmitry Safonov <dsafonov@virtuozzo.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: Fri, 8 Jun 2018 07:57:22 -0700	[thread overview]
Message-ID: <CALCETrUyapFiiXrHH23NW8XbqEkfKdGGU2wMUZ2DU=A+GWGqvw@mail.gmail.com> (raw)
In-Reply-To: <CAMe9rOpLDzWk=xdZqN1QJVnP-c_dti5Fy=C_GqbeQpS_a=0ewA@mail.gmail.com>

On Fri, Jun 8, 2018 at 5:24 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Thu, Jun 7, 2018 at 9:38 PM, Andy Lutomirski <luto@kernel.org> wrote:
> > 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:
> >>
> >
> > 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.
>
> We need a door for CET.  But it is a very bad idea to leave it open
> all the time.  I don't know much about CRIU,  If it is Checkpoint/Restore
> In Userspace.  Can you free any application with AVX512 on AVX512
> machine and restore it on non-AVX512 machine?

Presumably not -- if the program uses AVX512 and AVX512 goes away,
then the program won't be happy.

Anyway, having thought about this, here's a straw man proposal.  We
add a lock flag like in these patches.  The lock flag is set by
arch_prctl(), inherited on clone, and cleared on exec().  ptrace()
gains a new API to clear the lock flag and can modify the CET
configuration regardless of the lock flag.  (So ptrace() needs APIs to
read and write SSP, to read and write the shadow stack itself, and to
change the mode.)  By the time an attacker has gotten enough control
of a victim process to get it to use ptrace(), I don't think that
trying to protect CET serves any purpose.

As an aside, where are the latest CET docs?  I've found the "CET
technology preview 2.0", but it doesn't seem to be very clear or
entirely complete.

On Fri, Jun 8, 2018 at 5:17 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Thu, Jun 7, 2018 at 9:35 PM, Andy Lutomirski <luto@kernel.org> wrote:

> > 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 don't see the problem.  A CET-supporting ld.so will be started with
CET on regardless of what the final binary says.  If ld.so sees
LD_CET=force, it can keep CET on regardless of the flags in the loaded
binary.

>
> > 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.
>

I agree that this is a nice sentiment, but I don't think that a simple
"force CET on next exec()" flag is a good way to accomplish this.
I've had the pleasure of using legacy binaries, and there are all
kinds of gotchas.  First, a bunch of them aren't binaries at all --
they're shell scripts.  There's big_expensive_program that starts with
#!/bin/bash and eventually execs
/opt/blahblahblah/big_expensive_program_bin, and that involves two
execs.  (Heck, even Firefox is set up more or less like this.)  Some
programs can re-exec themselves.  All of this is not to mention that
it would be really annoying when your program crashes after you've
been using it for hours because you finally triggered the code path
that did longjmp() and CET kills it.

And you don't really need kernel support for this anyway.  It should
be relatively straightforward to write a loader that opens and loads a
static binary.

I think that this entire CET-on-exec concept should be dropped from
this patch series.  If someone really wants it, make it a separate
patch on top after everything has been merged, and we can poke holes
in it them.

  reply	other threads:[~2018-06-08 14:57 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
2018-06-08 12:24                 ` H.J. Lu
2018-06-08 14:57                   ` Andy Lutomirski [this message]
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='CALCETrUyapFiiXrHH23NW8XbqEkfKdGGU2wMUZ2DU=A+GWGqvw@mail.gmail.com' \
    --to=luto@kernel.org \
    --cc=arnd@arndb.de \
    --cc=corbet@lwn.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=dsafonov@virtuozzo.com \
    --cc=gorcunov@openvz.org \
    --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).