RE: [PATCH 2/2] ptrace: is_syscall_success: Add syscall return code handling for compat task

[David Laight]

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)