From: David Laight <David.Laight@ACULAB.COM>
To: 'Alexei Starovoitov' <alexei.starovoitov@gmail.com>
Cc: Puranjay Mohan <puranjay12@gmail.com>,
Ilya Leoshkevich <iii@linux.ibm.com>,
"David S. Miller" <davem@davemloft.net>,
David Ahern <dsahern@kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Martin KaFai Lau <martin.lau@linux.dev>,
Eduard Zingerman <eddyz87@gmail.com>, Song Liu <song@kernel.org>,
Yonghong Song <yonghong.song@linux.dev>,
John Fastabend <john.fastabend@gmail.com>,
KP Singh <kpsingh@kernel.org>,
Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>,
Jiri Olsa <jolsa@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
X86 ML <x86@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
"Jean-Philippe Brucker" <jean-philippe@linaro.org>,
Network Development <netdev@vger.kernel.org>,
bpf <bpf@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH bpf] bpf: verifier: prevent userspace memory access
Date: Sun, 24 Mar 2024 22:29:47 +0000 [thread overview]
Message-ID: <c73258ae8425470f90ad31c424cebe3a@AcuMS.aculab.com> (raw)
In-Reply-To: <CAADnVQJzfnK0Mv6HVKZ38VDuAemzbmSMeYscf77YoEy0SgWw+A@mail.gmail.com>
From: Alexei Starovoitov
> Sent: 24 March 2024 20:43
>
> On Sun, Mar 24, 2024 at 1:05 PM David Laight <David.Laight@aculab.com> wrote:
> >
> > From: Alexei Starovoitov
> > > Sent: 21 March 2024 06:08
> > >
> > > On Wed, Mar 20, 2024 at 3:55 AM Puranjay Mohan <puranjay12@gmail.com> wrote:
> > > >
> > > > The JITs need to implement bpf_arch_uaddress_limit() to define where
> > > > the userspace addresses end for that architecture or TASK_SIZE is taken
> > > > as default.
> > > >
> > > > The implementation is as follows:
> > > >
> > > > REG_AX = SRC_REG
> > > > if(offset)
> > > > REG_AX += offset;
> > > > REG_AX >>= 32;
> > > > if (REG_AX <= (uaddress_limit >> 32))
> > > > DST_REG = 0;
> > > > else
> > > > DST_REG = *(size *)(SRC_REG + offset);
> > >
> > > The patch looks good, but it seems to be causing s390 CI failures.
> >
> > I'm confused by the need for this check (and, IIRC, some other bpf
> > code that does kernel copies that can fault - and return an error).
> >
> > I though that the entire point of bpf was that is sanitised and
> > verified everything to limit what the 'program' could do in order
> > to stop it overwriting (or even reading) kernel structures that
> > is wasn't supposed to access.
> >
> > So it just shouldn't have a address that might be (in any way)
> > invalid.
>
> bpf tracing progs can call bpf_probe_read_kernel() which
> can read any kernel memory.
> This is nothing but an inlined version of it.
It was the getsockopt() code were I saw the copy_nocheck() calls.
Those have to be broken.
Although the way some of the options use the ptr:len supplied by
the application you stand no chance of do an in-kernel call
without a proper buffer descriptor argument (with separate optlen
and bufferlen fields.)
>
> > The only possible address verify is access_ok() to ensure that
> > a uses address really is a user address.
>
> access_ok() considerations don't apply.
> We're not dealing with user memory access.
If you do need a check for 'not a user address' don't you want to just
require access_ok() fail?
That would be architecture independent.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
next prev parent reply other threads:[~2024-03-24 22:30 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-20 10:54 [PATCH bpf] bpf: verifier: prevent userspace memory access Puranjay Mohan
2024-03-21 6:08 ` Alexei Starovoitov
2024-03-21 8:45 ` Ilya Leoshkevich
2024-03-21 10:13 ` Puranjay Mohan
2024-03-24 20:04 ` David Laight
2024-03-24 20:43 ` Alexei Starovoitov
2024-03-24 22:29 ` David Laight [this message]
2024-03-24 23:48 ` Alexei Starovoitov
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=c73258ae8425470f90ad31c424cebe3a@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bp@alien8.de \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=dave.hansen@linux.intel.com \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=eddyz87@gmail.com \
--cc=haoluo@google.com \
--cc=hpa@zytor.com \
--cc=iii@linux.ibm.com \
--cc=jean-philippe@linaro.org \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=mingo@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=puranjay12@gmail.com \
--cc=sdf@google.com \
--cc=song@kernel.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=yonghong.song@linux.dev \
/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.