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: <ZoiLzzM94m_sjfVK@zx2c4.com>
Date: Sat, 6 Jul 2024 02:11:59 +0200
From: "Jason A. Donenfeld" <Jason@...c4.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
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

Hi Linus,

On Fri, Jul 05, 2024 at 12:46:37PM -0700, Linus Torvalds wrote:
> If saying "the state size is fixed at 256 bytes" means that ten years
> from now, we won't be updating to some super-duper fancy new algorithm
> that wants to keep a huge state size - then that's a GOOD thing.

I'm all for avoiding fanciness. I can imagine three plausible scenarios
where we benefit from the kernel doing the allocation, rather than mmap,
or where it's nice to have the kernel decide on the size:

- On some platform, it's actually more efficient to generate N blocks,
  such that the state there needs to be larger.

- The amount of state that we buffer increases according to some speed
  vs practicality trade off that changes. (Right now we buffer 1.5
  blocks; maybe 3.5 would be better eventually.)

- We find out that there's a better way of doing all this with a special
  mapping instead, or some other means.

What I have in mind, IOW, isn't fanciness. But alright, let me run with
where you're urging me and see where that takes things. 

> Side note: you could just stick the size as a constant in the vdso too.

Yea, this sounds more like solution (4) from my last email. I'll give
that a shot and see what it's like nuking the syscall. I'll ping here
when v21 of the series is ready, and hopefully you like it more.

Thanks for brainstorming this all with me.

Jason