Hi Eric,
Peter talked to me about this BPF work to prevent JIT spraying attacks
in the beginning of this week and I took a look at your patch.
Some comments:
* Meta-comment about patch structure: why this was a one patch and not
two patches? It changes two things that are orthogonal to each o
> > What about emitting additional instructions at random locations in the
> > generated code itself?
> >
> > Eg., after every instruction, have random chance to insert
> > 'xor $0xcc,%al; xor $0xcc,%al', etc?
>
> This will be the latest thing I'll do.
>
> Frankly, whole point of BPF JIT is speed
On Mon, 2013-05-20 at 16:19 +0200, Florian Westphal wrote:
> What about emitting additional instructions at random locations in the
> generated code itself?
>
> Eg., after every instruction, have random chance to insert
> 'xor $0xcc,%al; xor $0xcc,%al', etc?
This will be the latest thing I'll do
Eric Dumazet wrote:
> From: Eric Dumazet
>
> hpa bringed into my attention some security related issues
> with BPF JIT on x86.
>
> This patch makes sure the bpf generated code is marked read only,
> as other kernel text sections.
>
> It also splits the unused space (we vmalloc() and only use a
On Mon, 2013-05-20 at 11:50 +0200, Daniel Borkmann wrote:
> Here seems also to be another approach ...
>
>http://grsecurity.net/~spender/jit_prot.diff
>
> via:
> http://www.reddit.com/r/netsec/comments/13dzhx/linux_kernel_jit_spray_for_smep_kernexec_bypass/
Well, there are many approaches
On Mon, 2013-05-20 at 09:51 +0100, David Laight wrote:
> Hmmm anyone looking to overwrite kernel code will then start
> looking for blocks of 0xcc bytes and know that what follows
> is the beginning of a function.
> That isn't any harder than random writes.
>
> Copying a random part of .rodat
On 05/20/2013 10:51 AM, David Laight wrote:
hpa bringed into my attention some security related issues
with BPF JIT on x86.
This patch makes sure the bpf generated code is marked read only,
as other kernel text sections.
It also splits the unused space (we vmalloc() and only use a fraction of
t
> hpa bringed into my attention some security related issues
> with BPF JIT on x86.
>
> This patch makes sure the bpf generated code is marked read only,
> as other kernel text sections.
>
> It also splits the unused space (we vmalloc() and only use a fraction of
> the page) in two parts, so that
From: Eric Dumazet
Date: Fri, 17 May 2013 19:37:03 -0700
> From: Eric Dumazet
>
> hpa bringed into my attention some security related issues
> with BPF JIT on x86.
>
> This patch makes sure the bpf generated code is marked read only,
> as other kernel text sections.
>
> It also splits the unu
From: Daniel Borkmann
Date: Sun, 19 May 2013 19:02:46 +0200
> Probably other archs could later on follow-up with setting to
> read-only, too.
Only s390 and x86 support this facility.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@
On 05/18/2013 04:37 AM, Eric Dumazet wrote:
From: Eric Dumazet
hpa bringed into my attention some security related issues
with BPF JIT on x86.
This patch makes sure the bpf generated code is marked read only,
as other kernel text sections.
It also splits the unused space (we vmalloc() and onl
From: Eric Dumazet
hpa bringed into my attention some security related issues
with BPF JIT on x86.
This patch makes sure the bpf generated code is marked read only,
as other kernel text sections.
It also splits the unused space (we vmalloc() and only use a fraction of
the page) in two parts, so
12 matches
Mail list logo
