netdev - Re: [PATCH 2/2] x86/cfi,bpf: Fix BPF JIT call

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20231120155936.GY8262@noisy.programming.kicks-ass.net>
Date: Mon, 20 Nov 2023 16:59:36 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: paul.walmsley@...ive.com, palmer@...belt.com, aou@...s.berkeley.edu,
	tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
	dave.hansen@...ux.intel.com, x86@...nel.org, hpa@...or.com,
	davem@...emloft.net, dsahern@...nel.org, ast@...nel.org,
	daniel@...earbox.net, andrii@...nel.org, martin.lau@...ux.dev,
	song@...nel.org, yonghong.song@...ux.dev, john.fastabend@...il.com,
	kpsingh@...nel.org, sdf@...gle.com, haoluo@...gle.com,
	jolsa@...nel.org, Arnd Bergmann <arnd@...db.de>,
	samitolvanen@...gle.com, keescook@...omium.org, nathan@...nel.org,
	ndesaulniers@...gle.com, linux-riscv@...ts.infradead.org,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	bpf@...r.kernel.org, linux-arch@...r.kernel.org,
	llvm@...ts.linux.dev, jpoimboe@...nel.org, joao@...rdrivepizza.com,
	mark.rutland@....com
Subject: Re: [PATCH 2/2] x86/cfi,bpf: Fix BPF JIT call

On Mon, Nov 20, 2023 at 03:46:44PM +0100, Peter Zijlstra wrote:

> @@ -2935,9 +3009,9 @@ struct bpf_prog *bpf_int_jit_compile(str
>  			jit_data->header = header;
>  			jit_data->rw_header = rw_header;
>  		}
> -		prog->bpf_func = (void *)image;
> +		prog->bpf_func = (void *)image + ctx.prog_offset;
>  		prog->jited = 1;
> -		prog->jited_len = proglen;
> +		prog->jited_len = proglen - ctx.prog_offset; // XXX?
>  	} else {
>  		prog = orig_prog;
>  	}


Note the XXX there, I wasn't sure what the desired semantics of proglen
was. As implemented it is the length from where bpf_func points to the
end, not including the pre-preamble -- as indicated by offset.