linux-kernel - Re: deconflicting new syscall numbers for 6.11

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: <CAHk-=win2mesMNEfL-KZQ_jk1YH8N8dL9r=7XOLp28_WMazpVg@mail.gmail.com>
Date: Thu, 4 Jul 2024 14:07:41 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: "Jason A. Donenfeld" <Jason@...c4.com>
Cc: jolsa@...nel.org, mhiramat@...nel.org, cgzones@...glemail.com, 
	brauner@...nel.org, linux-kernel@...r.kernel.org, arnd@...db.de
Subject: Re: deconflicting new syscall numbers for 6.11

On Thu, 4 Jul 2024 at 12:19, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> Bah. I guess I'll have to walk through the patch series once again.

Ok, I went through it once. First comments:

The system call additions look really random. You don't add them to
all architectures, but the ones you *do* add them to seem positively
pointless:

 - I don't think you should introduce the system all on 32-bit
architectures, and that includes as a compat call on 64-bit.

    The VM_DROPPABLE infrastructure doesn't even exist on 32-bit, and
while that might not be technically a requirement, it does seem to
argue against doing this on 32-bit architectures. Plus nobody sane
cares.

    You didn't even enable it on 32-bit x86 in the vdso, so why did
you enable it as a syscall?

 - even 64-bit architectures don't necessarily have anything like a
vdso, eg alpha.

It looks like you randomly just picked the architectures that have a
syscall.tbl file, rather than architectures where this made sense. I
thin kyou should drop all of them except possibly arm64, s390 and
powerpc.

I'm very ambivalent about the VM_DROPPABLE code.

On one hand, it's something we've discussed many times, and I don't
hate it. On the other hand, the discussions have always been about
actually exposing it to user space as a MAP_DROPPABLE so that user
space can do caching.

In fact, I'm almost certain that *because* you didn't expose it to
mmap(), people will now then instead mis-use vgetrandom_alloc()
instead to allocate random MAP_DROPPABLE pages. That is going to be a
nightmare.

And that nightmare has to be avoided. Which in turn means that I think
vgetrandom_alloc() has to go, and you just need to expose
MAP_DROPPABLE instead that obly works for private anonymous mappings,
and make sure glibc uses that.

Because as your patch series stands now, the semantics are unacceptable.

This is a non-starter. When I see a new system call where my reaction
is not just "this should have been just a mmap()", but then
immediately followed by "Oh, and people will mis-use this as a cool
mmap", I'm not merging that system call.

So I don't hate VM_DROPPABLE per se, but the interface is simply not
ok. vgetrandom_alloc() absolutely *has* to go, and needs to just be a
user-space wrapper around regular mmap.

                 Linus