Re: [PATCH v2 1/2] x86_64,signal: Fix SS handling for signals delivered to 64-bit programs

2015-03-12 Thread Andy Lutomirski
On Mar 11, 2015 4:32 AM, "Borislav Petkov" wrote: > > On Tue, Mar 10, 2015 at 07:03:24AM -0700, Andy Lutomirski wrote: > > The comment in the signal code says that apps can save/restore other > > segments on their own. It's true that apps can *save* SS on their > > own, but there's no way for

Re: [PATCH v2 1/2] x86_64,signal: Fix SS handling for signals delivered to 64-bit programs

2015-03-12 Thread Andy Lutomirski
On Mar 11, 2015 4:32 AM, Borislav Petkov b...@alien8.de wrote: On Tue, Mar 10, 2015 at 07:03:24AM -0700, Andy Lutomirski wrote: The comment in the signal code says that apps can save/restore other segments on their own. It's true that apps can *save* SS on their own, but there's no way

Re: [PATCH v2 1/2] x86_64,signal: Fix SS handling for signals delivered to 64-bit programs

2015-03-11 Thread Borislav Petkov
On Tue, Mar 10, 2015 at 07:03:24AM -0700, Andy Lutomirski wrote: > The comment in the signal code says that apps can save/restore other > segments on their own. It's true that apps can *save* SS on their > own, but there's no way for apps to restore it: SYSCALL effectively > resets SS to

Re: [PATCH v2 1/2] x86_64,signal: Fix SS handling for signals delivered to 64-bit programs

2015-03-11 Thread Borislav Petkov
On Tue, Mar 10, 2015 at 07:03:24AM -0700, Andy Lutomirski wrote: The comment in the signal code says that apps can save/restore other segments on their own. It's true that apps can *save* SS on their own, but there's no way for apps to restore it: SYSCALL effectively resets SS to __USER_DS,

Re: [PATCH v2 1/2] x86_64,signal: Fix SS handling for signals delivered to 64-bit programs

2015-03-10 Thread Andy Lutomirski
On Tue, Mar 10, 2015 at 9:42 AM, Oleg Nesterov wrote: > Well, the patch looks "obviously fine" to me, but this is all I can say. > > I mean, I simply can't understand this __pad0/ifdef(CONFIG_X86_32), it > looks as if ->ss was specially excluded for unknown reason from the very > beginning. I

Re: [PATCH v2 1/2] x86_64,signal: Fix SS handling for signals delivered to 64-bit programs

2015-03-10 Thread Oleg Nesterov
Well, the patch looks "obviously fine" to me, but this is all I can say. I mean, I simply can't understand this __pad0/ifdef(CONFIG_X86_32), it looks as if ->ss was specially excluded for unknown reason from the very beginning. On 03/10, Andy Lutomirski wrote: > > > ---

Re: [PATCH v2 1/2] x86_64,signal: Fix SS handling for signals delivered to 64-bit programs

2015-03-10 Thread Andy Lutomirski
[cc: Oleg, Borislav] On Tue, Mar 10, 2015 at 7:03 AM, Andy Lutomirski wrote: > The comment in the signal code says that apps can save/restore other > segments on their own. It's true that apps can *save* SS on their > own, but there's no way for apps to restore it: SYSCALL effectively > resets

Re: [PATCH v2 1/2] x86_64,signal: Fix SS handling for signals delivered to 64-bit programs

2015-03-10 Thread Andy Lutomirski
[cc: Oleg, Borislav] On Tue, Mar 10, 2015 at 7:03 AM, Andy Lutomirski l...@amacapital.net wrote: The comment in the signal code says that apps can save/restore other segments on their own. It's true that apps can *save* SS on their own, but there's no way for apps to restore it: SYSCALL

Re: [PATCH v2 1/2] x86_64,signal: Fix SS handling for signals delivered to 64-bit programs

2015-03-10 Thread Oleg Nesterov
Well, the patch looks obviously fine to me, but this is all I can say. I mean, I simply can't understand this __pad0/ifdef(CONFIG_X86_32), it looks as if -ss was specially excluded for unknown reason from the very beginning. On 03/10, Andy Lutomirski wrote: ---

Re: [PATCH v2 1/2] x86_64,signal: Fix SS handling for signals delivered to 64-bit programs

2015-03-10 Thread Andy Lutomirski
On Tue, Mar 10, 2015 at 9:42 AM, Oleg Nesterov o...@redhat.com wrote: Well, the patch looks obviously fine to me, but this is all I can say. I mean, I simply can't understand this __pad0/ifdef(CONFIG_X86_32), it looks as if -ss was specially excluded for unknown reason from the very