[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87v9lx3t4j.fsf@x220.int.ebiederm.org>
Date: Sat, 18 Apr 2020 06:55:56 -0500
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Christophe Leroy <christophe.leroy@....fr>
Cc: Christoph Hellwig <hch@....de>, Arnd Bergmann <arnd@...db.de>,
x86@...nel.org, linux-kernel@...r.kernel.org,
Alexander Viro <viro@...iv.linux.org.uk>,
linux-fsdevel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
linuxppc-dev@...ts.ozlabs.org, Jeremy Kerr <jk@...abs.org>
Subject: Re: [PATCH 1/2] signal: Factor copy_siginfo_to_external32 from copy_siginfo_to_user32
Christophe Leroy <christophe.leroy@....fr> writes:
> Le 17/04/2020 à 23:09, Eric W. Biederman a écrit :
>>
>> To remove the use of set_fs in the coredump code there needs to be a
>> way to convert a kernel siginfo to a userspace compat siginfo.
>>
>> Call that function copy_siginfo_to_compat and factor it out of
>> copy_siginfo_to_user32.
>
> I find it a pitty to do that.
>
> The existing function could have been easily converted to using
> user_access_begin() + user_access_end() and use unsafe_put_user() to copy to
> userspace to avoid copying through a temporary structure on the stack.
>
> With your change, it becomes impossible to do that.
I don't follow. You don't like temporary structures in the coredump
code or temporary structures in copy_siginfo_to_user32?
A temporary structure in copy_siginfo_to_user is pretty much required
so that it can be zeroed to guarantee we don't pass a structure with
holes to userspace.
The implementation of copy_siginfo_to_user32 used to use the equivalent
of user_access_begin() and user_access_end() and the code was a mess
that was very difficult to reason about. I recall their being holes
in the structure that were being copied to userspace.
Meanwhile if you are going to set all of the bytes a cache hot temporary
structure is quite cheap.
> Is that really an issue to use that set_fs() in the coredump code ?
Using set_fs() is pretty bad and something that we would like to remove
from the kernel entirely. The fewer instances of set_fs() we have the
better.
I forget all of the details but set_fs() is both a type violation and an
attack point when people are attacking the kernel. The existence of
set_fs() requires somethings that should be constants to be variables.
Something about that means that our current code is difficult to protect
from spectre style vulnerabilities.
There was a very good thread about it all in I think 2018 but
unfortunately I can't find it now.
Eric
Powered by blists - more mailing lists