linux-kernel - Re: [PATCH RFC v1] random: implement getrandom() in vDSO

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87v8r713zz.fsf@oldenburg.str.redhat.com>
Date:   Fri, 05 Aug 2022 10:36:16 +0200
From:   Florian Weimer <fweimer@...hat.com>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     "Jason A. Donenfeld" <Jason@...c4.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        linux-kernel@...r.kernel.org, linux-crypto@...r.kernel.org,
        x86@...nel.org, Nadia Heninger <nadiah@...ucsd.edu>,
        Thomas Ristenpart <ristenpart@...nell.edu>,
        Theodore Ts'o <tytso@....edu>,
        Vincenzo Frascino <vincenzo.frascino@....com>,
        Adhemerval Zanella Netto <adhemerval.zanella@...aro.org>
Subject: Re: [PATCH RFC v1] random: implement getrandom() in vDSO

* Thomas Gleixner:

> On Tue, Aug 02 2022 at 15:59, Jason A. Donenfeld wrote:
>> On Tue, Aug 02, 2022 at 03:46:27PM +0200, Thomas Gleixner wrote:
>>> Right now the Linux VDSO functions are 1:1 replacements for system calls
>>> and not adding a magic pile of functionality which is otherwise not
>>> available.
>>> 
>>> What you are proposing is to have an implementation which is not
>>> available via a regular syscall. Which means you are creating a VDSO
>>> only syscall which still has the same problem as any other syscall in
>>> terms of API design and functionality which needs to be supported
>>> forever.
>>
>> Wait, what? That's not correct. The WHOLE point is that vdso getrandom()
>> will generate bytes in the same way as the ordinary syscall, without
>> differences. Same function name, same algorithm. But just faster,
>> because vDSO. I explicitly don't want to dip into introducing something
>> different. That's the big selling point: that vDSO getrandom() and
>> syscall getrandom() are the same thing. If you trust one, you can trust
>> the other. If you expect properties of one, you get that from the other.
>> If you know the API of one, you can use the other.
>
> Seriously no. All existing VDSO functions have exactly the same function
> signature and semantics as their syscall counterparts. So they are drop
> in equivalent.
>
> But:
>
>   ssize_t getrandom(void *, void *, size_t, unsigned int);
>
> is very much different than
>
>   ssize_t getrandom(void *, size_t, unsigned int);
>
> Different signature and different semantics.

Just use

   ssize_t getrandom(size_t, unsigned int, void *);

then and have the system call ignore the argument.  There is recent
precedent for adding additional arguments to system calls, see
membarrier.  If we want to be super-conservative, we could add a new
flag and have the vDSO version always call into the kernel if the flag
isn't set.

*This* part is far less problematic compared to the approach to
per-thread memory allocation.

We now have:

* Explicit donation of memory areas to the kernel (set_robust_list,
  rseq).

* This getrandom_alloc vDSO call which does something unspecified and
  may return pointers which are or are not abstract.  (How is CRIU
  expected to handle this?)

* There's also userspace shadow stack coming.  I think the kernel moved
  away from implicit allocation, to something mmap-based.  It's not
  clear to me why that would be okay here, but not for shadow stacks.

Does io_uring have to handle a similar problem, too?

As long as the vDSO doesn't use private system calls, I don't expect any
practical problems, but this optimization doesn't really look to me like
something that intrinsically benefits from a completely new way of
allocating userspace memory for use by the kernel.

Thanks,
Florian