Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754854Ab3ETJus (ORCPT ); Mon, 20 May 2013 05:50:48 -0400 Received: from mx1.redhat.com ([209.132.183.28]:8186 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752896Ab3ETJuq (ORCPT ); Mon, 20 May 2013 05:50:46 -0400 Message-ID: <5199F1E3.1020109@redhat.com> Date: Mon, 20 May 2013 11:50:27 +0200 From: Daniel Borkmann User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: David Laight CC: Eric Dumazet , David Miller , netdev , "H. Peter Anvin" , linux-kernel@vger.kernel.org Subject: Re: [PATCH net-next] x86: bpf_jit_comp: secure bpf jit against spraying attacks References: <1368844623.3301.142.camel@edumazet-glaptop> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1467 Lines: 37 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 >> the page) in two parts, so that the generated bpf code not starts at a >> known offset in the page, but a pseudo random one. > ... >> +static struct bpf_binary_header *bpf_alloc_binary(unsigned int proglen, >> + u8 **image_ptr) > ... >> + /* insert a random number of int3 instructions before BPF code */ >> + *image_ptr = &header->image[prandom_u32() % hole]; >> + return header; >> +} > > 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 .rodata might be better - especially > if you can find part of .rodata.str*. 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/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/