Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Mon, Apr 10, 2017 at 12:47 PM, PaX Team wrote: > On 9 Apr 2017 at 17:31, Andy Lutomirski wrote: > >> On Sun, Apr 9, 2017 at 1:24 PM, PaX Team wrote: >> > >> I consider breaking buggy drivers (in a way that they either generally >> work okay > > do

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Mon, Apr 10, 2017 at 12:47 PM, PaX Team wrote: > On 9 Apr 2017 at 17:31, Andy Lutomirski wrote: > >> On Sun, Apr 9, 2017 at 1:24 PM, PaX Team wrote: >> > >> I consider breaking buggy drivers (in a way that they either generally >> work okay > > do they work okay when the dma transfer goes to

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Mon, Apr 10, 2017 at 1:13 PM, Kees Cook wrote: > On Sun, Apr 9, 2017 at 1:24 PM, PaX Team wrote: >> On 7 Apr 2017 at 22:07, Andy Lutomirski wrote: >>> No one has explained how CR0.WP is weaker or slower than my proposal. >> >> you misunderstood,

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Mon, Apr 10, 2017 at 1:13 PM, Kees Cook wrote: > On Sun, Apr 9, 2017 at 1:24 PM, PaX Team wrote: >> On 7 Apr 2017 at 22:07, Andy Lutomirski wrote: >>> No one has explained how CR0.WP is weaker or slower than my proposal. >> >> you misunderstood, Daniel was talking about your use_mm approach.

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Sun, Apr 9, 2017 at 1:24 PM, PaX Team wrote: > On 7 Apr 2017 at 22:07, Andy Lutomirski wrote: >> No one has explained how CR0.WP is weaker or slower than my proposal. > > you misunderstood, Daniel was talking about your use_mm approach. > >> Here's what I'm proposing: >>

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Sun, Apr 9, 2017 at 1:24 PM, PaX Team wrote: > On 7 Apr 2017 at 22:07, Andy Lutomirski wrote: >> No one has explained how CR0.WP is weaker or slower than my proposal. > > you misunderstood, Daniel was talking about your use_mm approach. > >> Here's what I'm proposing: >> >> At boot, choose a

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On 10 Apr 2017 at 10:26, Thomas Gleixner wrote: > On Fri, 7 Apr 2017, PaX Team wrote: > > On 7 Apr 2017 at 11:46, Thomas Gleixner wrote: > > > That's silly. Just because PaX does it, doesn't mean it's correct. > > > > is that FUD or do you have actionable information to share? > > That has

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On 10 Apr 2017 at 10:26, Thomas Gleixner wrote: > On Fri, 7 Apr 2017, PaX Team wrote: > > On 7 Apr 2017 at 11:46, Thomas Gleixner wrote: > > > That's silly. Just because PaX does it, doesn't mean it's correct. > > > > is that FUD or do you have actionable information to share? > > That has

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On 9 Apr 2017 at 17:31, Andy Lutomirski wrote: > On Sun, Apr 9, 2017 at 1:24 PM, PaX Team wrote: > > > I consider breaking buggy drivers (in a way that they either generally > work okay do they work okay when the dma transfer goes to a buffer that crosses physically

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On 9 Apr 2017 at 17:31, Andy Lutomirski wrote: > On Sun, Apr 9, 2017 at 1:24 PM, PaX Team wrote: > > > I consider breaking buggy drivers (in a way that they either generally > work okay do they work okay when the dma transfer goes to a buffer that crosses physically non-contiguous page

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Mon, Apr 10, 2017 at 3:42 AM, PaX Team wrote: > On 9 Apr 2017 at 17:10, Andy Lutomirski wrote: > >> On Sun, Apr 9, 2017 at 5:47 AM, PaX Team wrote: >> > on x86 the cost of the pax_open/close_kernel primitives comes from the cr0 >> > writes and

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Mon, Apr 10, 2017 at 3:42 AM, PaX Team wrote: > On 9 Apr 2017 at 17:10, Andy Lutomirski wrote: > >> On Sun, Apr 9, 2017 at 5:47 AM, PaX Team wrote: >> > on x86 the cost of the pax_open/close_kernel primitives comes from the cr0 >> > writes and nothing else, use_mm suffers not only from the

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On 9 Apr 2017 at 17:10, Andy Lutomirski wrote: > On Sun, Apr 9, 2017 at 5:47 AM, PaX Team wrote: > > on x86 the cost of the pax_open/close_kernel primitives comes from the cr0 > > writes and nothing else, use_mm suffers not only from the cr3 writes but > > also

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On 9 Apr 2017 at 17:10, Andy Lutomirski wrote: > On Sun, Apr 9, 2017 at 5:47 AM, PaX Team wrote: > > on x86 the cost of the pax_open/close_kernel primitives comes from the cr0 > > writes and nothing else, use_mm suffers not only from the cr3 writes but > > also locking/atomic ops and cr4 writes

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Fri, Apr 07, 2017 at 04:45:26PM +0200, Peter Zijlstra wrote: > On Fri, Apr 07, 2017 at 12:51:15PM +0200, Mathias Krause wrote: > > Why that? It allows fast and CPU local modifications of r/o memory. > > OTOH, an approach that needs to fiddle with page table entries > > requires global

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Fri, Apr 07, 2017 at 04:45:26PM +0200, Peter Zijlstra wrote: > On Fri, Apr 07, 2017 at 12:51:15PM +0200, Mathias Krause wrote: > > Why that? It allows fast and CPU local modifications of r/o memory. > > OTOH, an approach that needs to fiddle with page table entries > > requires global

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Sat, Apr 08, 2017 at 08:20:03AM -0700, Andy Lutomirski wrote: > On Sat, Apr 8, 2017 at 12:33 AM, Daniel Micay wrote: > > The > > submitted code is aimed at rare writes to globals, but this feature is > > more than that and design decisions shouldn't be based on just the

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Sat, Apr 08, 2017 at 08:20:03AM -0700, Andy Lutomirski wrote: > On Sat, Apr 8, 2017 at 12:33 AM, Daniel Micay wrote: > > The > > submitted code is aimed at rare writes to globals, but this feature is > > more than that and design decisions shouldn't be based on just the > > short term. > >

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Fri, 7 Apr 2017, PaX Team wrote: > On 7 Apr 2017 at 11:46, Thomas Gleixner wrote: > > > On Fri, 7 Apr 2017, Mathias Krause wrote: > > > Well, doesn't look good to me. NMIs will still be able to interrupt > > > this code and will run with CR0.WP = 0. > > > > > > Shouldn't you instead question

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Fri, 7 Apr 2017, PaX Team wrote: > On 7 Apr 2017 at 11:46, Thomas Gleixner wrote: > > > On Fri, 7 Apr 2017, Mathias Krause wrote: > > > Well, doesn't look good to me. NMIs will still be able to interrupt > > > this code and will run with CR0.WP = 0. > > > > > > Shouldn't you instead question

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Sun, Apr 9, 2017 at 1:24 PM, PaX Team wrote: > >> In the context of virtually mapped stacks / KSTACKOVERFLOW, this >> naturally leads to different solutions. The upstream kernel had a >> bunch of buggy drivers that played badly with virtually mapped stacks. >> grsecurity

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Sun, Apr 9, 2017 at 1:24 PM, PaX Team wrote: > >> In the context of virtually mapped stacks / KSTACKOVERFLOW, this >> naturally leads to different solutions. The upstream kernel had a >> bunch of buggy drivers that played badly with virtually mapped stacks. >> grsecurity sensibly went for the

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Sun, Apr 9, 2017 at 5:47 AM, PaX Team wrote: > On 7 Apr 2017 at 21:58, Andy Lutomirski wrote: > >> On Fri, Apr 7, 2017 at 12:58 PM, PaX Team wrote: >> > On 7 Apr 2017 at 9:14, Andy Lutomirski wrote: >> >> Then someone who cares about performance can

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Sun, Apr 9, 2017 at 5:47 AM, PaX Team wrote: > On 7 Apr 2017 at 21:58, Andy Lutomirski wrote: > >> On Fri, Apr 7, 2017 at 12:58 PM, PaX Team wrote: >> > On 7 Apr 2017 at 9:14, Andy Lutomirski wrote: >> >> Then someone who cares about performance can benchmark the CR0.WP >> >> approach against

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On 7 Apr 2017 at 22:07, Andy Lutomirski wrote: > grsecurity and PaX are great projects. They have a lot of good ideas, > and they're put together quite nicely. The upstream kernel should > *not* do things differently from they way they are in grsecurity/PaX > just because it wants to be

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On 7 Apr 2017 at 22:07, Andy Lutomirski wrote: > grsecurity and PaX are great projects. They have a lot of good ideas, > and they're put together quite nicely. The upstream kernel should > *not* do things differently from they way they are in grsecurity/PaX > just because it wants to be

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On 7 Apr 2017 at 21:58, Andy Lutomirski wrote: > On Fri, Apr 7, 2017 at 12:58 PM, PaX Team wrote: > > On 7 Apr 2017 at 9:14, Andy Lutomirski wrote: > >> Then someone who cares about performance can benchmark the CR0.WP > >> approach against it and try to argue that it's a

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On 7 Apr 2017 at 21:58, Andy Lutomirski wrote: > On Fri, Apr 7, 2017 at 12:58 PM, PaX Team wrote: > > On 7 Apr 2017 at 9:14, Andy Lutomirski wrote: > >> Then someone who cares about performance can benchmark the CR0.WP > >> approach against it and try to argue that it's a good idea. This > >>

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

* Andy Lutomirski wrote: > On Sat, Apr 8, 2017 at 12:33 AM, Daniel Micay wrote: > > The > > submitted code is aimed at rare writes to globals, but this feature is > > more than that and design decisions shouldn't be based on just the > > short term. > >

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

* Andy Lutomirski wrote: > On Sat, Apr 8, 2017 at 12:33 AM, Daniel Micay wrote: > > The > > submitted code is aimed at rare writes to globals, but this feature is > > more than that and design decisions shouldn't be based on just the > > short term. > > Then, if you disagree with a proposed

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Sat, Apr 8, 2017 at 12:33 AM, Daniel Micay wrote: > The > submitted code is aimed at rare writes to globals, but this feature is > more than that and design decisions shouldn't be based on just the > short term. Then, if you disagree with a proposed design, *explain

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Sat, Apr 8, 2017 at 12:33 AM, Daniel Micay wrote: > The > submitted code is aimed at rare writes to globals, but this feature is > more than that and design decisions shouldn't be based on just the > short term. Then, if you disagree with a proposed design, *explain why* in a standalone

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

> grsecurity and PaX are great projects. They have a lot of good ideas, > and they're put together quite nicely. The upstream kernel should > *not* do things differently from they way they are in grsecurity/PaX > just because it wants to be different. Conversely, the upstream > kernel should

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

> grsecurity and PaX are great projects. They have a lot of good ideas, > and they're put together quite nicely. The upstream kernel should > *not* do things differently from they way they are in grsecurity/PaX > just because it wants to be different. Conversely, the upstream > kernel should

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Fri, Apr 7, 2017 at 9:21 PM, Daniel Micay wrote: >>> Fair enough. However, placing a BUG_ON(!(read_cr0() & X86_CR0_WP)) >>> somewhere sensible should make those "leaks" visible fast -- and their >>> exploitation impossible, i.e. fail hard. >> >> The leaks surely exist

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Fri, Apr 7, 2017 at 9:21 PM, Daniel Micay wrote: >>> Fair enough. However, placing a BUG_ON(!(read_cr0() & X86_CR0_WP)) >>> somewhere sensible should make those "leaks" visible fast -- and their >>> exploitation impossible, i.e. fail hard. >> >> The leaks surely exist and now we'll just add an

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Fri, Apr 7, 2017 at 12:58 PM, PaX Team wrote: > On 7 Apr 2017 at 9:14, Andy Lutomirski wrote: > >> On Fri, Apr 7, 2017 at 6:30 AM, Mathias Krause >> wrote: >> > On 7 April 2017 at 15:14, Thomas Gleixner wrote: >> >> On Fri, 7

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Fri, Apr 7, 2017 at 12:58 PM, PaX Team wrote: > On 7 Apr 2017 at 9:14, Andy Lutomirski wrote: > >> On Fri, Apr 7, 2017 at 6:30 AM, Mathias Krause >> wrote: >> > On 7 April 2017 at 15:14, Thomas Gleixner wrote: >> >> On Fri, 7 Apr 2017, Mathias Krause wrote: >> > Fair enough. However,

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

>> Fair enough. However, placing a BUG_ON(!(read_cr0() & X86_CR0_WP)) >> somewhere sensible should make those "leaks" visible fast -- and their >> exploitation impossible, i.e. fail hard. > > The leaks surely exist and now we'll just add an exploitable BUG. That didn't seem to matter for landing

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

>> Fair enough. However, placing a BUG_ON(!(read_cr0() & X86_CR0_WP)) >> somewhere sensible should make those "leaks" visible fast -- and their >> exploitation impossible, i.e. fail hard. > > The leaks surely exist and now we'll just add an exploitable BUG. That didn't seem to matter for landing

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

> Not too late to rename it. Scoped write? I think it makes change to s/change/sense/

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

> Not too late to rename it. Scoped write? I think it makes change to s/change/sense/

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

> I probably chose the wrong name for this feature (write rarely). > That's _usually_ true, but "sensitive_write()" was getting rather > long. The things that we need to protect with this are certainly stuff > that doesn't get much writing, but some things are just plain > sensitive (like page

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

> I probably chose the wrong name for this feature (write rarely). > That's _usually_ true, but "sensitive_write()" was getting rather > long. The things that we need to protect with this are certainly stuff > that doesn't get much writing, but some things are just plain > sensitive (like page

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Fri, Apr 7, 2017 at 1:44 PM, Thomas Gleixner wrote: > On Fri, 7 Apr 2017, Andy Lutomirski wrote: >> On Fri, Apr 7, 2017 at 6:30 AM, Mathias Krause >> wrote: >> > On 7 April 2017 at 15:14, Thomas Gleixner wrote: >> >> I really

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Fri, Apr 7, 2017 at 1:44 PM, Thomas Gleixner wrote: > On Fri, 7 Apr 2017, Andy Lutomirski wrote: >> On Fri, Apr 7, 2017 at 6:30 AM, Mathias Krause >> wrote: >> > On 7 April 2017 at 15:14, Thomas Gleixner wrote: >> >> I really do not care whether PaX wants to chase and verify that over and

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Fri, 7 Apr 2017, Andy Lutomirski wrote: > On Fri, Apr 7, 2017 at 6:30 AM, Mathias Krause wrote: > > On 7 April 2017 at 15:14, Thomas Gleixner wrote: > >> I really do not care whether PaX wants to chase and verify that over and > >> over. I certainly

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Fri, 7 Apr 2017, Andy Lutomirski wrote: > On Fri, Apr 7, 2017 at 6:30 AM, Mathias Krause wrote: > > On 7 April 2017 at 15:14, Thomas Gleixner wrote: > >> I really do not care whether PaX wants to chase and verify that over and > >> over. I certainly don't want to take the chance to leak

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On 7 Apr 2017 at 11:46, Thomas Gleixner wrote: > On Fri, 7 Apr 2017, Mathias Krause wrote: > > Well, doesn't look good to me. NMIs will still be able to interrupt > > this code and will run with CR0.WP = 0. > > > > Shouldn't you instead question yourself why PaX can do it "just" with > >

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On 7 Apr 2017 at 11:46, Thomas Gleixner wrote: > On Fri, 7 Apr 2017, Mathias Krause wrote: > > Well, doesn't look good to me. NMIs will still be able to interrupt > > this code and will run with CR0.WP = 0. > > > > Shouldn't you instead question yourself why PaX can do it "just" with > >

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On 7 Apr 2017 at 9:14, Andy Lutomirski wrote: > On Fri, Apr 7, 2017 at 6:30 AM, Mathias Krause wrote: > > On 7 April 2017 at 15:14, Thomas Gleixner wrote: > >> On Fri, 7 Apr 2017, Mathias Krause wrote: > > Fair enough. However, placing a

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On 7 Apr 2017 at 9:14, Andy Lutomirski wrote: > On Fri, Apr 7, 2017 at 6:30 AM, Mathias Krause wrote: > > On 7 April 2017 at 15:14, Thomas Gleixner wrote: > >> On Fri, 7 Apr 2017, Mathias Krause wrote: > > Fair enough. However, placing a BUG_ON(!(read_cr0() & X86_CR0_WP)) > > somewhere sensible

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Fri, 7 Apr 2017, Mathias Krause wrote: > On 7 April 2017 at 15:14, Thomas Gleixner wrote: > > On Fri, 7 Apr 2017, Mathias Krause wrote: > >> On 7 April 2017 at 11:46, Thomas Gleixner wrote: > >> > Whether protected by preempt_disable or

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Fri, 7 Apr 2017, Mathias Krause wrote: > On 7 April 2017 at 15:14, Thomas Gleixner wrote: > > On Fri, 7 Apr 2017, Mathias Krause wrote: > >> On 7 April 2017 at 11:46, Thomas Gleixner wrote: > >> > Whether protected by preempt_disable or local_irq_disable, to make that > >> > work it needs CR0

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Fri, Apr 07, 2017 at 09:14:29AM -0700, Andy Lutomirski wrote: > I think we're approaching this all wrong, actually. The fact that x86 > has this CR0.WP thing is arguably a historical accident, and the fact > that PaX uses it doesn't mean that PaX is doing it the best way for > upstream Linux.

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Fri, Apr 07, 2017 at 09:14:29AM -0700, Andy Lutomirski wrote: > I think we're approaching this all wrong, actually. The fact that x86 > has this CR0.WP thing is arguably a historical accident, and the fact > that PaX uses it doesn't mean that PaX is doing it the best way for > upstream Linux.

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Fri, Apr 7, 2017 at 6:30 AM, Mathias Krause wrote: > On 7 April 2017 at 15:14, Thomas Gleixner wrote: >> On Fri, 7 Apr 2017, Mathias Krause wrote: >>> On 7 April 2017 at 11:46, Thomas Gleixner wrote: >>> > Whether protected by

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Fri, Apr 7, 2017 at 6:30 AM, Mathias Krause wrote: > On 7 April 2017 at 15:14, Thomas Gleixner wrote: >> On Fri, 7 Apr 2017, Mathias Krause wrote: >>> On 7 April 2017 at 11:46, Thomas Gleixner wrote: >>> > Whether protected by preempt_disable or local_irq_disable, to make that >>> > work it

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Fri, Apr 07, 2017 at 12:51:15PM +0200, Mathias Krause wrote: > Why that? It allows fast and CPU local modifications of r/o memory. > OTOH, an approach that needs to fiddle with page table entries > requires global synchronization to keep the individual TLB states in > sync. Hmm.. Not that fast,

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Fri, Apr 07, 2017 at 12:51:15PM +0200, Mathias Krause wrote: > Why that? It allows fast and CPU local modifications of r/o memory. > OTOH, an approach that needs to fiddle with page table entries > requires global synchronization to keep the individual TLB states in > sync. Hmm.. Not that fast,

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On 7 April 2017 at 15:14, Thomas Gleixner wrote: > On Fri, 7 Apr 2017, Mathias Krause wrote: >> On 7 April 2017 at 11:46, Thomas Gleixner wrote: >> > Whether protected by preempt_disable or local_irq_disable, to make that >> > work it needs CR0 handling in

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On 7 April 2017 at 15:14, Thomas Gleixner wrote: > On Fri, 7 Apr 2017, Mathias Krause wrote: >> On 7 April 2017 at 11:46, Thomas Gleixner wrote: >> > Whether protected by preempt_disable or local_irq_disable, to make that >> > work it needs CR0 handling in the exception entry/exit at the lowest

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Fri, 7 Apr 2017, Mathias Krause wrote: > On 7 April 2017 at 11:46, Thomas Gleixner wrote: > > Whether protected by preempt_disable or local_irq_disable, to make that > > work it needs CR0 handling in the exception entry/exit at the lowest > > level. And that's just a

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Fri, 7 Apr 2017, Mathias Krause wrote: > On 7 April 2017 at 11:46, Thomas Gleixner wrote: > > Whether protected by preempt_disable or local_irq_disable, to make that > > work it needs CR0 handling in the exception entry/exit at the lowest > > level. And that's just a nightmare maintainence

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On 7 April 2017 at 11:46, Thomas Gleixner wrote: > On Fri, 7 Apr 2017, Mathias Krause wrote: >> On 6 April 2017 at 17:59, Andy Lutomirski wrote: >> > On Wed, Apr 5, 2017 at 5:14 PM, Kees Cook wrote: >> >> static __always_inline

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On 7 April 2017 at 11:46, Thomas Gleixner wrote: > On Fri, 7 Apr 2017, Mathias Krause wrote: >> On 6 April 2017 at 17:59, Andy Lutomirski wrote: >> > On Wed, Apr 5, 2017 at 5:14 PM, Kees Cook wrote: >> >> static __always_inline rare_write_begin(void) >> >> { >> >> preempt_disable(); >> >>

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Fri, 7 Apr 2017, Mathias Krause wrote: > On 6 April 2017 at 17:59, Andy Lutomirski wrote: > > On Wed, Apr 5, 2017 at 5:14 PM, Kees Cook wrote: > >> static __always_inline rare_write_begin(void) > >> { > >> preempt_disable(); > >>

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Fri, 7 Apr 2017, Mathias Krause wrote: > On 6 April 2017 at 17:59, Andy Lutomirski wrote: > > On Wed, Apr 5, 2017 at 5:14 PM, Kees Cook wrote: > >> static __always_inline rare_write_begin(void) > >> { > >> preempt_disable(); > >> local_irq_disable(); > >> barrier(); > >>

Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Wed, Mar 29, 2017 at 11:15:56AM -0700, Kees Cook wrote: > +static __always_inline unsigned long __arch_rare_write_end(void) > +{ > + unsigned long cr0; > + > + barrier(); > + cr0 = read_cr0() ^ X86_CR0_WP; > + BUG_ON(!(cr0 & X86_CR0_WP)); > + write_cr0(cr0); > +

Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Wed, Mar 29, 2017 at 11:15:56AM -0700, Kees Cook wrote: > +static __always_inline unsigned long __arch_rare_write_end(void) > +{ > + unsigned long cr0; > + > + barrier(); > + cr0 = read_cr0() ^ X86_CR0_WP; > + BUG_ON(!(cr0 & X86_CR0_WP)); > + write_cr0(cr0); > +

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On 6 April 2017 at 17:59, Andy Lutomirski wrote: > On Wed, Apr 5, 2017 at 5:14 PM, Kees Cook wrote: >> On Wed, Apr 5, 2017 at 4:57 PM, Andy Lutomirski wrote: >>> On Wed, Mar 29, 2017 at 6:41 PM, Kees Cook

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On 6 April 2017 at 17:59, Andy Lutomirski wrote: > On Wed, Apr 5, 2017 at 5:14 PM, Kees Cook wrote: >> On Wed, Apr 5, 2017 at 4:57 PM, Andy Lutomirski wrote: >>> On Wed, Mar 29, 2017 at 6:41 PM, Kees Cook wrote: On Wed, Mar 29, 2017 at 3:38 PM, Andy Lutomirski wrote: > On Wed,

Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Wed, Apr 5, 2017 at 5:14 PM, Kees Cook wrote: > On Wed, Apr 5, 2017 at 4:57 PM, Andy Lutomirski wrote: >> On Wed, Mar 29, 2017 at 6:41 PM, Kees Cook wrote: >>> On Wed, Mar 29, 2017 at 3:38 PM, Andy Lutomirski

Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Wed, Apr 5, 2017 at 5:14 PM, Kees Cook wrote: > On Wed, Apr 5, 2017 at 4:57 PM, Andy Lutomirski wrote: >> On Wed, Mar 29, 2017 at 6:41 PM, Kees Cook wrote: >>> On Wed, Mar 29, 2017 at 3:38 PM, Andy Lutomirski >>> wrote: On Wed, Mar 29, 2017 at 11:15 AM, Kees Cook wrote: > Based

Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Wed, Apr 5, 2017 at 4:57 PM, Andy Lutomirski wrote: > On Wed, Mar 29, 2017 at 6:41 PM, Kees Cook wrote: >> On Wed, Mar 29, 2017 at 3:38 PM, Andy Lutomirski wrote: >>> On Wed, Mar 29, 2017 at 11:15 AM, Kees Cook

Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Wed, Apr 5, 2017 at 4:57 PM, Andy Lutomirski wrote: > On Wed, Mar 29, 2017 at 6:41 PM, Kees Cook wrote: >> On Wed, Mar 29, 2017 at 3:38 PM, Andy Lutomirski wrote: >>> On Wed, Mar 29, 2017 at 11:15 AM, Kees Cook wrote: Based on PaX's x86 pax_{open,close}_kernel() implementation, this

Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Wed, Mar 29, 2017 at 6:41 PM, Kees Cook wrote: > On Wed, Mar 29, 2017 at 3:38 PM, Andy Lutomirski wrote: >> On Wed, Mar 29, 2017 at 11:15 AM, Kees Cook wrote: >>> Based on PaX's x86 pax_{open,close}_kernel() implementation,

Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Wed, Mar 29, 2017 at 6:41 PM, Kees Cook wrote: > On Wed, Mar 29, 2017 at 3:38 PM, Andy Lutomirski wrote: >> On Wed, Mar 29, 2017 at 11:15 AM, Kees Cook wrote: >>> Based on PaX's x86 pax_{open,close}_kernel() implementation, this >>> allows HAVE_ARCH_RARE_WRITE to work on x86. >>> >> >>> +

Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Wed, Mar 29, 2017 at 3:38 PM, Andy Lutomirski wrote: > On Wed, Mar 29, 2017 at 11:15 AM, Kees Cook wrote: >> Based on PaX's x86 pax_{open,close}_kernel() implementation, this >> allows HAVE_ARCH_RARE_WRITE to work on x86. >> > >> + >> +static

Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Wed, Mar 29, 2017 at 3:38 PM, Andy Lutomirski wrote: > On Wed, Mar 29, 2017 at 11:15 AM, Kees Cook wrote: >> Based on PaX's x86 pax_{open,close}_kernel() implementation, this >> allows HAVE_ARCH_RARE_WRITE to work on x86. >> > >> + >> +static __always_inline unsigned long

Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Wed, Mar 29, 2017 at 11:15 AM, Kees Cook wrote: > Based on PaX's x86 pax_{open,close}_kernel() implementation, this > allows HAVE_ARCH_RARE_WRITE to work on x86. > > + > +static __always_inline unsigned long __arch_rare_write_begin(void) > +{ > + unsigned long

Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Wed, Mar 29, 2017 at 11:15 AM, Kees Cook wrote: > Based on PaX's x86 pax_{open,close}_kernel() implementation, this > allows HAVE_ARCH_RARE_WRITE to work on x86. > > + > +static __always_inline unsigned long __arch_rare_write_begin(void) > +{ > + unsigned long cr0; > + > +

[RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

Based on PaX's x86 pax_{open,close}_kernel() implementation, this allows HAVE_ARCH_RARE_WRITE to work on x86. There is missing work to sort out some header file issues where preempt.h is missing, though it can't be included in pg_table.h unconditionally... some other solution will be needed,

[RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

Based on PaX's x86 pax_{open,close}_kernel() implementation, this allows HAVE_ARCH_RARE_WRITE to work on x86. There is missing work to sort out some header file issues where preempt.h is missing, though it can't be included in pg_table.h unconditionally... some other solution will be needed,