All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiong Wang <jiong.wang@netronome.com>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>,
	Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Jiong Wang <jiong.wang@netronome.com>,
	bpf@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: Regression fix for bpf in v5.3 (was Re: [RFC PATCH] bpf: handle 32-bit zext during constant blinding)
Date: Wed, 21 Aug 2019 11:55:54 +0100	[thread overview]
Message-ID: <87k1b6yeh1.fsf@netronome.com> (raw)
In-Reply-To: <87d0gy6cj6.fsf@concordia.ellerman.id.au>


Michael Ellerman writes:

> "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> writes:
>> Since BPF constant blinding is performed after the verifier pass, there
>> are certain ALU32 instructions inserted which don't have a corresponding
>> zext instruction inserted after. This is causing a kernel oops on
>> powerpc and can be reproduced by running 'test_cgroup_storage' with
>> bpf_jit_harden=2.
>>
>> Fix this by emitting BPF_ZEXT during constant blinding if
>> prog->aux->verifier_zext is set.
>>
>> Fixes: a4b1d3c1ddf6cb ("bpf: verifier: insert zero extension according to analysis result")
>> Reported-by: Michael Ellerman <mpe@ellerman.id.au>
>> Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
>> ---
>> This approach (the location where zext is being introduced below, in 
>> particular) works for powerpc, but I am not entirely sure if this is 
>> sufficient for other architectures as well. This is broken on v5.3-rc4.
>
> Any comment on this?

Have commented on https://marc.info/?l=linux-netdev&m=156637836024743&w=2

The fix looks correct to me on "BPF_LD | BPF_IMM | BPF_DW", but looks
unnecessary on two other places. It would be great if you or Naveen could
confirm it.

Thanks.

Regards,
Jiong

> This is a regression in v5.3, which results in a kernel crash, it would
> be nice to get it fixed before the release please?
>
> cheers
>
>> diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
>> index 8191a7db2777..d84146e6fd9e 100644
>> --- a/kernel/bpf/core.c
>> +++ b/kernel/bpf/core.c
>> @@ -890,7 +890,8 @@ int bpf_jit_get_func_addr(const struct bpf_prog *prog,
>>  
>>  static int bpf_jit_blind_insn(const struct bpf_insn *from,
>>  			      const struct bpf_insn *aux,
>> -			      struct bpf_insn *to_buff)
>> +			      struct bpf_insn *to_buff,
>> +			      bool emit_zext)
>>  {
>>  	struct bpf_insn *to = to_buff;
>>  	u32 imm_rnd = get_random_int();
>> @@ -939,6 +940,8 @@ static int bpf_jit_blind_insn(const struct bpf_insn *from,
>>  		*to++ = BPF_ALU32_IMM(BPF_MOV, BPF_REG_AX, imm_rnd ^ from->imm);
>>  		*to++ = BPF_ALU32_IMM(BPF_XOR, BPF_REG_AX, imm_rnd);
>>  		*to++ = BPF_ALU32_REG(from->code, from->dst_reg, BPF_REG_AX);
>> +		if (emit_zext)
>> +			*to++ = BPF_ZEXT_REG(from->dst_reg);
>>  		break;
>>  
>>  	case BPF_ALU64 | BPF_ADD | BPF_K:
>> @@ -992,6 +995,10 @@ static int bpf_jit_blind_insn(const struct bpf_insn *from,
>>  			off -= 2;
>>  		*to++ = BPF_ALU32_IMM(BPF_MOV, BPF_REG_AX, imm_rnd ^ from->imm);
>>  		*to++ = BPF_ALU32_IMM(BPF_XOR, BPF_REG_AX, imm_rnd);
>> +		if (emit_zext) {
>> +			*to++ = BPF_ZEXT_REG(BPF_REG_AX);
>> +			off--;
>> +		}
>>  		*to++ = BPF_JMP32_REG(from->code, from->dst_reg, BPF_REG_AX,
>>  				      off);
>>  		break;
>> @@ -1005,6 +1012,8 @@ static int bpf_jit_blind_insn(const struct bpf_insn *from,
>>  	case 0: /* Part 2 of BPF_LD | BPF_IMM | BPF_DW. */
>>  		*to++ = BPF_ALU32_IMM(BPF_MOV, BPF_REG_AX, imm_rnd ^ aux[0].imm);
>>  		*to++ = BPF_ALU32_IMM(BPF_XOR, BPF_REG_AX, imm_rnd);
>> +		if (emit_zext)
>> +			*to++ = BPF_ZEXT_REG(BPF_REG_AX);
>>  		*to++ = BPF_ALU64_REG(BPF_OR,  aux[0].dst_reg, BPF_REG_AX);
>>  		break;
>>  
>> @@ -1088,7 +1097,8 @@ struct bpf_prog *bpf_jit_blind_constants(struct bpf_prog *prog)
>>  		    insn[1].code == 0)
>>  			memcpy(aux, insn, sizeof(aux));
>>  
>> -		rewritten = bpf_jit_blind_insn(insn, aux, insn_buff);
>> +		rewritten = bpf_jit_blind_insn(insn, aux, insn_buff,
>> +						clone->aux->verifier_zext);
>>  		if (!rewritten)
>>  			continue;
>>  
>> -- 
>> 2.22.0


WARNING: multiple messages have this Message-ID (diff)
From: Jiong Wang <jiong.wang@netronome.com>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: Daniel Borkmann <daniel@iogearbox.net>,
	Jiong Wang <jiong.wang@netronome.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	"Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>,
	linuxppc-dev@lists.ozlabs.org, bpf@vger.kernel.org
Subject: Re: Regression fix for bpf in v5.3 (was Re: [RFC PATCH] bpf: handle 32-bit zext during constant blinding)
Date: Wed, 21 Aug 2019 11:55:54 +0100	[thread overview]
Message-ID: <87k1b6yeh1.fsf@netronome.com> (raw)
In-Reply-To: <87d0gy6cj6.fsf@concordia.ellerman.id.au>


Michael Ellerman writes:

> "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> writes:
>> Since BPF constant blinding is performed after the verifier pass, there
>> are certain ALU32 instructions inserted which don't have a corresponding
>> zext instruction inserted after. This is causing a kernel oops on
>> powerpc and can be reproduced by running 'test_cgroup_storage' with
>> bpf_jit_harden=2.
>>
>> Fix this by emitting BPF_ZEXT during constant blinding if
>> prog->aux->verifier_zext is set.
>>
>> Fixes: a4b1d3c1ddf6cb ("bpf: verifier: insert zero extension according to analysis result")
>> Reported-by: Michael Ellerman <mpe@ellerman.id.au>
>> Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
>> ---
>> This approach (the location where zext is being introduced below, in 
>> particular) works for powerpc, but I am not entirely sure if this is 
>> sufficient for other architectures as well. This is broken on v5.3-rc4.
>
> Any comment on this?

Have commented on https://marc.info/?l=linux-netdev&m=156637836024743&w=2

The fix looks correct to me on "BPF_LD | BPF_IMM | BPF_DW", but looks
unnecessary on two other places. It would be great if you or Naveen could
confirm it.

Thanks.

Regards,
Jiong

> This is a regression in v5.3, which results in a kernel crash, it would
> be nice to get it fixed before the release please?
>
> cheers
>
>> diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
>> index 8191a7db2777..d84146e6fd9e 100644
>> --- a/kernel/bpf/core.c
>> +++ b/kernel/bpf/core.c
>> @@ -890,7 +890,8 @@ int bpf_jit_get_func_addr(const struct bpf_prog *prog,
>>  
>>  static int bpf_jit_blind_insn(const struct bpf_insn *from,
>>  			      const struct bpf_insn *aux,
>> -			      struct bpf_insn *to_buff)
>> +			      struct bpf_insn *to_buff,
>> +			      bool emit_zext)
>>  {
>>  	struct bpf_insn *to = to_buff;
>>  	u32 imm_rnd = get_random_int();
>> @@ -939,6 +940,8 @@ static int bpf_jit_blind_insn(const struct bpf_insn *from,
>>  		*to++ = BPF_ALU32_IMM(BPF_MOV, BPF_REG_AX, imm_rnd ^ from->imm);
>>  		*to++ = BPF_ALU32_IMM(BPF_XOR, BPF_REG_AX, imm_rnd);
>>  		*to++ = BPF_ALU32_REG(from->code, from->dst_reg, BPF_REG_AX);
>> +		if (emit_zext)
>> +			*to++ = BPF_ZEXT_REG(from->dst_reg);
>>  		break;
>>  
>>  	case BPF_ALU64 | BPF_ADD | BPF_K:
>> @@ -992,6 +995,10 @@ static int bpf_jit_blind_insn(const struct bpf_insn *from,
>>  			off -= 2;
>>  		*to++ = BPF_ALU32_IMM(BPF_MOV, BPF_REG_AX, imm_rnd ^ from->imm);
>>  		*to++ = BPF_ALU32_IMM(BPF_XOR, BPF_REG_AX, imm_rnd);
>> +		if (emit_zext) {
>> +			*to++ = BPF_ZEXT_REG(BPF_REG_AX);
>> +			off--;
>> +		}
>>  		*to++ = BPF_JMP32_REG(from->code, from->dst_reg, BPF_REG_AX,
>>  				      off);
>>  		break;
>> @@ -1005,6 +1012,8 @@ static int bpf_jit_blind_insn(const struct bpf_insn *from,
>>  	case 0: /* Part 2 of BPF_LD | BPF_IMM | BPF_DW. */
>>  		*to++ = BPF_ALU32_IMM(BPF_MOV, BPF_REG_AX, imm_rnd ^ aux[0].imm);
>>  		*to++ = BPF_ALU32_IMM(BPF_XOR, BPF_REG_AX, imm_rnd);
>> +		if (emit_zext)
>> +			*to++ = BPF_ZEXT_REG(BPF_REG_AX);
>>  		*to++ = BPF_ALU64_REG(BPF_OR,  aux[0].dst_reg, BPF_REG_AX);
>>  		break;
>>  
>> @@ -1088,7 +1097,8 @@ struct bpf_prog *bpf_jit_blind_constants(struct bpf_prog *prog)
>>  		    insn[1].code == 0)
>>  			memcpy(aux, insn, sizeof(aux));
>>  
>> -		rewritten = bpf_jit_blind_insn(insn, aux, insn_buff);
>> +		rewritten = bpf_jit_blind_insn(insn, aux, insn_buff,
>> +						clone->aux->verifier_zext);
>>  		if (!rewritten)
>>  			continue;
>>  
>> -- 
>> 2.22.0


  reply	other threads:[~2019-08-21 10:56 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-13 17:10 [RFC PATCH] bpf: handle 32-bit zext during constant blinding Naveen N. Rao
2019-08-13 17:10 ` Naveen N. Rao
2019-08-21  8:30 ` Naveen N. Rao
2019-08-21  8:30   ` Naveen N. Rao
2019-08-21  9:05   ` Jiong Wang
2019-08-21  9:05     ` Jiong Wang
2019-08-21 10:25 ` Regression fix for bpf in v5.3 (was Re: [RFC PATCH] bpf: handle 32-bit zext during constant blinding) Michael Ellerman
2019-08-21 10:25   ` Michael Ellerman
2019-08-21 10:55   ` Jiong Wang [this message]
2019-08-21 10:55     ` Jiong Wang
2019-08-21 19:12     ` Naveen N. Rao
2019-08-21 19:12       ` Naveen N. Rao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87k1b6yeh1.fsf@netronome.com \
    --to=jiong.wang@netronome.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=naveen.n.rao@linux.vnet.ibm.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.