netdev - Re: [PATCH bpf-next] bpf: Emit explicit NULL pointer checks for PROBE

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <5E2A13A1-7F78-4830-871B-694892119EA3@fb.com>
Date:   Wed, 3 Feb 2021 18:37:06 +0000
From:   Song Liu <songliubraving@...com>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>
CC:     "David S . Miller" <davem@...emloft.net>,
        Daniel Borkmann <daniel@...earbox.net>,
        Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
        Kernel Team <Kernel-team@...com>
Subject: Re: [PATCH bpf-next] bpf: Emit explicit NULL pointer checks for
 PROBE_LDX instructions.



> On Feb 2, 2021, at 6:19 PM, Alexei Starovoitov <alexei.starovoitov@...il.com> wrote:
> 
> On Wed, Feb 03, 2021 at 12:56:39AM +0000, Song Liu wrote:
>> 
>> 
>>> On Feb 1, 2021, at 9:38 PM, Alexei Starovoitov <alexei.starovoitov@...il.com> wrote:
>>> 
>>> From: Alexei Starovoitov <ast@...nel.org>
>>> 
>>> PTR_TO_BTF_ID registers contain either kernel pointer or NULL.
>>> Emit the NULL check explicitly by JIT instead of going into
>>> do_user_addr_fault() on NULL deference.
>>> 
>>> Signed-off-by: Alexei Starovoitov <ast@...nel.org>
>>> ---
>>> arch/x86/net/bpf_jit_comp.c | 19 +++++++++++++++++++
>>> 1 file changed, 19 insertions(+)
>>> 
>>> diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
>>> index b7a2911bda77..a3dc3bd154ac 100644
>>> --- a/arch/x86/net/bpf_jit_comp.c
>>> +++ b/arch/x86/net/bpf_jit_comp.c
>>> @@ -930,6 +930,7 @@ static int do_jit(struct bpf_prog *bpf_prog, int *addrs, u8 *image,
>>> 		u32 dst_reg = insn->dst_reg;
>>> 		u32 src_reg = insn->src_reg;
>>> 		u8 b2 = 0, b3 = 0;
>>> +		u8 *start_of_ldx;
>>> 		s64 jmp_offset;
>>> 		u8 jmp_cond;
>>> 		u8 *func;
>>> @@ -1278,12 +1279,30 @@ st:			if (is_imm8(insn->off))
>>> 		case BPF_LDX | BPF_PROBE_MEM | BPF_W:
>>> 		case BPF_LDX | BPF_MEM | BPF_DW:
>>> 		case BPF_LDX | BPF_PROBE_MEM | BPF_DW:
>>> +			if (BPF_MODE(insn->code) == BPF_PROBE_MEM) {
>>> +				/* test src_reg, src_reg */
>>> +				maybe_emit_mod(&prog, src_reg, src_reg, true); /* always 1 byte */
>>> +				EMIT2(0x85, add_2reg(0xC0, src_reg, src_reg));
>>> +				/* jne start_of_ldx */
>>> +				EMIT2(X86_JNE, 0);
>>> +				/* xor dst_reg, dst_reg */
>>> +				emit_mov_imm32(&prog, false, dst_reg, 0);
>>> +				/* jmp byte_after_ldx */
>>> +				EMIT2(0xEB, 0);
>>> +
>>> +				/* populate jmp_offset for JNE above */
>>> +				temp[4] = prog - temp - 5 /* sizeof(test + jne) */;
>> 
>> IIUC, this case only happens for i == 1 in the loop? If so, can we use temp[5(?)] 
>> instead of start_of_ldx?
> 
> I don't understand the question, but let me try anyway :)
> temp is a buffer for single instruction.
> prog=temp; for every loop iteration (not only i == 1)

Thanks for the explanation. I misunderstood how we use prog in the loop. 

> temp[4] is second byte in JNE instruction as the comment says.
> temp[5] is a byte after JNE. It's a first byte of XOR.
> That XOR is variable length instruction. 
> Hence while emitting JNE we don't know the target offset in JNE and just use 0.
> So temp[4] assignment populates with actual offset, since now we know the size
> of XOR.

And after reading emit_ldx() more carefully, I agree that introducing 
start_of_ldx would simplify the logic here. 

Acked-by: Song Liu <songliubraving@...com>