From: "Indan Zupancic" <indan@nul.nu> To: "H. Peter Anvin" <hpa@zytor.com> Cc: "Linus Torvalds" <torvalds@linux-foundation.org>, "Andi Kleen" <andi@firstfloor.org>, "Jamie Lokier" <jamie@shareable.org>, "Andrew Lutomirski" <luto@mit.edu>, "Oleg Nesterov" <oleg@redhat.com>, "Will Drewry" <wad@chromium.org>, linux-kernel@vger.kernel.org, keescook@chromium.org, john.johansen@canonical.com, serge.hallyn@canonical.com, coreyb@linux.vnet.ibm.com, pmoore@redhat.com, eparis@redhat.com, djm@mindrot.org, segoon@openwall.com, rostedt@goodmis.org, jmorris@namei.org, scarybeasts@gmail.com, avi@redhat.com, penberg@cs.helsinki.fi, viro@zeniv.linux.org.uk, mingo@elte.hu, akpm@linux-foundation.org, khilman@ti.com, borislav.petkov@amd.com, amwang@redhat.com, ak@linux.intel.com, eric.dumazet@gmail.com, dhowells@redhat.com, daniel.lezcano@free.fr, linux-fsdevel@vger.kernel.org, linux-security-module@vger.kernel.org, olofj@chromium.org, mhalcrow@google.com, dlaor@redhat.com, "Roland McGrath" <mcgrathr@chromium.org>, "H.J. Lu" <hjl.tools@gmail.com> Subject: Re: Compat 32-bit syscall entry from 64-bit task!? Date: Thu, 9 Feb 2012 07:03:08 +0100 [thread overview] Message-ID: <5f13059f9b57d2a0fe2be094702b8177.squirrel@webmail.greenhost.nl> (raw) In-Reply-To: <4F334B8C.2050005@zytor.com> On Thu, February 9, 2012 05:29, H. Peter Anvin wrote: > On 02/08/2012 08:20 PM, Indan Zupancic wrote: >> >> CS is already available to user space, but any other value than 0x23 or 0x33 >> will confuse user space, as that is all they know about. Apparently Xen uses >> different values, but if those are static then user space can check for them >> separately. But if the values change dynamically then some other way may be >> needed. >> >> But does it make much sense to pass the CPU mode of user space if that mode >> can be changed at any moment? I don't think it really does. Can you give an >> example of how that info can be used by a ptracer? >> > > Uh... you could make THAT argument about ANY register state! Well, when the tracee is in a system call, it can't change registers, and their values determine the system call number and arguments. That information is stable for the current system call. And as a ptracer can't determine if the 32 or 64-bit syscall entry path was taken in a race-free way, it makes sense to provide that extra info. But the same is not true for the user space CPU mode, that can change at any time without the tracer getting a notification, except if it is single stepping (which I forgot about). Would it be useful to know the CPU mode when single stepping or otherwise? I'm asking because I don't see a need for it, but if someone else does it's better to add it now together with the syscall mode bit. Unlike the system call mode, the CPU mode can be checked via CS. The question is if that works well enough or if the values are dynamic enough that it's better to pass the info explicitly instead. Unlike the syscall mode info, figuring out the mode from CS isn't trivial when it can change dynamically. Then all places that use non-standard CS values need to be changed to provide the mode somehow. > I believe H.J. can fill you in about the usage. That would be great. >> >> Only confusion I can think of is someone following the register values >> across a systemcall instruction. Then the swizzling may be unexpected. >> But if they do that they could check how the sycall was entered and >> compensate for that. (I can't think of any requirement why this would >> need to be race-free.) >> > > You'd have to know how you'd entered, which right now you don't have any > way to know. You can check the syscall instruction itself, either before it's executed or afterwards by checking the IP. Though that's trickier, because the kernel points the IP to just after int80 for a sysenter call, so you have to check if there's a sysenter nearby too. You can also figure out what the entry instruction was by comparing the register values with the expected ones and deducing it that way. But the kernel is actually changing the registers, so why hide that? I mean, once user space is aware that the kernel may do swizzling, is there any actual problem left? Because this sounds like user space was trying to be clever, but got it wrong. E.g. it knew the kernel was entered not via int80, but then got confused because of the swizzling. Greetings, Indan
WARNING: multiple messages have this Message-ID (diff)
From: "Indan Zupancic" <indan@nul.nu> To: "H. Peter Anvin" <hpa@zytor.com> Cc: "Linus Torvalds" <torvalds@linux-foundation.org>, "Andi Kleen" <andi@firstfloor.org>, "Jamie Lokier" <jamie@shareable.org>, "Andrew Lutomirski" <luto@mit.edu>, "Oleg Nesterov" <oleg@redhat.com>, "Will Drewry" <wad@chromium.org>, linux-kernel@vger.kernel.org, keescook@chromium.org, john.johansen@canonical.com, serge.hallyn@canonical.com, coreyb@linux.vnet.ibm.com, pmoore@redhat.com, eparis@redhat.com, djm@mindrot.org, segoon@openwall.com, rostedt@goodmis.org, jmorris@namei.org, scarybeasts@gmail.com, avi@redhat.com, penberg@cs.helsinki.fi, viro@zeniv.linux.org.uk, mingo@elte.hu, akpm@linux-foundation.org, khilman@ti.com, borislav.petkov@amd.com, amwang@redhat.com, ak@linux.intel.com, eric.dumazet@gmail.com, dhowells@redhat.com, daniel.lezcano@free.fr, linux-fsdevel@vger.kernel.org, linux-security-module@vger.kernel.org, olofj@chromium.org, mhalcrow@google.com, dlaor@re Subject: Re: Compat 32-bit syscall entry from 64-bit task!? Date: Thu, 9 Feb 2012 07:03:08 +0100 [thread overview] Message-ID: <5f13059f9b57d2a0fe2be094702b8177.squirrel@webmail.greenhost.nl> (raw) In-Reply-To: <4F334B8C.2050005@zytor.com> On Thu, February 9, 2012 05:29, H. Peter Anvin wrote: > On 02/08/2012 08:20 PM, Indan Zupancic wrote: >> >> CS is already available to user space, but any other value than 0x23 or 0x33 >> will confuse user space, as that is all they know about. Apparently Xen uses >> different values, but if those are static then user space can check for them >> separately. But if the values change dynamically then some other way may be >> needed. >> >> But does it make much sense to pass the CPU mode of user space if that mode >> can be changed at any moment? I don't think it really does. Can you give an >> example of how that info can be used by a ptracer? >> > > Uh... you could make THAT argument about ANY register state! Well, when the tracee is in a system call, it can't change registers, and their values determine the system call number and arguments. That information is stable for the current system call. And as a ptracer can't determine if the 32 or 64-bit syscall entry path was taken in a race-free way, it makes sense to provide that extra info. But the same is not true for the user space CPU mode, that can change at any time without the tracer getting a notification, except if it is single stepping (which I forgot about). Would it be useful to know the CPU mode when single stepping or otherwise? I'm asking because I don't see a need for it, but if someone else does it's better to add it now together with the syscall mode bit. Unlike the system call mode, the CPU mode can be checked via CS. The question is if that works well enough or if the values are dynamic enough that it's better to pass the info explicitly instead. Unlike the syscall mode info, figuring out the mode from CS isn't trivial when it can change dynamically. Then all places that use non-standard CS values need to be changed to provide the mode somehow. > I believe H.J. can fill you in about the usage. That would be great. >> >> Only confusion I can think of is someone following the register values >> across a systemcall instruction. Then the swizzling may be unexpected. >> But if they do that they could check how the sycall was entered and >> compensate for that. (I can't think of any requirement why this would >> need to be race-free.) >> > > You'd have to know how you'd entered, which right now you don't have any > way to know. You can check the syscall instruction itself, either before it's executed or afterwards by checking the IP. Though that's trickier, because the kernel points the IP to just after int80 for a sysenter call, so you have to check if there's a sysenter nearby too. You can also figure out what the entry instruction was by comparing the register values with the expected ones and deducing it that way. But the kernel is actually changing the registers, so why hide that? I mean, once user space is aware that the kernel may do swizzling, is there any actual problem left? Because this sounds like user space was trying to be clever, but got it wrong. E.g. it knew the kernel was entered not via int80, but then got confused because of the swizzling. Greetings, Indan
next prev parent reply other threads:[~2012-02-09 6:03 UTC|newest] Thread overview: 409+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-01-11 17:25 [RFC,PATCH 0/2] dynamic seccomp policies (using BPF filters) Will Drewry 2012-01-11 17:25 ` [RFC,PATCH 1/2] seccomp_filters: system call filtering using BPF Will Drewry 2012-01-12 8:53 ` Serge Hallyn 2012-01-12 16:54 ` Will Drewry 2012-01-12 16:54 ` Will Drewry 2012-01-12 14:50 ` Oleg Nesterov 2012-01-12 16:55 ` Will Drewry 2012-01-12 16:55 ` Will Drewry 2012-01-12 15:43 ` Steven Rostedt 2012-01-12 16:14 ` Oleg Nesterov 2012-01-12 16:38 ` Steven Rostedt 2012-01-12 16:47 ` Oleg Nesterov 2012-01-12 17:08 ` Will Drewry 2012-01-12 17:08 ` Will Drewry 2012-01-12 17:30 ` Jamie Lokier 2012-01-12 17:40 ` Steven Rostedt 2012-01-12 17:44 ` Jamie Lokier 2012-01-12 17:56 ` Steven Rostedt 2012-01-12 23:27 ` Alan Cox 2012-01-12 23:38 ` Linus Torvalds 2012-01-12 22:18 ` Will Drewry 2012-01-12 22:18 ` Will Drewry 2012-01-12 23:00 ` Andrew Lutomirski 2012-01-12 23:00 ` Andrew Lutomirski 2012-01-12 16:14 ` Andrew Lutomirski 2012-01-12 16:14 ` Andrew Lutomirski 2012-01-12 16:27 ` Steven Rostedt 2012-01-12 16:51 ` Andrew Lutomirski 2012-01-12 16:51 ` Andrew Lutomirski 2012-01-12 17:09 ` Linus Torvalds 2012-01-12 17:17 ` Steven Rostedt 2012-01-12 18:18 ` Andrew Lutomirski 2012-01-12 18:32 ` Linus Torvalds 2012-01-12 18:32 ` Linus Torvalds 2012-01-12 18:44 ` Andrew Lutomirski 2012-01-12 19:08 ` Kyle Moffett 2012-01-12 19:08 ` Kyle Moffett 2012-01-12 23:05 ` Eric Paris 2012-01-12 23:33 ` Andrew Lutomirski 2012-01-12 23:33 ` Andrew Lutomirski 2012-01-12 19:40 ` Will Drewry 2012-01-12 19:40 ` Will Drewry 2012-01-12 19:42 ` Will Drewry 2012-01-12 19:42 ` Will Drewry 2012-01-12 19:46 ` Andrew Lutomirski 2012-01-12 19:46 ` Andrew Lutomirski 2012-01-12 20:00 ` Linus Torvalds 2012-01-12 20:00 ` Linus Torvalds 2012-01-12 16:59 ` Will Drewry 2012-01-12 16:59 ` Will Drewry 2012-01-12 17:22 ` Jamie Lokier 2012-01-12 17:22 ` Jamie Lokier 2012-01-12 17:35 ` Will Drewry 2012-01-12 17:57 ` Jamie Lokier 2012-01-12 17:57 ` Jamie Lokier 2012-01-12 18:03 ` Will Drewry 2012-01-12 18:03 ` Will Drewry 2012-01-13 1:34 ` Jamie Lokier 2012-01-13 2:44 ` Indan Zupancic 2012-01-13 6:33 ` Chris Evans 2012-01-13 6:33 ` Chris Evans 2012-01-12 17:36 ` Jamie Lokier 2012-01-12 16:18 ` Alan Cox 2012-01-12 17:03 ` Will Drewry 2012-01-12 17:03 ` Will Drewry 2012-01-12 17:11 ` Alan Cox 2012-01-12 17:52 ` Will Drewry 2012-01-12 17:52 ` Will Drewry 2012-01-13 1:31 ` James Morris 2012-01-12 16:22 ` Oleg Nesterov 2012-01-12 17:10 ` Will Drewry 2012-01-12 17:23 ` Oleg Nesterov 2012-01-12 17:23 ` Oleg Nesterov 2012-01-12 17:51 ` Will Drewry 2012-01-12 17:51 ` Will Drewry 2012-01-13 17:31 ` Oleg Nesterov 2012-01-13 17:31 ` Oleg Nesterov 2012-01-13 19:01 ` Will Drewry 2012-01-13 19:01 ` Will Drewry 2012-01-13 23:10 ` Will Drewry 2012-01-13 23:10 ` Will Drewry 2012-01-13 23:12 ` Will Drewry 2012-01-13 23:12 ` Will Drewry 2012-01-13 23:30 ` Eric Paris 2012-01-15 3:40 ` Indan Zupancic 2012-01-16 1:40 ` Will Drewry 2012-01-16 6:49 ` Indan Zupancic 2012-01-16 20:12 ` Will Drewry 2012-01-17 6:46 ` Indan Zupancic 2012-01-17 17:37 ` Will Drewry 2012-01-18 4:06 ` Indan Zupancic 2012-01-18 4:38 ` Will Drewry 2012-01-17 20:34 ` Kees Cook 2012-01-17 20:42 ` Will Drewry 2012-01-17 21:09 ` Will Drewry 2012-01-18 4:47 ` Indan Zupancic 2012-01-16 18:37 ` Oleg Nesterov 2012-01-16 18:37 ` Oleg Nesterov 2012-01-16 20:15 ` Will Drewry 2012-01-16 20:15 ` Will Drewry 2012-01-17 16:45 ` Oleg Nesterov 2012-01-17 16:56 ` Will Drewry 2012-01-17 16:56 ` Will Drewry 2012-01-17 17:01 ` Andrew Lutomirski 2012-01-17 17:01 ` Andrew Lutomirski 2012-01-17 17:05 ` Oleg Nesterov 2012-01-17 17:45 ` Andrew Lutomirski 2012-01-17 17:45 ` Andrew Lutomirski 2012-01-18 0:56 ` Compat 32-bit syscall entry from 64-bit task!? [was: Re: [RFC,PATCH 1/2] seccomp_filters: system call filtering using BPF] Indan Zupancic 2012-01-18 1:01 ` Andrew Lutomirski 2012-01-18 1:01 ` Andrew Lutomirski 2012-01-19 1:06 ` Indan Zupancic 2012-01-19 1:06 ` Indan Zupancic 2012-01-19 1:19 ` Andrew Lutomirski 2012-01-19 1:47 ` Indan Zupancic 2012-01-18 1:07 ` Roland McGrath 2012-01-18 1:47 ` Indan Zupancic 2012-01-18 1:48 ` Jamie Lokier 2012-01-18 1:50 ` Andi Kleen 2012-01-18 2:00 ` Steven Rostedt 2012-01-18 2:04 ` Jamie Lokier 2012-01-18 2:22 ` Andi Kleen 2012-01-18 2:22 ` Andi Kleen 2012-01-18 2:25 ` Andrew Lutomirski 2012-01-18 4:22 ` Indan Zupancic 2012-01-18 4:22 ` Indan Zupancic 2012-01-18 5:23 ` Linus Torvalds 2012-01-18 5:23 ` Linus Torvalds 2012-01-18 6:25 ` Linus Torvalds 2012-01-18 6:25 ` Linus Torvalds 2012-01-18 13:12 ` Compat 32-bit syscall entry from 64-bit task!? Indan Zupancic 2012-01-18 13:12 ` Indan Zupancic 2012-01-18 19:31 ` Linus Torvalds 2012-01-18 19:31 ` Linus Torvalds 2012-01-18 19:36 ` Andi Kleen 2012-01-18 19:36 ` Andi Kleen 2012-01-18 19:39 ` Linus Torvalds 2012-01-18 19:39 ` Linus Torvalds 2012-01-18 19:44 ` Andi Kleen 2012-01-18 19:44 ` Andi Kleen 2012-01-18 19:47 ` Linus Torvalds 2012-01-18 19:47 ` Linus Torvalds 2012-01-18 19:52 ` Will Drewry 2012-01-18 19:52 ` Will Drewry 2012-01-18 19:58 ` Will Drewry 2012-01-18 19:58 ` Will Drewry 2012-01-18 19:41 ` Martin Mares 2012-01-18 19:41 ` Martin Mares 2012-01-18 19:38 ` Andrew Lutomirski 2012-01-18 19:38 ` Andrew Lutomirski 2012-01-19 16:01 ` Jamie Lokier 2012-01-19 16:01 ` Jamie Lokier 2012-01-19 16:13 ` Andrew Lutomirski 2012-01-19 16:13 ` Andrew Lutomirski 2012-01-19 19:21 ` Linus Torvalds 2012-01-19 19:21 ` Linus Torvalds 2012-01-19 19:30 ` Andrew Lutomirski 2012-01-19 19:30 ` Andrew Lutomirski 2012-01-19 19:37 ` Linus Torvalds 2012-01-19 19:37 ` Linus Torvalds 2012-01-19 19:41 ` Linus Torvalds 2012-01-19 19:41 ` Linus Torvalds 2012-01-19 23:54 ` Jamie Lokier 2012-01-19 23:54 ` Jamie Lokier 2012-01-20 0:05 ` Linus Torvalds 2012-01-20 0:05 ` Linus Torvalds 2012-01-20 15:35 ` Will Drewry 2012-01-20 15:35 ` Will Drewry 2012-01-20 17:56 ` Roland McGrath 2012-01-20 17:56 ` Roland McGrath 2012-01-20 19:45 ` Will Drewry 2012-01-20 19:45 ` Will Drewry 2012-01-18 20:26 ` Linus Torvalds 2012-01-18 20:26 ` Linus Torvalds 2012-01-18 20:55 ` H. Peter Anvin 2012-01-18 20:55 ` H. Peter Anvin 2012-01-18 21:01 ` Linus Torvalds 2012-01-18 21:01 ` Linus Torvalds 2012-01-18 21:04 ` H. Peter Anvin 2012-01-18 21:04 ` H. Peter Anvin 2012-01-18 21:21 ` H. Peter Anvin 2012-01-18 21:21 ` H. Peter Anvin 2012-01-18 21:51 ` Roland McGrath 2012-01-18 21:51 ` Roland McGrath 2012-01-18 21:53 ` H. Peter Anvin 2012-01-18 21:53 ` H. Peter Anvin 2012-01-18 23:28 ` Linus Torvalds 2012-01-18 23:28 ` Linus Torvalds 2012-01-19 0:38 ` H. Peter Anvin 2012-01-19 0:38 ` H. Peter Anvin 2012-01-20 21:51 ` Denys Vlasenko 2012-01-20 21:51 ` Denys Vlasenko 2012-01-20 22:40 ` Roland McGrath 2012-01-20 22:40 ` Roland McGrath 2012-01-20 22:41 ` H. Peter Anvin 2012-01-20 22:41 ` H. Peter Anvin 2012-01-20 23:49 ` Indan Zupancic 2012-01-20 23:49 ` Indan Zupancic 2012-01-20 23:55 ` Roland McGrath 2012-01-20 23:55 ` Roland McGrath 2012-01-20 23:58 ` hpanvin@gmail.com 2012-01-20 23:58 ` hpanvin@gmail.com 2012-01-23 2:14 ` Indan Zupancic 2012-01-23 2:14 ` Indan Zupancic 2012-01-21 0:07 ` Denys Vlasenko 2012-01-21 0:07 ` Denys Vlasenko 2012-01-21 0:10 ` Roland McGrath 2012-01-21 0:10 ` Roland McGrath 2012-01-21 1:23 ` Jamie Lokier 2012-01-21 1:23 ` Jamie Lokier 2012-01-23 2:37 ` Indan Zupancic 2012-01-23 2:37 ` Indan Zupancic 2012-01-23 16:48 ` Oleg Nesterov 2012-01-23 16:48 ` Oleg Nesterov 2012-01-24 8:19 ` Indan Zupancic 2012-01-24 8:19 ` Indan Zupancic 2012-02-06 20:30 ` H. Peter Anvin 2012-02-06 20:30 ` H. Peter Anvin 2012-02-06 20:39 ` Roland McGrath 2012-02-06 20:39 ` Roland McGrath 2012-02-06 20:42 ` H. Peter Anvin 2012-02-06 20:42 ` H. Peter Anvin 2012-01-18 21:26 ` Linus Torvalds 2012-01-18 21:26 ` Linus Torvalds 2012-01-18 21:30 ` H. Peter Anvin 2012-01-18 21:30 ` H. Peter Anvin 2012-01-18 21:42 ` Linus Torvalds 2012-01-18 21:42 ` Linus Torvalds 2012-01-18 21:47 ` H. Peter Anvin 2012-01-18 21:47 ` H. Peter Anvin 2012-01-19 1:45 ` Indan Zupancic 2012-01-19 1:45 ` Indan Zupancic 2012-01-19 2:16 ` H. Peter Anvin 2012-01-19 2:16 ` H. Peter Anvin 2012-02-06 8:32 ` Indan Zupancic 2012-02-06 8:32 ` Indan Zupancic 2012-02-06 17:02 ` H. Peter Anvin 2012-02-06 17:02 ` H. Peter Anvin 2012-02-07 1:52 ` Indan Zupancic 2012-02-07 1:52 ` Indan Zupancic 2012-02-09 0:19 ` H. Peter Anvin 2012-02-09 0:19 ` H. Peter Anvin 2012-02-09 4:20 ` Indan Zupancic 2012-02-09 4:20 ` Indan Zupancic 2012-02-09 4:29 ` H. Peter Anvin 2012-02-09 4:29 ` H. Peter Anvin 2012-02-09 6:03 ` Indan Zupancic [this message] 2012-02-09 6:03 ` Indan Zupancic 2012-02-09 14:47 ` H. Peter Anvin 2012-02-09 14:47 ` H. Peter Anvin 2012-02-09 16:00 ` H.J. Lu 2012-02-09 16:00 ` H.J. Lu 2012-02-10 1:09 ` Indan Zupancic 2012-02-10 1:09 ` Indan Zupancic 2012-02-10 1:15 ` H. Peter Anvin 2012-02-10 1:15 ` H. Peter Anvin 2012-02-10 2:29 ` Indan Zupancic 2012-02-10 2:29 ` Indan Zupancic 2012-02-10 2:47 ` H. Peter Anvin 2012-02-10 2:47 ` H. Peter Anvin [not found] ` <cc95fcf4b1c28ee6f73e373d04593634.squirrel@webmail.greenhost.nl> 2012-02-10 15:53 ` H. Peter Anvin 2012-02-10 15:53 ` H. Peter Anvin 2012-02-10 22:42 ` Indan Zupancic 2012-02-10 22:42 ` Indan Zupancic 2012-02-10 22:56 ` H. Peter Anvin 2012-02-10 22:56 ` H. Peter Anvin 2012-02-12 12:07 ` Indan Zupancic 2012-02-12 12:07 ` Indan Zupancic 2012-01-25 19:36 ` Oleg Nesterov 2012-01-25 19:36 ` Oleg Nesterov 2012-01-25 20:20 ` Pedro Alves 2012-01-25 20:20 ` Pedro Alves 2012-01-25 23:36 ` Denys Vlasenko 2012-01-25 23:36 ` Denys Vlasenko 2012-01-25 23:32 ` Denys Vlasenko 2012-01-25 23:32 ` Denys Vlasenko 2012-01-26 0:40 ` Indan Zupancic 2012-01-26 0:40 ` Indan Zupancic 2012-01-26 1:08 ` Jamie Lokier 2012-01-26 1:08 ` Jamie Lokier 2012-01-26 1:22 ` Denys Vlasenko 2012-01-26 1:22 ` Denys Vlasenko 2012-01-26 6:34 ` Indan Zupancic 2012-01-26 6:34 ` Indan Zupancic 2012-01-26 10:31 ` Jamie Lokier 2012-01-26 10:31 ` Jamie Lokier 2012-01-26 10:40 ` Denys Vlasenko 2012-01-26 10:40 ` Denys Vlasenko 2012-01-26 11:01 ` Jamie Lokier 2012-01-26 11:01 ` Jamie Lokier 2012-01-26 14:02 ` Denys Vlasenko 2012-01-26 14:02 ` Denys Vlasenko 2012-01-26 11:19 ` Indan Zupancic 2012-01-26 11:19 ` Indan Zupancic 2012-01-26 11:20 ` Indan Zupancic 2012-01-26 11:20 ` Indan Zupancic 2012-01-26 11:47 ` Jamie Lokier 2012-01-26 11:47 ` Jamie Lokier 2012-01-26 14:05 ` Denys Vlasenko 2012-01-26 14:05 ` Denys Vlasenko 2012-01-27 7:23 ` Indan Zupancic 2012-01-27 7:23 ` Indan Zupancic 2012-02-10 2:02 ` Jamie Lokier 2012-02-10 2:02 ` Jamie Lokier 2012-02-10 3:37 ` Indan Zupancic 2012-02-10 3:37 ` Indan Zupancic 2012-02-10 21:19 ` Denys Vlasenko 2012-02-10 21:19 ` Denys Vlasenko 2012-01-26 1:09 ` Denys Vlasenko 2012-01-26 1:09 ` Denys Vlasenko 2012-01-26 3:47 ` Linus Torvalds 2012-01-26 3:47 ` Linus Torvalds 2012-01-26 18:03 ` Denys Vlasenko 2012-01-26 18:03 ` Denys Vlasenko 2017-03-08 23:41 ` Dmitry V. Levin 2017-03-08 23:41 ` Dmitry V. Levin 2017-03-09 4:39 ` Andrew Lutomirski 2017-03-09 4:39 ` Andrew Lutomirski 2017-03-14 2:57 ` Dmitry V. Levin 2017-03-14 2:57 ` Dmitry V. Levin 2012-01-26 5:57 ` Indan Zupancic 2012-01-26 5:57 ` Indan Zupancic 2012-01-26 0:59 ` Jamie Lokier 2012-01-26 0:59 ` Jamie Lokier 2012-01-26 1:21 ` Denys Vlasenko 2012-01-26 1:21 ` Denys Vlasenko 2012-01-26 8:23 ` Pedro Alves 2012-01-26 8:23 ` Pedro Alves 2012-01-26 8:53 ` Denys Vlasenko 2012-01-26 8:53 ` Denys Vlasenko 2012-01-26 9:51 ` Pedro Alves 2012-01-26 9:51 ` Pedro Alves 2012-01-26 18:44 ` Oleg Nesterov 2012-01-26 18:44 ` Oleg Nesterov 2012-02-10 2:51 ` Jamie Lokier 2012-02-10 2:51 ` Jamie Lokier 2012-01-18 15:04 ` Compat 32-bit syscall entry from 64-bit task!? [was: Re: [RFC,PATCH 1/2] seccomp_filters: system call filtering using BPF] Eric Paris 2012-01-18 15:04 ` Eric Paris 2012-01-18 17:51 ` Linus Torvalds 2012-01-18 17:51 ` Linus Torvalds 2012-01-18 5:43 ` Chris Evans 2012-01-18 5:43 ` Chris Evans 2012-01-18 12:12 ` Indan Zupancic 2012-01-18 12:12 ` Indan Zupancic 2012-01-18 21:13 ` Chris Evans 2012-01-18 21:13 ` Chris Evans 2012-01-19 0:14 ` Indan Zupancic 2012-01-19 0:14 ` Indan Zupancic 2012-01-19 8:16 ` Chris Evans 2012-01-19 8:16 ` Chris Evans 2012-01-19 11:34 ` Indan Zupancic 2012-01-19 11:34 ` Indan Zupancic 2012-01-19 16:11 ` Jamie Lokier 2012-01-19 16:11 ` Jamie Lokier 2012-01-19 15:40 ` Jamie Lokier 2012-01-19 15:40 ` Jamie Lokier 2012-01-18 17:00 ` Oleg Nesterov 2012-01-18 17:00 ` Oleg Nesterov 2012-01-18 17:12 ` Oleg Nesterov 2012-01-18 17:12 ` Oleg Nesterov 2012-01-18 21:09 ` Chris Evans 2012-01-18 21:09 ` Chris Evans 2012-01-23 16:56 ` Oleg Nesterov 2012-01-23 16:56 ` Oleg Nesterov 2012-01-23 22:23 ` Chris Evans 2012-01-23 22:23 ` Chris Evans 2012-02-07 11:45 ` Indan Zupancic 2012-02-07 11:45 ` Indan Zupancic 2012-01-19 0:29 ` Indan Zupancic 2012-01-19 0:29 ` Indan Zupancic 2012-01-18 2:27 ` Linus Torvalds 2012-01-18 2:27 ` Linus Torvalds 2012-01-18 2:31 ` Andi Kleen 2012-01-18 2:31 ` Andi Kleen 2012-01-18 2:46 ` Linus Torvalds 2012-01-18 2:46 ` Linus Torvalds 2012-01-18 14:06 ` Martin Mares 2012-01-18 14:06 ` Martin Mares 2012-01-18 18:24 ` Andi Kleen 2012-01-18 18:24 ` Andi Kleen 2012-01-19 16:04 ` Jamie Lokier 2012-01-19 16:04 ` Jamie Lokier 2012-01-20 0:21 ` Indan Zupancic 2012-01-20 0:21 ` Indan Zupancic 2012-01-20 0:53 ` Linus Torvalds 2012-01-20 0:53 ` Linus Torvalds 2012-01-20 2:02 ` Indan Zupancic 2012-01-20 2:02 ` Indan Zupancic 2012-01-17 17:06 ` [RFC,PATCH 1/2] seccomp_filters: system call filtering using BPF Will Drewry 2012-01-17 17:06 ` Will Drewry 2012-01-17 19:35 ` Will Drewry 2012-01-17 19:35 ` Will Drewry 2012-01-12 17:02 ` Andrew Lutomirski 2012-01-12 17:02 ` Andrew Lutomirski 2012-01-16 20:28 ` Will Drewry 2012-01-16 20:28 ` Will Drewry 2012-01-11 17:25 ` [RFC,PATCH 2/2] Documentation: prctl/seccomp_filter Will Drewry 2012-01-11 20:03 ` Jonathan Corbet 2012-01-11 20:10 ` Will Drewry 2012-01-11 20:10 ` Will Drewry 2012-01-11 23:19 ` [PATCH v2 " Will Drewry 2012-01-12 0:29 ` Will Drewry 2012-01-12 0:29 ` Will Drewry 2012-01-12 18:16 ` Randy Dunlap 2012-01-12 17:23 ` Will Drewry 2012-01-12 17:34 ` Steven Rostedt 2012-01-12 13:13 ` [RFC,PATCH " Łukasz Sowa 2012-01-12 17:25 ` Will Drewry 2012-01-12 17:25 ` Will Drewry
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=5f13059f9b57d2a0fe2be094702b8177.squirrel@webmail.greenhost.nl \ --to=indan@nul.nu \ --cc=ak@linux.intel.com \ --cc=akpm@linux-foundation.org \ --cc=amwang@redhat.com \ --cc=andi@firstfloor.org \ --cc=avi@redhat.com \ --cc=borislav.petkov@amd.com \ --cc=coreyb@linux.vnet.ibm.com \ --cc=daniel.lezcano@free.fr \ --cc=dhowells@redhat.com \ --cc=djm@mindrot.org \ --cc=dlaor@redhat.com \ --cc=eparis@redhat.com \ --cc=eric.dumazet@gmail.com \ --cc=hjl.tools@gmail.com \ --cc=hpa@zytor.com \ --cc=jamie@shareable.org \ --cc=jmorris@namei.org \ --cc=john.johansen@canonical.com \ --cc=keescook@chromium.org \ --cc=khilman@ti.com \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-security-module@vger.kernel.org \ --cc=luto@mit.edu \ --cc=mcgrathr@chromium.org \ --cc=mhalcrow@google.com \ --cc=mingo@elte.hu \ --cc=oleg@redhat.com \ --cc=olofj@chromium.org \ --cc=penberg@cs.helsinki.fi \ --cc=pmoore@redhat.com \ --cc=rostedt@goodmis.org \ --cc=scarybeasts@gmail.com \ --cc=segoon@openwall.com \ --cc=serge.hallyn@canonical.com \ --cc=torvalds@linux-foundation.org \ --cc=viro@zeniv.linux.org.uk \ --cc=wad@chromium.org \ /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.