linux-kernel - Re: [PATCH v3] tty: tty_io: remove hung_up_tty

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]

Date: Wed, 1 May 2024 14:20:35 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Marco Elver <elver@...gle.com>
Cc: paulmck@...nel.org, Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Dmitry Vyukov <dvyukov@...gle.com>, 
	syzbot <syzbot+b7c3ba8cdc2f6cf83c21@...kaller.appspotmail.com>, 
	linux-kernel@...r.kernel.org, syzkaller-bugs@...glegroups.com, 
	Nathan Chancellor <nathan@...nel.org>, Arnd Bergmann <arnd@...nel.org>, Al Viro <viro@...iv.linux.org.uk>, 
	Jiri Slaby <jirislaby@...nel.org>
Subject: Re: [PATCH v3] tty: tty_io: remove hung_up_tty_fops

On Wed, 1 May 2024 at 14:06, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> So it would be something like
>
>         const struct file_operations    * __data_racy f_op;
>
> and only the load of f_op would be volatile - not the pointer itself.

Noe that in reality, we'd actually prefer the compiler to treat that
"__data_racy" as volatile in the sense of "don't reload this value",
but at the same time be the opposite of volatile in the sense that
using one read multiple times is actually a good idea.

IOW, the problem is rematerialization ("read the value more than once
when there is just one access in the source"), not strictly a "read
the value separately each time it is accessed".

We've actually had that before: it's not that we want each access to
force a read from memory, we want to avoid a TOCTOU race.

Many of our "READ_ONCE()" uses are of that kind, and using "volatile"
sadly generates horrible code, but is the only way to tell the
compiler to not ever rematerialize the value by loading it _twice_.

I'd love to see an extension where "const volatile" basically means
exactly that: the volatile tells the compiler that it can't
rematerialize by doing the load multiple times, but the "const" would
say that if the compiler sees two or more accesses, it can still CSE
them.

Oh well. Thankfully it's not a hugely common code generation problem.
It comes up every once in a while, and I think the last time this
worry came up, I think we had gcc people tell us that they don't
actually ever rematerialize loads from memory.

Of course, that was an implementation issue, not a guarantee.

                           Linus