Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 10:30:44PM +0200, Peter Zijlstra wrote: > On stack variable length arrays get implemented by the compiler doing > alloca(), and we sadly have a few of those around. I've just got rid of one of those and I wish they would appear entirely as they are horrible in so many

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 10:30:44PM +0200, Peter Zijlstra wrote: > On stack variable length arrays get implemented by the compiler doing > alloca(), and we sadly have a few of those around. I've just got rid of one of those and I wish they would appear entirely as they are horrible in so many

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 12:15 AM, Al Viro wrote: > Folks, seriously, have you even looked through that zoo? I have, and it's > really, really not fun. Sure, we can say "fuck 'em, no need to allow > splice() on random crap". Would be perfectly reasonable, expect that >

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 12:15 AM, Al Viro wrote: > Folks, seriously, have you even looked through that zoo? I have, and it's > really, really not fun. Sure, we can say "fuck 'em, no need to allow > splice() on random crap". Would be perfectly reasonable, expect that > it's not the only place

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 05:47:55PM -0400, Rik van Riel wrote: > > Seriously, look at these beasts.  Overwriting ->addr_limit is nowhere > > near > > the top threat.  If attacker can overwrite thread_info, you have > > lost. > > That is why THREAD_INFO_IN_TASK exists. It moves > the struct

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 05:47:55PM -0400, Rik van Riel wrote: > > Seriously, look at these beasts.  Overwriting ->addr_limit is nowhere > > near > > the top threat.  If attacker can overwrite thread_info, you have > > lost. > > That is why THREAD_INFO_IN_TASK exists. It moves > the struct

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 2:41 PM, Al Viro wrote: > On Fri, May 12, 2017 at 02:17:19PM -0700, Kees Cook wrote: > >> Two things are at risk from stack exhaustion: thread_info (mainly >> addr_limit) when on the stack (fixed by THREAD_INFO_IN_TASK), and > > Really? Let's take

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 2:41 PM, Al Viro wrote: > On Fri, May 12, 2017 at 02:17:19PM -0700, Kees Cook wrote: > >> Two things are at risk from stack exhaustion: thread_info (mainly >> addr_limit) when on the stack (fixed by THREAD_INFO_IN_TASK), and > > Really? Let's take a look at arm, for

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, 2017-05-12 at 22:41 +0100, Al Viro wrote: > On Fri, May 12, 2017 at 02:17:19PM -0700, Kees Cook wrote: > > > Two things are at risk from stack exhaustion: thread_info (mainly > > addr_limit) when on the stack (fixed by THREAD_INFO_IN_TASK), and > > Really?  Let's take a look at arm, for

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, 2017-05-12 at 22:41 +0100, Al Viro wrote: > On Fri, May 12, 2017 at 02:17:19PM -0700, Kees Cook wrote: > > > Two things are at risk from stack exhaustion: thread_info (mainly > > addr_limit) when on the stack (fixed by THREAD_INFO_IN_TASK), and > > Really?  Let's take a look at arm, for

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 02:17:19PM -0700, Kees Cook wrote: > Two things are at risk from stack exhaustion: thread_info (mainly > addr_limit) when on the stack (fixed by THREAD_INFO_IN_TASK), and Really? Let's take a look at arm, for example: struct thread_info { unsigned long

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 02:17:19PM -0700, Kees Cook wrote: > Two things are at risk from stack exhaustion: thread_info (mainly > addr_limit) when on the stack (fixed by THREAD_INFO_IN_TASK), and Really? Let's take a look at arm, for example: struct thread_info { unsigned long

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

> overflow into adjacent allocations (fixed by VMAP_STACK). 99% fixed, but it's possible to skip over the guard page without -fstack-check enabled (plus some edge cases need to be fixed in GCC), unless VLAs were forbidden in addition to the existing large frame size warning. I'm not sure about

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

> overflow into adjacent allocations (fixed by VMAP_STACK). 99% fixed, but it's possible to skip over the guard page without -fstack-check enabled (plus some edge cases need to be fixed in GCC), unless VLAs were forbidden in addition to the existing large frame size warning. I'm not sure about

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 2:06 PM, Al Viro wrote: > On Fri, May 12, 2017 at 09:21:06PM +0100, Russell King - ARM Linux wrote: >> On Fri, May 12, 2017 at 12:30:02PM -0700, Kees Cook wrote: >> > I'm clearly not explaining things well enough. I shouldn't say >> > "corruption",

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 2:06 PM, Al Viro wrote: > On Fri, May 12, 2017 at 09:21:06PM +0100, Russell King - ARM Linux wrote: >> On Fri, May 12, 2017 at 12:30:02PM -0700, Kees Cook wrote: >> > I'm clearly not explaining things well enough. I shouldn't say >> > "corruption", I should say "malicious

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, 2017-05-12 at 22:06 +0100, Al Viro wrote: > On Fri, May 12, 2017 at 09:21:06PM +0100, Russell King - ARM Linux > wrote: > > On Fri, May 12, 2017 at 12:30:02PM -0700, Kees Cook wrote: > > > I'm clearly not explaining things well enough. I shouldn't say > > > "corruption", I should say

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, 2017-05-12 at 22:06 +0100, Al Viro wrote: > On Fri, May 12, 2017 at 09:21:06PM +0100, Russell King - ARM Linux > wrote: > > On Fri, May 12, 2017 at 12:30:02PM -0700, Kees Cook wrote: > > > I'm clearly not explaining things well enough. I shouldn't say > > > "corruption", I should say

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 09:21:06PM +0100, Russell King - ARM Linux wrote: > On Fri, May 12, 2017 at 12:30:02PM -0700, Kees Cook wrote: > > I'm clearly not explaining things well enough. I shouldn't say > > "corruption", I should say "malicious manipulation". The methodology > > of attacks against

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 09:21:06PM +0100, Russell King - ARM Linux wrote: > On Fri, May 12, 2017 at 12:30:02PM -0700, Kees Cook wrote: > > I'm clearly not explaining things well enough. I shouldn't say > > "corruption", I should say "malicious manipulation". The methodology > > of attacks against

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 2:00 PM, Kees Cook wrote: > On Fri, May 12, 2017 at 1:45 PM, Russell King - ARM Linux > wrote: >> On Fri, May 12, 2017 at 10:30:44PM +0200, Peter Zijlstra wrote: >>> On Fri, May 12, 2017 at 09:21:06PM +0100, Russell King - ARM

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 2:00 PM, Kees Cook wrote: > On Fri, May 12, 2017 at 1:45 PM, Russell King - ARM Linux > wrote: >> On Fri, May 12, 2017 at 10:30:44PM +0200, Peter Zijlstra wrote: >>> On Fri, May 12, 2017 at 09:21:06PM +0100, Russell King - ARM Linux wrote: >>> > On Fri, May 12, 2017 at

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 1:45 PM, Russell King - ARM Linux wrote: > On Fri, May 12, 2017 at 10:30:44PM +0200, Peter Zijlstra wrote: >> On Fri, May 12, 2017 at 09:21:06PM +0100, Russell King - ARM Linux wrote: >> > On Fri, May 12, 2017 at 12:30:02PM -0700, Kees Cook wrote: >>

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 1:45 PM, Russell King - ARM Linux wrote: > On Fri, May 12, 2017 at 10:30:44PM +0200, Peter Zijlstra wrote: >> On Fri, May 12, 2017 at 09:21:06PM +0100, Russell King - ARM Linux wrote: >> > On Fri, May 12, 2017 at 12:30:02PM -0700, Kees Cook wrote: >> > > I'm clearly not

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 10:30:44PM +0200, Peter Zijlstra wrote: > On Fri, May 12, 2017 at 09:21:06PM +0100, Russell King - ARM Linux wrote: > > On Fri, May 12, 2017 at 12:30:02PM -0700, Kees Cook wrote: > > > I'm clearly not explaining things well enough. I shouldn't say > > > "corruption", I

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 10:30:44PM +0200, Peter Zijlstra wrote: > On Fri, May 12, 2017 at 09:21:06PM +0100, Russell King - ARM Linux wrote: > > On Fri, May 12, 2017 at 12:30:02PM -0700, Kees Cook wrote: > > > I'm clearly not explaining things well enough. I shouldn't say > > > "corruption", I

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 09:21:06PM +0100, Russell King - ARM Linux wrote: > On Fri, May 12, 2017 at 12:30:02PM -0700, Kees Cook wrote: > > I'm clearly not explaining things well enough. I shouldn't say > > "corruption", I should say "malicious manipulation". The methodology > > of attacks against

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 09:21:06PM +0100, Russell King - ARM Linux wrote: > On Fri, May 12, 2017 at 12:30:02PM -0700, Kees Cook wrote: > > I'm clearly not explaining things well enough. I shouldn't say > > "corruption", I should say "malicious manipulation". The methodology > > of attacks against

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 12:30:02PM -0700, Kees Cook wrote: > I'm clearly not explaining things well enough. I shouldn't say > "corruption", I should say "malicious manipulation". The methodology > of attacks against the stack are quite different from the other kinds > of attacks like

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 12:30:02PM -0700, Kees Cook wrote: > I'm clearly not explaining things well enough. I shouldn't say > "corruption", I should say "malicious manipulation". The methodology > of attacks against the stack are quite different from the other kinds > of attacks like

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 12:08 PM, Linus Torvalds wrote: > On Fri, May 12, 2017 at 12:01 PM, Kees Cook wrote: >> Yeah, the risk for "corrupted addr_limit" is mainly a concern for >> archs with addr_limit on the kernel stack. If I'm reading

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 12:08 PM, Linus Torvalds wrote: > On Fri, May 12, 2017 at 12:01 PM, Kees Cook wrote: >> Yeah, the risk for "corrupted addr_limit" is mainly a concern for >> archs with addr_limit on the kernel stack. If I'm reading things >> correctly, that means, from the archs I've been

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 12:01:59PM -0700, Kees Cook wrote: > Yeah, the risk for "corrupted addr_limit" is mainly a concern for > archs with addr_limit on the kernel stack. If I'm reading things > correctly, that means, from the archs I've been paying closer > attention to, it's an issue for arm,

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 12:01:59PM -0700, Kees Cook wrote: > Yeah, the risk for "corrupted addr_limit" is mainly a concern for > archs with addr_limit on the kernel stack. If I'm reading things > correctly, that means, from the archs I've been paying closer > attention to, it's an issue for arm,

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 12:01 PM, Kees Cook wrote: > > Yeah, the risk for "corrupted addr_limit" is mainly a concern for > archs with addr_limit on the kernel stack. If I'm reading things > correctly, that means, from the archs I've been paying closer > attention to, it's

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 12:01 PM, Kees Cook wrote: > > Yeah, the risk for "corrupted addr_limit" is mainly a concern for > archs with addr_limit on the kernel stack. If I'm reading things > correctly, that means, from the archs I've been paying closer > attention to, it's an issue for arm, mips,

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Thu, May 11, 2017 at 10:54 PM, Martin Schwidefsky wrote: > On Thu, 11 May 2017 22:34:31 -0700 > Kees Cook wrote: > >> On Thu, May 11, 2017 at 10:28 PM, Martin Schwidefsky >> wrote: >> > On Thu, 11 May 2017 16:44:07 -0700

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Thu, May 11, 2017 at 10:54 PM, Martin Schwidefsky wrote: > On Thu, 11 May 2017 22:34:31 -0700 > Kees Cook wrote: > >> On Thu, May 11, 2017 at 10:28 PM, Martin Schwidefsky >> wrote: >> > On Thu, 11 May 2017 16:44:07 -0700 >> > Linus Torvalds wrote: >> > >> >> On Thu, May 11, 2017 at 4:17 PM,

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Thu, May 11, 2017 at 11:58 PM, Ingo Molnar wrote: > > * Linus Torvalds wrote: > >> On Thu, May 11, 2017 at 4:17 PM, Thomas Garnier wrote: >> > >> > Ingo: Do you want the change as-is? Would you like it to be optional? >> >

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Thu, May 11, 2017 at 11:58 PM, Ingo Molnar wrote: > > * Linus Torvalds wrote: > >> On Thu, May 11, 2017 at 4:17 PM, Thomas Garnier wrote: >> > >> > Ingo: Do you want the change as-is? Would you like it to be optional? >> > What do you think? >> >> I'm not ingo, but I don't like that patch.

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 10:11 AM, Al Viro wrote: > Anyway, what's special about modules? IDGI... One of the arguments that came up earlier was code in external modules being mostly unaudited, sometimes without any source code available at all but still used in devices.

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 10:11 AM, Al Viro wrote: > Anyway, what's special about modules? IDGI... One of the arguments that came up earlier was code in external modules being mostly unaudited, sometimes without any source code available at all but still used in devices. If modules can't do

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 01:11:26AM -0700, Christoph Hellwig wrote: > But it won't help against exploits modifying addr_limit manually. Or the ones setting current->cred to that of init. Your point being?

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 01:11:26AM -0700, Christoph Hellwig wrote: > But it won't help against exploits modifying addr_limit manually. Or the ones setting current->cred to that of init. Your point being?

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 09:43:40AM +0200, Arnd Bergmann wrote: > How realistic and how useful would it be to first completely eliminate > the ones that are in loadable modules and then wrapping the definition > in #ifndef MODULE (or even make it an extern function)? Eliminate _what_? ->read()

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 09:43:40AM +0200, Arnd Bergmann wrote: > How realistic and how useful would it be to first completely eliminate > the ones that are in loadable modules and then wrapping the definition > in #ifndef MODULE (or even make it an extern function)? Eliminate _what_? ->read()

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 09:43:40AM +0200, Arnd Bergmann wrote: > How realistic and how useful would it be to first completely eliminate > the ones that are in loadable modules and then wrapping the definition > in #ifndef MODULE (or even make it an extern function)? Should be fairly doable and

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 09:43:40AM +0200, Arnd Bergmann wrote: > How realistic and how useful would it be to first completely eliminate > the ones that are in loadable modules and then wrapping the definition > in #ifndef MODULE (or even make it an extern function)? Should be fairly doable and

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 9:15 AM, Al Viro wrote: > On Fri, May 12, 2017 at 09:00:12AM +0200, Ingo Molnar wrote: > >> > How about trying to remove all of them? If we could actually get rid >> > of all of them, we could drop the arch support, and we'd get faster, >> >

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 9:15 AM, Al Viro wrote: > On Fri, May 12, 2017 at 09:00:12AM +0200, Ingo Molnar wrote: > >> > How about trying to remove all of them? If we could actually get rid >> > of all of them, we could drop the arch support, and we'd get faster, >> > simpler, shorter uaccess code

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 08:15:49AM +0100, Al Viro wrote: > And converting everything to ->read_iter()/->write_iter() means an insane > amount of code churn, not to mention coping with random bogosities in > semantics. ->read() and ->write() are going to stay around, pretty > much indefinitely.

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 08:15:49AM +0100, Al Viro wrote: > And converting everything to ->read_iter()/->write_iter() means an insane > amount of code churn, not to mention coping with random bogosities in > semantics. ->read() and ->write() are going to stay around, pretty > much indefinitely.

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 09:00:12AM +0200, Ingo Molnar wrote: > > How about trying to remove all of them? If we could actually get rid > > of all of them, we could drop the arch support, and we'd get faster, > > simpler, shorter uaccess code throughout the kernel. > > I'm all for that! Oh,

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 09:00:12AM +0200, Ingo Molnar wrote: > > How about trying to remove all of them? If we could actually get rid > > of all of them, we could drop the arch support, and we'd get faster, > > simpler, shorter uaccess code throughout the kernel. > > I'm all for that! Oh,

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

* Andy Lutomirski wrote: > On Tue, May 9, 2017 at 1:56 AM, Christoph Hellwig wrote: > > On Tue, May 09, 2017 at 08:45:22AM +0200, Ingo Molnar wrote: > >> We only have ~115 code blocks in the kernel that set/restore KERNEL_DS, it > >> would > >> be a pity

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

* Andy Lutomirski wrote: > On Tue, May 9, 2017 at 1:56 AM, Christoph Hellwig wrote: > > On Tue, May 09, 2017 at 08:45:22AM +0200, Ingo Molnar wrote: > >> We only have ~115 code blocks in the kernel that set/restore KERNEL_DS, it > >> would > >> be a pity to add a runtime check to every system

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

* Linus Torvalds wrote: > On Thu, May 11, 2017 at 4:17 PM, Thomas Garnier wrote: > > > > Ingo: Do you want the change as-is? Would you like it to be optional? > > What do you think? > > I'm not ingo, but I don't like that patch. It's in the

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

* Linus Torvalds wrote: > On Thu, May 11, 2017 at 4:17 PM, Thomas Garnier wrote: > > > > Ingo: Do you want the change as-is? Would you like it to be optional? > > What do you think? > > I'm not ingo, but I don't like that patch. It's in the wrong place - > that system call return code is too

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

* Kees Cook wrote: > > git commit b5a882fcf146c87cb6b67c6df353e1c042b8773d > > "s390: restore address space when returning to user space". > > If I'm understanding this, it won't catch corruption of addr_limit > during fast-path syscalls, though (i.e. addr_limit changed

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

* Kees Cook wrote: > > git commit b5a882fcf146c87cb6b67c6df353e1c042b8773d > > "s390: restore address space when returning to user space". > > If I'm understanding this, it won't catch corruption of addr_limit > during fast-path syscalls, though (i.e. addr_limit changed without a > call to

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

[resending because kernel.org seems to have mangled my SMTP credentials. I wonder if this is a common problem.] On Thu, May 11, 2017 at 4:44 PM, Linus Torvalds wrote: > On Thu, May 11, 2017 at 4:17 PM, Thomas Garnier wrote: >> >> Ingo: Do you

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

[resending because kernel.org seems to have mangled my SMTP credentials. I wonder if this is a common problem.] On Thu, May 11, 2017 at 4:44 PM, Linus Torvalds wrote: > On Thu, May 11, 2017 at 4:17 PM, Thomas Garnier wrote: >> >> Ingo: Do you want the change as-is? Would you like it to be

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Thu, 11 May 2017 22:34:31 -0700 Kees Cook wrote: > On Thu, May 11, 2017 at 10:28 PM, Martin Schwidefsky > wrote: > > On Thu, 11 May 2017 16:44:07 -0700 > > Linus Torvalds wrote: > > > >> On Thu, May 11, 2017 at

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Thu, 11 May 2017 22:34:31 -0700 Kees Cook wrote: > On Thu, May 11, 2017 at 10:28 PM, Martin Schwidefsky > wrote: > > On Thu, 11 May 2017 16:44:07 -0700 > > Linus Torvalds wrote: > > > >> On Thu, May 11, 2017 at 4:17 PM, Thomas Garnier > >> wrote: > >> > > >> > Ingo: Do you want the

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Thu, May 11, 2017 at 10:28 PM, Martin Schwidefsky wrote: > On Thu, 11 May 2017 16:44:07 -0700 > Linus Torvalds wrote: > >> On Thu, May 11, 2017 at 4:17 PM, Thomas Garnier wrote: >> > >> > Ingo: Do you want the change

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Thu, May 11, 2017 at 10:28 PM, Martin Schwidefsky wrote: > On Thu, 11 May 2017 16:44:07 -0700 > Linus Torvalds wrote: > >> On Thu, May 11, 2017 at 4:17 PM, Thomas Garnier wrote: >> > >> > Ingo: Do you want the change as-is? Would you like it to be optional? >> > What do you think? >> >> I'm

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Thu, 11 May 2017 16:44:07 -0700 Linus Torvalds wrote: > On Thu, May 11, 2017 at 4:17 PM, Thomas Garnier wrote: > > > > Ingo: Do you want the change as-is? Would you like it to be optional? > > What do you think? > > I'm not ingo, but I

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Thu, 11 May 2017 16:44:07 -0700 Linus Torvalds wrote: > On Thu, May 11, 2017 at 4:17 PM, Thomas Garnier wrote: > > > > Ingo: Do you want the change as-is? Would you like it to be optional? > > What do you think? > > I'm not ingo, but I don't like that patch. It's in the wrong place - >

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Thu, May 11, 2017 at 4:17 PM, Thomas Garnier wrote: > > Ingo: Do you want the change as-is? Would you like it to be optional? > What do you think? I'm not ingo, but I don't like that patch. It's in the wrong place - that system call return code is too timing-critical to

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Thu, May 11, 2017 at 4:17 PM, Thomas Garnier wrote: > > Ingo: Do you want the change as-is? Would you like it to be optional? > What do you think? I'm not ingo, but I don't like that patch. It's in the wrong place - that system call return code is too timing-critical to add address limit

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Tue, May 9, 2017 at 7:29 AM, Thomas Garnier wrote: > > On Tue, May 9, 2017 at 4:10 AM, Greg KH wrote: > > On Tue, May 09, 2017 at 08:56:19AM +0200, Ingo Molnar wrote: > >> > >> * Kees Cook wrote: > >> > >> > > There's the option of

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Tue, May 9, 2017 at 7:29 AM, Thomas Garnier wrote: > > On Tue, May 9, 2017 at 4:10 AM, Greg KH wrote: > > On Tue, May 09, 2017 at 08:56:19AM +0200, Ingo Molnar wrote: > >> > >> * Kees Cook wrote: > >> > >> > > There's the option of using GCC plugins now that the infrastructure was > >> > >

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Tue, May 09, 2017 at 04:31:00PM -0700, Kees Cook wrote: > > I don't like silent fixups. If we want to do this, we should BUG or > > at least WARN, not just change the addr limit. But I'm also not > > convinced it's indicative of an actual bug here. > > Nothing should enter that function with

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Tue, May 09, 2017 at 04:31:00PM -0700, Kees Cook wrote: > > I don't like silent fixups. If we want to do this, we should BUG or > > at least WARN, not just change the addr limit. But I'm also not > > convinced it's indicative of an actual bug here. > > Nothing should enter that function with

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Wed, May 10, 2017 at 1:14 AM, Christoph Hellwig wrote: > On Wed, May 10, 2017 at 09:08:41AM +0100, Al Viro wrote: >> On Wed, May 10, 2017 at 09:37:04AM +0200, Arnd Bergmann wrote: >> >> > > How about trying to remove all of them? If we could actually get rid >> > > of all

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Wed, May 10, 2017 at 1:14 AM, Christoph Hellwig wrote: > On Wed, May 10, 2017 at 09:08:41AM +0100, Al Viro wrote: >> On Wed, May 10, 2017 at 09:37:04AM +0200, Arnd Bergmann wrote: >> >> > > How about trying to remove all of them? If we could actually get rid >> > > of all of them, we could

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Wed, May 10, 2017 at 09:08:41AM +0100, Al Viro wrote: > On Wed, May 10, 2017 at 09:37:04AM +0200, Arnd Bergmann wrote: > > > > How about trying to remove all of them? If we could actually get rid > > > of all of them, we could drop the arch support, and we'd get faster, > > > simpler, shorter

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Wed, May 10, 2017 at 09:08:41AM +0100, Al Viro wrote: > On Wed, May 10, 2017 at 09:37:04AM +0200, Arnd Bergmann wrote: > > > > How about trying to remove all of them? If we could actually get rid > > > of all of them, we could drop the arch support, and we'd get faster, > > > simpler, shorter

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Wed, May 10, 2017 at 09:37:04AM +0200, Arnd Bergmann wrote: > > How about trying to remove all of them? If we could actually get rid > > of all of them, we could drop the arch support, and we'd get faster, > > simpler, shorter uaccess code throughout the kernel. BTW, not all get_user() under

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Wed, May 10, 2017 at 09:37:04AM +0200, Arnd Bergmann wrote: > > How about trying to remove all of them? If we could actually get rid > > of all of them, we could drop the arch support, and we'd get faster, > > simpler, shorter uaccess code throughout the kernel. BTW, not all get_user() under

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Tue, May 9, 2017 at 3:00 PM, Andy Lutomirski wrote: > On Tue, May 9, 2017 at 1:56 AM, Christoph Hellwig wrote: >> On Tue, May 09, 2017 at 08:45:22AM +0200, Ingo Molnar wrote: >>> We only have ~115 code blocks in the kernel that set/restore KERNEL_DS, it

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Tue, May 9, 2017 at 3:00 PM, Andy Lutomirski wrote: > On Tue, May 9, 2017 at 1:56 AM, Christoph Hellwig wrote: >> On Tue, May 09, 2017 at 08:45:22AM +0200, Ingo Molnar wrote: >>> We only have ~115 code blocks in the kernel that set/restore KERNEL_DS, it >>> would >>> be a pity to add a

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Wed, May 10, 2017 at 09:28:48AM +0200, Arnd Bergmann wrote: > My older time64_t syscall series has the side-effect of doing something > like this to the time-related compat handlers in kernel/compat.c. If nobody > else has started looking at removing set_fs from those, I can extract > the

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Wed, May 10, 2017 at 09:28:48AM +0200, Arnd Bergmann wrote: > My older time64_t syscall series has the side-effect of doing something > like this to the time-related compat handlers in kernel/compat.c. If nobody > else has started looking at removing set_fs from those, I can extract > the

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Wed, May 10, 2017 at 08:27:47AM +0100, Al Viro wrote: > And you *still* do the same. Christoph, this is ridiculous - the worst > part of the area is not a couple of functions in fs/read_write.c, it's > a fucking lot of ->read() and ->write() instances in shitty driver code, > pardon the

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Wed, May 10, 2017 at 08:27:47AM +0100, Al Viro wrote: > And you *still* do the same. Christoph, this is ridiculous - the worst > part of the area is not a couple of functions in fs/read_write.c, it's > a fucking lot of ->read() and ->write() instances in shitty driver code, > pardon the

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Tue, May 09, 2017 at 11:53:01PM -0700, Christoph Hellwig wrote: > On Wed, May 10, 2017 at 04:12:54AM +0100, Al Viro wrote: > > What's the point? What's wrong with having > > kernel_read()/kernel_readv()/etc.? > > You still have set_fs() in there; doing that one level up in call chain > >

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Tue, May 09, 2017 at 11:53:01PM -0700, Christoph Hellwig wrote: > On Wed, May 10, 2017 at 04:12:54AM +0100, Al Viro wrote: > > What's the point? What's wrong with having > > kernel_read()/kernel_readv()/etc.? > > You still have set_fs() in there; doing that one level up in call chain > >

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Tue, May 9, 2017 at 6:03 PM, Christoph Hellwig wrote: > On Tue, May 09, 2017 at 06:02:50AM -0700, Christoph Hellwig wrote: >> On Tue, May 09, 2017 at 06:00:01AM -0700, Andy Lutomirski wrote: >> > fs/splice.c has some, ahem, interesting uses that have been the source >> > of

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Tue, May 9, 2017 at 6:03 PM, Christoph Hellwig wrote: > On Tue, May 09, 2017 at 06:02:50AM -0700, Christoph Hellwig wrote: >> On Tue, May 09, 2017 at 06:00:01AM -0700, Andy Lutomirski wrote: >> > fs/splice.c has some, ahem, interesting uses that have been the source >> > of nasty exploits in

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Tue, May 09, 2017 at 04:31:00PM -0700, Kees Cook wrote: > > I don't like silent fixups. If we want to do this, we should BUG or > > at least WARN, not just change the addr limit. But I'm also not > > convinced it's indicative of an actual bug here. > > Nothing should enter that function with

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Tue, May 09, 2017 at 04:31:00PM -0700, Kees Cook wrote: > > I don't like silent fixups. If we want to do this, we should BUG or > > at least WARN, not just change the addr limit. But I'm also not > > convinced it's indicative of an actual bug here. > > Nothing should enter that function with

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Wed, May 10, 2017 at 04:39:12AM +0100, Al Viro wrote: > fcntl stuff: I've decided not to put something similar into work.compat > since I couldn't decide what to do with compat stuff - word-by-word copy > from userland converting to struct flock + conversion to posix_lock + > actual work +

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Wed, May 10, 2017 at 04:39:12AM +0100, Al Viro wrote: > fcntl stuff: I've decided not to put something similar into work.compat > since I couldn't decide what to do with compat stuff - word-by-word copy > from userland converting to struct flock + conversion to posix_lock + > actual work +

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Wed, May 10, 2017 at 04:12:54AM +0100, Al Viro wrote: > What's the point? What's wrong with having kernel_read()/kernel_readv()/etc.? > You still have set_fs() in there; doing that one level up in call chain would > be just fine... IDGI. The problem is that they modify the address limit,

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Wed, May 10, 2017 at 04:12:54AM +0100, Al Viro wrote: > What's the point? What's wrong with having kernel_read()/kernel_readv()/etc.? > You still have set_fs() in there; doing that one level up in call chain would > be just fine... IDGI. The problem is that they modify the address limit,

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Wed, May 10, 2017 at 03:45:24AM +0100, Al Viro wrote: > FWIW, some parts of that queue are obviously sane; it's the conversions of > kernel_write() and friends to ->read_iter/->write_iter() that are > non-starters. And that part is the main point! > That stuff is used in too many situations;

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Wed, May 10, 2017 at 03:45:24AM +0100, Al Viro wrote: > FWIW, some parts of that queue are obviously sane; it's the conversions of > kernel_write() and friends to ->read_iter/->write_iter() that are > non-starters. And that part is the main point! > That stuff is used in too many situations;

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Tue, May 09, 2017 at 09:50:32AM -0700, Kees Cook wrote: > http://git.infradead.org/users/hch/vfs.git/commitdiff/018e0e9030777121fe87e89d43066691e7366587 > This accidentally(?) removes the kernel-doc comments. That was sort of intentional, the kerneldoc boilerplate adds very little value for

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Tue, May 09, 2017 at 09:50:32AM -0700, Kees Cook wrote: > http://git.infradead.org/users/hch/vfs.git/commitdiff/018e0e9030777121fe87e89d43066691e7366587 > This accidentally(?) removes the kernel-doc comments. That was sort of intentional, the kerneldoc boilerplate adds very little value for

  1   2   >