From: Oleg Nesterov <oleg@redhat.com>
To: David Laight <David.Laight@ACULAB.COM>
Cc: He Zhe <zhe.he@windriver.com>, Paul Moore <paul@paul-moore.com>,
Eric Paris <eparis@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] ptrace: is_syscall_success: Add syscall return code handling for compat task
Date: Wed, 14 Apr 2021 18:55:47 +0200 [thread overview]
Message-ID: <20210414165547.GA22294@redhat.com> (raw)
In-Reply-To: <e2efffb879914176a2eae8b52a3c5c33@AcuMS.aculab.com>
On 04/14, David Laight wrote:
>
> From: Oleg Nesterov
> > Sent: 14 April 2021 16:08
> >
> > Add audit maintainers...
> >
> > On 04/14, He Zhe wrote:
> > >
> > > When 32-bit userspace application is running on 64-bit kernel, the 32-bit
> > > syscall return code would be changed from u32 to u64 in regs_return_value
> > > and then changed to s64. Hence the negative return code would be treated
> > > as a positive number and results in a non-error in, for example, audit
> > > like below.
> >
> > Sorry, can understand. At least on x86_64 even the 32-bit syscall returns
> > long, not u32.
> >
> > Hmm. And afaics on x86 is_compat_task() is only defined if !CONFIG_COMPAT,
> > so this patch looks wrong anyway.
>
> And, as with the other patch a x64_64 64bit process can make both types
> of 32bit system call - so it needs to depend on the system call entry type
> not any type of the task.
I don't understand... but iirc is_compat_task() used to check TS_COMPAT and
this is what we need to detect the 32-bit syscall. But it looks deprecated,
I think in_compat_syscall() should be used instead.
But this doesn't matter, I still can't understand the problem.
Oleg.
next prev parent reply other threads:[~2021-04-14 16:56 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-14 8:02 [PATCH 2/2] ptrace: is_syscall_success: Add syscall return code handling for compat task He Zhe
2021-04-14 15:08 ` Oleg Nesterov
2021-04-14 16:17 ` David Laight
2021-04-14 16:55 ` Oleg Nesterov [this message]
2021-04-14 21:39 ` David Laight
2021-04-15 5:12 ` He Zhe
2021-04-15 5:48 ` Oleg Nesterov
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=20210414165547.GA22294@redhat.com \
--to=oleg@redhat.com \
--cc=David.Laight@ACULAB.COM \
--cc=eparis@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=zhe.he@windriver.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.