Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Florian Weimer <fweimer@redhat.com>
To:     Thomas Gleixner <tglx@linutronix.de>
Cc:     "Jason A. Donenfeld" <Jason@zx2c4.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org,
        x86@kernel.org, Nadia Heninger <nadiah@cs.ucsd.edu>,
        Thomas Ristenpart <ristenpart@cornell.edu>,
        Theodore Ts'o <tytso@mit.edu>,
        Vincenzo Frascino <vincenzo.frascino@arm.com>,
        Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
Subject: Re: [PATCH RFC v1] random: implement getrandom() in vDSO
References: <20220729145525.1729066-1-Jason@zx2c4.com>
        <CAHk-=wiLwz=9h9LD1-_yb1+T+u59a2EjTmMvCiGj4A-ZsPN1wA@mail.gmail.com>
        <YuXCpyULk6jFgGV5@zx2c4.com> <87zggnsqwj.ffs@tglx>
        <Yuhe6IIFXqNMZs5b@zx2c4.com> <87bkt2sqq4.ffs@tglx>
        <YuktqQS7Rb0IbJNh@zx2c4.com> <878ro6smmm.ffs@tglx>
Date:   Fri, 05 Aug 2022 10:36:16 +0200
In-Reply-To: <878ro6smmm.ffs@tglx> (Thomas Gleixner's message of "Tue, 02 Aug
        2022 17:14:57 +0200")
Message-ID: <87v8r713zz.fsf@oldenburg.str.redhat.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

* 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