[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a4cffbd2aee74105864a7d68be829888@AcuMS.aculab.com>
Date: Wed, 14 Apr 2021 21:39:59 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Oleg Nesterov' <oleg@...hat.com>
CC: He Zhe <zhe.he@...driver.com>, Paul Moore <paul@...l-moore.com>,
"Eric Paris" <eparis@...hat.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 2/2] ptrace: is_syscall_success: Add syscall return code
handling for compat task
From: Oleg Nesterov
> Sent: 14 April 2021 17:56
>
> 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.
Not on X86_64.
The syscall entry code sets the type on the current system call entry.
So a process that is created as a 64bit process can make both i386
and x32 system calls as well as normal 64bit ones.
> But it looks deprecated,
> I think in_compat_syscall() should be used instead.
That does the right checks on x86.
Most code doesn't need to know about the subtle difference between
normal 32bit calls and x32 ones.
> But this doesn't matter, I still can't understand the problem.
Dunno, I only know the 'fix' is borked.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists