Re: deconflicting new syscall numbers for 6.11

Linus Torvalds
2024-07-05T18:08:23Z

On Fri, 5 Jul 2024 at 10:53, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> That sounds not so good: the current state is 144 bytes, and it's
> expected that there'll be one of these per thread. Mapping 16k or 4k per
> thread seems pretty bad. At least it certainly seems that way? Wasting
> 16240 bytes per thread + a new vmap I can't imagine is okay.

Well, I guess the simple solution would be "just pick a size that is
guaranteed to be at most a page, and a power-of-two, and big enough".

You really don't have that many choices. Presumably we won't have
per-architecture random states anyway, so the smallest supported page
size is the upper limit, and if the current size is 144 bytes, we know
that 256 is the lower limit.

IOW, we pretty much know that the number is _always_ going to be 2**n
where 8 <= n <= 12.

Just pick one.

> | - Future memory tagging CPU extensions might allow us to prevent the
> | memory from being accessed unless the accesses are coming from vDSO
> | code, which would avoid heartbleed-like bugs. This is very appealing.

No. Stop this idiocy.

Now you are getting into cray-cray land. Nobody cares about random
numbers so much that they'd worry about leaking them from other
sources thanks to hardware bugs.

Seriously. This is the kind of "crazy random number" talk that makes
me go "I don't want to touch this".

Get your act together. There is *NO* way we care about this kind of
garbage, and just bringing it up makes me doubt that you have the
right mindset.

You claimed to not be one of the crazy people. SHOW IT.

Linus