From: Andy Lutomirski <luto@amacapital.net> To: Florian Weimer <fweimer@redhat.com> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>, "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>, Boqun Feng <boqun.feng@gmail.com>, Peter Zijlstra <peterz@infradead.org>, Paul Turner <pjt@google.com>, Andrew Hunter <ahh@google.com>, Dave Watson <davejwatson@fb.com>, Josh Triplett <josh@joshtriplett.org>, Will Deacon <will.deacon@arm.com>, linux-kernel <linux-kernel@vger.kernel.org>, Thomas Gleixner <tglx@linutronix.de>, Andi Kleen <andi@firstfloor.org>, Chris Lameter <cl@linux.com>, Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>, Ben Maurer <bmaurer@fb.com>, rostedt <rostedt@goodmis.org>, Linus Torvalds <torvalds@linux-foundation.org>, Andrew Morton <akpm@linux-foundation.org>, Russell King <linux@arm.linux.org.uk>, Catalin Marinas <catalin.marinas@arm.com>, Michael Kerrisk <mtk.manpages@gmail.com>, Alexander Viro <viro@zeniv.linux.org.uk>, linux-api <linux-api@vger.kernel.org> Subject: Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call Date: Fri, 13 Oct 2017 11:17:04 -0700 [thread overview] Message-ID: <CALCETrVWZxC=mT9p7HTrAwcAdMzaxwa=A-O0uQt79qy1Cpky_g@mail.gmail.com> (raw) In-Reply-To: <3358e696-43e9-15d3-9634-68e9da79e121@redhat.com> On Fri, Oct 13, 2017 at 10:53 AM, Florian Weimer <fweimer@redhat.com> wrote: > On 10/13/2017 07:24 PM, Andy Lutomirski wrote: >> >> On Fri, Oct 13, 2017 at 7:27 AM, Mathieu Desnoyers >> <mathieu.desnoyers@efficios.com> wrote: >>> >>> ----- On Oct 13, 2017, at 9:56 AM, Florian Weimer fweimer@redhat.com >>> wrote: >>> >>>> On 10/13/2017 03:40 PM, Mathieu Desnoyers wrote: >>>>> >>>>> The proposed ABI does not require to store any function pointer. For a >>>>> given >>>>> rseq_finish() critical section, pointers to specific instructions >>>>> (within a >>>>> function) are emitted at link-time into a struct rseq_cs: >>>>> >>>>> struct rseq_cs { >>>>> RSEQ_FIELD_u32_u64(start_ip); >>>>> RSEQ_FIELD_u32_u64(post_commit_ip); >>>>> RSEQ_FIELD_u32_u64(abort_ip); >>>>> uint32_t flags; >>>>> } __attribute__((aligned(4 * sizeof(uint64_t)))); >>>>> >>>>> Then, at runtime, the fast-path stores the address of that struct >>>>> rseq_cs >>>>> into the TLS struct rseq "rseq_cs" field. >>>>> >>>>> So all we store at runtime is a pointer to data, not a pointer to >>>>> functions. >>>>> >>>>> But you seem to hint that having a pointer to data containing pointers >>>>> to code >>>>> may still be making it easier for exploit writers. Can you elaborate on >>>>> the >>>>> scenario ? >>>> >>>> >>>> I'm concerned that the exploit writer writes a totally made up struct >>>> rseq_cs object into writable memory, along with function pointers, and >>>> puts the address of that in to the rseq_cs field. >>>> >>>> This would be comparable to how C++ vtable pointers are targeted >>>> (including those in the glibc libio implementation of stdio streams). >>>> >>>> Does this answer your questions? >>> >>> >>> Yes, it does. How about we add a "canary" field to the TLS struct rseq, >>> e.g.: >>> >>> struct rseq { >>> union rseq_cpu_event u; >>> RSEQ_FIELD_u32_u64(rseq_cs); -> pointer to struct rseq_cs >>> uint32_t flags; >>> uint32_t canary; -> 32 low bits of rseq_cs ^ canary_mask >>> }; >>> >>> We could then add a "uint32_t canary_mask" argument to sys_rseq, e.g.: >>> >>> SYSCALL_DEFINE3(rseq, struct rseq __user *, rseq, uint32_t, canary_mask, >>> int, flags); >>> >>> So a thread which does not care about hardening would simply register its >>> struct rseq TLS with a canary mask of "0". Nothing changes on the >>> fast-path. >>> >>> A thread belonging to a process that cares about hardening could use a >>> random >>> value as canary, and pass it as canary_mask argument to the syscall. The >>> fast-path could then set the struct rseq "canary" value to >>> (32-low-bits of rseq_cs) ^ canary_mask just surrounding the critical >>> section, >>> and set it back to 0 afterward. >>> >>> In the kernel, whenever the rseq_cs pointer would be loaded, its 32 low >>> bits >>> would be checked to match (canary ^ canary_mask). If it differs, then the >>> kernel kills the process with SIGSEGV. >>> >>> Would that take care of your concern ? >>> >> >> I would propose a slightly different solution: have the kernel verify >> that it jumps to a code sequence that occurs just after some >> highly-unlikely magic bytes in the text *and* that those bytes have >> some signature that matches a signature in the struct rseq that's >> passed in. > > > And the signature is fixed at the time of the rseq syscall? The point of the signature is to prevent an rseq landing pad from being used out of context. Actually getting the details right might be tricky. > > Yes, that would be far more reliable. > > Thanks, > Florian -- Andy Lutomirski AMA Capital Management, LLC
WARNING: multiple messages have this Message-ID (diff)
From: Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> To: Florian Weimer <fweimer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> Cc: Mathieu Desnoyers <mathieu.desnoyers-vg+e7yoeK/dWk0Htik3J/w@public.gmane.org>, "Paul E. McKenney" <paulmck-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>, Boqun Feng <boqun.feng-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>, Paul Turner <pjt-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>, Andrew Hunter <ahh-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>, Dave Watson <davejwatson-b10kYP2dOMg@public.gmane.org>, Josh Triplett <josh-iaAMLnmF4UmaiuxdJuQwMA@public.gmane.org>, Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>, linux-kernel <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>, Andi Kleen <andi-Vw/NltI1exuRpAAqCnN02g@public.gmane.org>, Chris Lameter <cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org>, Ingo Molnar <mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, "H. Peter Anvin" <hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>, Ben Maurer <bmaurer-b10kYP2dOMg@public.gmane.org>, rostedt <rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org>, Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>, Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>, Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>, Catalin Subject: Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call Date: Fri, 13 Oct 2017 11:17:04 -0700 [thread overview] Message-ID: <CALCETrVWZxC=mT9p7HTrAwcAdMzaxwa=A-O0uQt79qy1Cpky_g@mail.gmail.com> (raw) In-Reply-To: <3358e696-43e9-15d3-9634-68e9da79e121-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> On Fri, Oct 13, 2017 at 10:53 AM, Florian Weimer <fweimer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote: > On 10/13/2017 07:24 PM, Andy Lutomirski wrote: >> >> On Fri, Oct 13, 2017 at 7:27 AM, Mathieu Desnoyers >> <mathieu.desnoyers-vg+e7yoeK/dWk0Htik3J/w@public.gmane.org> wrote: >>> >>> ----- On Oct 13, 2017, at 9:56 AM, Florian Weimer fweimer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org >>> wrote: >>> >>>> On 10/13/2017 03:40 PM, Mathieu Desnoyers wrote: >>>>> >>>>> The proposed ABI does not require to store any function pointer. For a >>>>> given >>>>> rseq_finish() critical section, pointers to specific instructions >>>>> (within a >>>>> function) are emitted at link-time into a struct rseq_cs: >>>>> >>>>> struct rseq_cs { >>>>> RSEQ_FIELD_u32_u64(start_ip); >>>>> RSEQ_FIELD_u32_u64(post_commit_ip); >>>>> RSEQ_FIELD_u32_u64(abort_ip); >>>>> uint32_t flags; >>>>> } __attribute__((aligned(4 * sizeof(uint64_t)))); >>>>> >>>>> Then, at runtime, the fast-path stores the address of that struct >>>>> rseq_cs >>>>> into the TLS struct rseq "rseq_cs" field. >>>>> >>>>> So all we store at runtime is a pointer to data, not a pointer to >>>>> functions. >>>>> >>>>> But you seem to hint that having a pointer to data containing pointers >>>>> to code >>>>> may still be making it easier for exploit writers. Can you elaborate on >>>>> the >>>>> scenario ? >>>> >>>> >>>> I'm concerned that the exploit writer writes a totally made up struct >>>> rseq_cs object into writable memory, along with function pointers, and >>>> puts the address of that in to the rseq_cs field. >>>> >>>> This would be comparable to how C++ vtable pointers are targeted >>>> (including those in the glibc libio implementation of stdio streams). >>>> >>>> Does this answer your questions? >>> >>> >>> Yes, it does. How about we add a "canary" field to the TLS struct rseq, >>> e.g.: >>> >>> struct rseq { >>> union rseq_cpu_event u; >>> RSEQ_FIELD_u32_u64(rseq_cs); -> pointer to struct rseq_cs >>> uint32_t flags; >>> uint32_t canary; -> 32 low bits of rseq_cs ^ canary_mask >>> }; >>> >>> We could then add a "uint32_t canary_mask" argument to sys_rseq, e.g.: >>> >>> SYSCALL_DEFINE3(rseq, struct rseq __user *, rseq, uint32_t, canary_mask, >>> int, flags); >>> >>> So a thread which does not care about hardening would simply register its >>> struct rseq TLS with a canary mask of "0". Nothing changes on the >>> fast-path. >>> >>> A thread belonging to a process that cares about hardening could use a >>> random >>> value as canary, and pass it as canary_mask argument to the syscall. The >>> fast-path could then set the struct rseq "canary" value to >>> (32-low-bits of rseq_cs) ^ canary_mask just surrounding the critical >>> section, >>> and set it back to 0 afterward. >>> >>> In the kernel, whenever the rseq_cs pointer would be loaded, its 32 low >>> bits >>> would be checked to match (canary ^ canary_mask). If it differs, then the >>> kernel kills the process with SIGSEGV. >>> >>> Would that take care of your concern ? >>> >> >> I would propose a slightly different solution: have the kernel verify >> that it jumps to a code sequence that occurs just after some >> highly-unlikely magic bytes in the text *and* that those bytes have >> some signature that matches a signature in the struct rseq that's >> passed in. > > > And the signature is fixed at the time of the rseq syscall? The point of the signature is to prevent an rseq landing pad from being used out of context. Actually getting the details right might be tricky. > > Yes, that would be far more reliable. > > Thanks, > Florian -- Andy Lutomirski AMA Capital Management, LLC
next prev parent reply other threads:[~2017-10-13 18:17 UTC|newest] Thread overview: 113+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-10-12 23:03 [RFC PATCH v9 for 4.15 00/14] Restartable sequences and CPU op vector system calls Mathieu Desnoyers 2017-10-12 23:03 ` [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call Mathieu Desnoyers 2017-10-13 0:36 ` Linus Torvalds 2017-10-13 0:36 ` Linus Torvalds 2017-10-13 9:35 ` Ben Maurer 2017-10-13 9:35 ` Ben Maurer 2017-10-13 18:30 ` Linus Torvalds 2017-10-13 18:30 ` Linus Torvalds 2017-10-13 20:54 ` Paul E. McKenney 2017-10-13 20:54 ` Paul E. McKenney 2017-10-13 21:05 ` Linus Torvalds 2017-10-13 21:05 ` Linus Torvalds 2017-10-13 21:21 ` Paul E. McKenney 2017-10-13 21:21 ` Paul E. McKenney 2017-10-13 21:36 ` Mathieu Desnoyers 2017-10-13 21:36 ` Mathieu Desnoyers 2017-10-16 16:04 ` Carlos O'Donell 2017-10-16 16:04 ` Carlos O'Donell 2017-10-16 16:46 ` Andi Kleen 2017-10-16 16:46 ` Andi Kleen 2017-10-16 22:17 ` Mathieu Desnoyers 2017-10-16 22:17 ` Mathieu Desnoyers 2017-10-17 16:19 ` Ben Maurer 2017-10-17 16:19 ` Ben Maurer 2017-10-17 16:33 ` Mathieu Desnoyers 2017-10-17 16:33 ` Mathieu Desnoyers 2017-10-17 16:41 ` Ben Maurer 2017-10-17 16:41 ` Ben Maurer 2017-10-17 17:48 ` Mathieu Desnoyers 2017-10-17 17:48 ` Mathieu Desnoyers 2017-10-18 6:22 ` Greg KH 2017-10-18 6:22 ` Greg KH 2017-10-18 16:28 ` Mathieu Desnoyers 2017-10-18 16:28 ` Mathieu Desnoyers 2017-10-14 3:01 ` Andi Kleen 2017-10-14 3:01 ` Andi Kleen 2017-10-14 4:05 ` Linus Torvalds 2017-10-14 4:05 ` Linus Torvalds 2017-10-14 11:37 ` Mathieu Desnoyers 2017-10-14 11:37 ` Mathieu Desnoyers 2017-10-13 12:50 ` Florian Weimer 2017-10-13 13:40 ` Mathieu Desnoyers 2017-10-13 13:40 ` Mathieu Desnoyers 2017-10-13 13:56 ` Florian Weimer 2017-10-13 13:56 ` Florian Weimer 2017-10-13 14:27 ` Mathieu Desnoyers 2017-10-13 14:27 ` Mathieu Desnoyers 2017-10-13 17:24 ` Andy Lutomirski 2017-10-13 17:24 ` Andy Lutomirski 2017-10-13 17:53 ` Florian Weimer 2017-10-13 17:53 ` Florian Weimer 2017-10-13 18:17 ` Andy Lutomirski [this message] 2017-10-13 18:17 ` Andy Lutomirski 2017-10-14 11:53 ` Mathieu Desnoyers 2017-10-14 11:53 ` Mathieu Desnoyers 2017-10-18 16:41 ` Ben Maurer 2017-10-18 18:11 ` Mathieu Desnoyers 2017-10-18 18:11 ` Mathieu Desnoyers 2017-10-19 11:35 ` Mathieu Desnoyers 2017-10-19 11:35 ` Mathieu Desnoyers 2017-10-19 17:01 ` Florian Weimer 2017-10-19 17:01 ` Florian Weimer 2017-10-23 17:30 ` Ben Maurer 2017-10-23 17:30 ` Ben Maurer 2017-10-23 20:44 ` Mathieu Desnoyers 2017-10-23 20:44 ` Mathieu Desnoyers 2017-10-12 23:03 ` [RFC PATCH for 4.15 02/14] tracing: instrument restartable sequences Mathieu Desnoyers 2017-10-12 23:03 ` [RFC PATCH for 4.15 03/14] Restartable sequences: ARM 32 architecture support Mathieu Desnoyers 2017-10-12 23:03 ` [RFC PATCH for 4.15 04/14] Restartable sequences: wire up ARM 32 system call Mathieu Desnoyers 2017-10-12 23:03 ` [RFC PATCH for 4.15 05/14] Restartable sequences: x86 32/64 architecture support Mathieu Desnoyers 2017-10-12 23:03 ` [RFC PATCH for 4.15 06/14] Restartable sequences: wire up x86 32/64 system call Mathieu Desnoyers 2017-10-12 23:03 ` [RFC PATCH for 4.15 07/14] Restartable sequences: powerpc architecture support Mathieu Desnoyers 2017-10-12 23:03 ` [RFC PATCH for 4.15 08/14] Restartable sequences: Wire up powerpc system call Mathieu Desnoyers 2017-10-12 23:03 ` [RFC PATCH for 4.15 09/14] Provide cpu_opv " Mathieu Desnoyers 2017-10-13 13:57 ` Alan Cox 2017-10-13 13:57 ` Alan Cox 2017-10-13 14:50 ` Mathieu Desnoyers 2017-10-13 14:50 ` Mathieu Desnoyers 2017-10-14 14:22 ` Mathieu Desnoyers 2017-10-14 14:22 ` Mathieu Desnoyers 2017-10-13 17:20 ` Andy Lutomirski 2017-10-13 17:20 ` Andy Lutomirski 2017-10-14 2:50 ` Andi Kleen 2017-10-14 2:50 ` Andi Kleen 2017-10-14 13:35 ` Mathieu Desnoyers 2017-10-14 13:35 ` Mathieu Desnoyers 2017-10-12 23:03 ` [RFC PATCH for 4.15 10/14] cpu_opv: Wire up x86 32/64 " Mathieu Desnoyers 2017-10-12 23:03 ` [RFC PATCH for 4.15 11/14] cpu_opv: Wire up powerpc " Mathieu Desnoyers 2017-10-12 23:03 ` [RFC PATCH for 4.15 12/14] cpu_opv: Wire up ARM32 " Mathieu Desnoyers 2017-10-12 23:03 ` [RFC PATCH for 4.15 13/14] cpu_opv: Implement selftests Mathieu Desnoyers 2017-10-12 23:03 ` [RFC PATCH for 4.15 14/14] Restartable sequences: Provide self-tests Mathieu Desnoyers 2017-10-16 2:51 ` Michael Ellerman 2017-10-16 2:51 ` Michael Ellerman 2017-10-16 14:23 ` Mathieu Desnoyers 2017-10-16 14:23 ` Mathieu Desnoyers 2017-10-17 10:38 ` Michael Ellerman 2017-10-17 10:38 ` Michael Ellerman 2017-10-17 13:50 ` Mathieu Desnoyers 2017-10-17 13:50 ` Mathieu Desnoyers 2017-10-16 18:50 ` Mathieu Desnoyers 2017-10-16 18:50 ` Mathieu Desnoyers 2017-10-17 10:36 ` Michael Ellerman 2017-10-17 10:36 ` Michael Ellerman 2017-10-17 13:50 ` Mathieu Desnoyers 2017-10-17 13:50 ` Mathieu Desnoyers 2017-10-18 5:45 ` Michael Ellerman 2017-10-18 5:45 ` Michael Ellerman 2017-10-16 3:00 ` Michael Ellerman 2017-10-16 3:00 ` Michael Ellerman 2017-10-16 3:48 ` Boqun Feng 2017-10-16 3:48 ` Boqun Feng 2017-10-16 11:48 ` Michael Ellerman 2017-10-16 11:48 ` Michael Ellerman
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='CALCETrVWZxC=mT9p7HTrAwcAdMzaxwa=A-O0uQt79qy1Cpky_g@mail.gmail.com' \ --to=luto@amacapital.net \ --cc=ahh@google.com \ --cc=akpm@linux-foundation.org \ --cc=andi@firstfloor.org \ --cc=bmaurer@fb.com \ --cc=boqun.feng@gmail.com \ --cc=catalin.marinas@arm.com \ --cc=cl@linux.com \ --cc=davejwatson@fb.com \ --cc=fweimer@redhat.com \ --cc=hpa@zytor.com \ --cc=josh@joshtriplett.org \ --cc=linux-api@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@arm.linux.org.uk \ --cc=mathieu.desnoyers@efficios.com \ --cc=mingo@redhat.com \ --cc=mtk.manpages@gmail.com \ --cc=paulmck@linux.vnet.ibm.com \ --cc=peterz@infradead.org \ --cc=pjt@google.com \ --cc=rostedt@goodmis.org \ --cc=tglx@linutronix.de \ --cc=torvalds@linux-foundation.org \ --cc=viro@zeniv.linux.org.uk \ --cc=will.deacon@arm.com \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.