lkml.org 
[lkml]   [2019]   [Oct]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Convert filldir[64]() from __put_user() to unsafe_put_user()
On Tue, Oct 08, 2019 at 08:58:58PM +0100, Al Viro wrote:

> That's powerpc. And while the constant-sized bits are probably pretty
> useless there as well, note the allow_read_from_user()/prevent_read_from_user()
> part. Looks suspiciously similar to user_access_begin()/user_access_end()...
>
> The difference is, they have separate "for read" and "for write" primitives
> and they want the range in their user_access_end() analogue. Separating
> the read and write isn't a problem for callers (we want them close to
> the actual memory accesses). Passing the range to user_access_end() just
> might be tolerable, unless it makes you throw up...

BTW, another related cleanup is futex_atomic_op_inuser() and
arch_futex_atomic_op_inuser(). In the former we have
if (!access_ok(uaddr, sizeof(u32)))
return -EFAULT;

ret = arch_futex_atomic_op_inuser(op, oparg, &oldval, uaddr);
if (ret)
return ret;
and in the latter we've got STAC/CLAC pairs stuck into inlined bits
on x86. As well as allow_write_to_user(uaddr, sizeof(*uaddr)) on
ppc...

I don't see anything in x86 one objtool would've barfed if we pulled
STAC/CLAC out and turned access_ok() into user_access_begin(),
with matching user_access_end() right after the call of
arch_futex_atomic_op_inuser(). Everything is inlined there and
no scary memory accesses would get into the scope (well, we do
have
if (!ret)
*oval = oldval;
in the very end of arch_futex_atomic_op_inuser() there, but oval
is the address of a local variable in the sole caller; if we run
with kernel stack on ring 3 page, we are deeply fucked *and*
wouldn't have survived that far into futex_atomic_op_inuser() anyway ;-)

\
 
 \ /
  Last update: 2019-10-08 22:16    [W:0.178 / U:0.380 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site