All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Yang Jihong <yangjihong1@huawei.com>
Cc: ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
	martin.lau@linux.dev, song@kernel.org, yhs@fb.com,
	john.fastabend@gmail.com, kpsingh@kernel.org, sdf@google.com,
	haoluo@google.com, jolsa@kernel.org, illusionist.neo@gmail.com,
	davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
	pabeni@redhat.com, mykolal@fb.com, shuah@kernel.org,
	benjamin.tissoires@redhat.com, memxor@gmail.com, delyank@fb.com,
	asavkov@redhat.com, bpf@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
	linux-kselftest@vger.kernel.org
Subject: Re: [PATCH bpf RESEND 2/4] bpf: Remove size check for sk in bpf_skb_is_valid_access for 32-bit architecture
Date: Thu, 3 Nov 2022 11:23:08 +0000	[thread overview]
Message-ID: <Y2OknBtLgqTHSrvy@shell.armlinux.org.uk> (raw)
In-Reply-To: <20221103092118.248600-3-yangjihong1@huawei.com>

On Thu, Nov 03, 2022 at 05:21:16PM +0800, Yang Jihong wrote:
> The error code -EACCES is returned when bpf prog is tested in 32-bit environment,
> This is because bpf_object__relocate modifies the instruction to change memory
> size to 4 bytes, as shown in the following messages:
> 
> libbpf: prog 'kfunc_call_test1': relo #2: matching candidate #0 <byte_off> [18342] struct __sk_buff.sk (0:30:0 @ offset 168)
> libbpf: prog 'kfunc_call_test1': relo #2: patched insn #1 (LDX/ST/STX) off 168 -> 168
> libbpf: prog 'kfunc_call_test1': relo #2: patched insn #1 (LDX/ST/STX) mem_sz 8 -> 4
> 
> As a result, the bpf_skb_is_valid_access check fails. For 32-bit architecture,
> unnecessary checks need to be deleted.

Isn't the purpose of this check to ensure that the entire pointer is
written, and BPF can't write half of it?


>  	case offsetof(struct __sk_buff, sk):
> -		if (type == BPF_WRITE || size != sizeof(__u64))
> -			return false;

Wouldn't "(size != sizeof(struct bpf_sock *) && size != sizeof(__u64))"
be more appropriate here, so 32-bit can only write the 32-bit pointer
or the full 64-bit value, and 64-bit can only write the 64-bit pointer?
Or is there a reason not to? bpf folk?

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

WARNING: multiple messages have this Message-ID (diff)
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Yang Jihong <yangjihong1@huawei.com>
Cc: ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
	martin.lau@linux.dev, song@kernel.org, yhs@fb.com,
	john.fastabend@gmail.com, kpsingh@kernel.org, sdf@google.com,
	haoluo@google.com, jolsa@kernel.org, illusionist.neo@gmail.com,
	davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
	pabeni@redhat.com, mykolal@fb.com, shuah@kernel.org,
	benjamin.tissoires@redhat.com, memxor@gmail.com, delyank@fb.com,
	asavkov@redhat.com, bpf@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
	linux-kselftest@vger.kernel.org
Subject: Re: [PATCH bpf RESEND 2/4] bpf: Remove size check for sk in bpf_skb_is_valid_access for 32-bit architecture
Date: Thu, 3 Nov 2022 11:23:08 +0000	[thread overview]
Message-ID: <Y2OknBtLgqTHSrvy@shell.armlinux.org.uk> (raw)
In-Reply-To: <20221103092118.248600-3-yangjihong1@huawei.com>

On Thu, Nov 03, 2022 at 05:21:16PM +0800, Yang Jihong wrote:
> The error code -EACCES is returned when bpf prog is tested in 32-bit environment,
> This is because bpf_object__relocate modifies the instruction to change memory
> size to 4 bytes, as shown in the following messages:
> 
> libbpf: prog 'kfunc_call_test1': relo #2: matching candidate #0 <byte_off> [18342] struct __sk_buff.sk (0:30:0 @ offset 168)
> libbpf: prog 'kfunc_call_test1': relo #2: patched insn #1 (LDX/ST/STX) off 168 -> 168
> libbpf: prog 'kfunc_call_test1': relo #2: patched insn #1 (LDX/ST/STX) mem_sz 8 -> 4
> 
> As a result, the bpf_skb_is_valid_access check fails. For 32-bit architecture,
> unnecessary checks need to be deleted.

Isn't the purpose of this check to ensure that the entire pointer is
written, and BPF can't write half of it?


>  	case offsetof(struct __sk_buff, sk):
> -		if (type == BPF_WRITE || size != sizeof(__u64))
> -			return false;

Wouldn't "(size != sizeof(struct bpf_sock *) && size != sizeof(__u64))"
be more appropriate here, so 32-bit can only write the 32-bit pointer
or the full 64-bit value, and 64-bit can only write the 64-bit pointer?
Or is there a reason not to? bpf folk?

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-11-03 11:23 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-03  9:21 [PATCH bpf RESEND 0/4] bpf: Support kernel function call in 32-bit ARM Yang Jihong
2022-11-03  9:21 ` Yang Jihong
2022-11-03  9:21 ` [PATCH bpf RESEND 1/4] bpf: Adapt 32-bit return value kfunc for 32-bit ARM when zext extension Yang Jihong
2022-11-03  9:21   ` Yang Jihong
2022-11-03  9:21 ` [PATCH bpf RESEND 2/4] bpf: Remove size check for sk in bpf_skb_is_valid_access for 32-bit architecture Yang Jihong
2022-11-03  9:21   ` Yang Jihong
2022-11-03 11:23   ` Russell King (Oracle) [this message]
2022-11-03 11:23     ` Russell King (Oracle)
2022-11-03 18:15     ` Alexei Starovoitov
2022-11-03 18:15       ` Alexei Starovoitov
2022-11-04 22:43       ` Andrii Nakryiko
2022-11-04 22:43         ` Andrii Nakryiko
2022-11-04 23:37         ` Alexei Starovoitov
2022-11-04 23:37           ` Alexei Starovoitov
2022-11-07  9:22           ` Yang Jihong
2022-11-07  9:22             ` Yang Jihong
2022-11-07  9:12     ` Yang Jihong
2022-11-07  9:12       ` Yang Jihong
2022-11-03  9:21 ` [PATCH bpf RESEND 3/4] bpf: Add kernel function call support in 32-bit ARM Yang Jihong
2022-11-03  9:21   ` Yang Jihong
2022-11-03 11:35   ` Russell King (Oracle)
2022-11-03 11:35     ` Russell King (Oracle)
2022-11-07  9:10     ` Yang Jihong
2022-11-07  9:10       ` Yang Jihong
2022-11-03  9:21 ` [PATCH bpf RESEND 4/4] bpf:selftests: Add kfunc_call test for mixing 32-bit and 64-bit parameters Yang Jihong
2022-11-03  9:21   ` Yang Jihong

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=Y2OknBtLgqTHSrvy@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=andrii@kernel.org \
    --cc=asavkov@redhat.com \
    --cc=ast@kernel.org \
    --cc=benjamin.tissoires@redhat.com \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=delyank@fb.com \
    --cc=edumazet@google.com \
    --cc=haoluo@google.com \
    --cc=illusionist.neo@gmail.com \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kpsingh@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=memxor@gmail.com \
    --cc=mykolal@fb.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=sdf@google.com \
    --cc=shuah@kernel.org \
    --cc=song@kernel.org \
    --cc=yangjihong1@huawei.com \
    --cc=yhs@fb.com \
    /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.