All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: "Zidenberg, Tsahi" <tsahee@amazon.com>
Cc: stable@vger.kernel.org
Subject: Re: [PATCH 0/2] fix userspace access on arm64 for linux 5.4
Date: Tue, 13 Apr 2021 09:27:22 +0200	[thread overview]
Message-ID: <YHVH2uNBTVDsJ66m@kroah.com> (raw)
In-Reply-To: <e99e851a-07c3-ab83-0d10-fa2bb87a516d@amazon.com>

On Mon, Apr 12, 2021 at 10:46:41PM +0300, Zidenberg, Tsahi wrote:
> 
> 
> On 10/04/2021 14:30, Greg KH wrote:
> > On Mon, Mar 29, 2021 at 01:56:53PM +0300, Zidenberg, Tsahi wrote:
> >> arm64 access to userspace addresses in bpf and kprobes is broken,
> >> because kernelspace address accessors are always used, and won't work
> >> for userspace.
> > What does not work exactly?
> >
> > What is broken that is fixed in these changes?  I can't seem to
> > understand that as it feels like bpf and kprobes works on 5.4.y unless
> > something broke it?
> >
> > confused,
> >
> > greg k-h
> 
> The original bug that I was working on: command line parameters don't
> appear when snooping execve using bpf on arm64.

Has this ever worked?  If not, it's not really a regression that needs
to be fixed, just use a newer kernel version, right?

> This is true using
> either osquery (with --enable_bpf_events) or bcc (execsnoop-bpfcc).
> The reason, it seems, is that in arm64 userspace addresses cannot be
> accessed with kernelspace accessors.
> This bug is fixed with Patch 1.
> 
> Since Patch 1 added ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE, I thought
> it made sense to check what else uses this config. I did not verify
> kprobes are also broken in the same way, but it seems likely, and the
> fix is very small. If only Patch 1 is merged - I'll be happy :)

But your "patch 1" is no where near what that commit is upstream so now
you have divered from what is there and created something new.  And we
don't like that for obvious reasons (no testing, maintaining over time,
etc.)

So again, if you want to do this type of thing, why not just use a newer
kernel?

thanks,

greg k-h

  reply	other threads:[~2021-04-13  7:27 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-29 10:56 [PATCH 0/2] fix userspace access on arm64 for linux 5.4 Zidenberg, Tsahi
2021-03-29 10:58 ` [PATCH 1/2] bpf: fix userspace access for bpf_probe_read{, str}() Zidenberg, Tsahi
2021-03-30 17:21   ` Sasha Levin
2021-03-31 18:37     ` Zidenberg, Tsahi
2021-04-03  9:56       ` Greg KH
2021-04-04  9:13         ` Zidenberg, Tsahi
2021-04-10 11:29           ` Greg KH
2021-04-12 20:01             ` Zidenberg, Tsahi
2021-04-13  7:28               ` Greg KH
2021-03-29 10:59 ` [PATCH 2/2] tracing/kprobes: handle userspace access on unified probes Zidenberg, Tsahi
2021-04-10 11:29   ` Greg KH
2021-04-10 11:30 ` [PATCH 0/2] fix userspace access on arm64 for linux 5.4 Greg KH
2021-04-12 19:46   ` Zidenberg, Tsahi
2021-04-13  7:27     ` Greg KH [this message]
2021-04-21 13:04       ` Zidenberg, Tsahi
2021-04-21 13:26         ` Greg KH

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=YHVH2uNBTVDsJ66m@kroah.com \
    --to=greg@kroah.com \
    --cc=stable@vger.kernel.org \
    --cc=tsahee@amazon.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.