linux-kernel - RE: [Linaro-mm-sig] Re: [PATCH] epoll: try to be a _bit

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] [day] [month] [year] [list]

Message-ID: <b3e869996b554b57bf59a66cc10ac810@AcuMS.aculab.com>
Date: Sat, 11 May 2024 18:25:02 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Christian Brauner' <brauner@...nel.org>, Daniel Vetter <daniel@...ll.ch>
CC: Christian König <ckoenig.leichtzumerken@...il.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>, Al Viro
	<viro@...iv.linux.org.uk>, "keescook@...omium.org" <keescook@...omium.org>,
	"axboe@...nel.dk" <axboe@...nel.dk>, "christian.koenig@....com"
	<christian.koenig@....com>, "dri-devel@...ts.freedesktop.org"
	<dri-devel@...ts.freedesktop.org>, "io-uring@...r.kernel.org"
	<io-uring@...r.kernel.org>, "jack@...e.cz" <jack@...e.cz>,
	"laura@...bott.name" <laura@...bott.name>, "linaro-mm-sig@...ts.linaro.org"
	<linaro-mm-sig@...ts.linaro.org>, "linux-fsdevel@...r.kernel.org"
	<linux-fsdevel@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "linux-media@...r.kernel.org"
	<linux-media@...r.kernel.org>, "minhquangbui99@...il.com"
	<minhquangbui99@...il.com>, "sumit.semwal@...aro.org"
	<sumit.semwal@...aro.org>,
	"syzbot+045b454ab35fd82a35fb@...kaller.appspotmail.com"
	<syzbot+045b454ab35fd82a35fb@...kaller.appspotmail.com>,
	"syzkaller-bugs@...glegroups.com" <syzkaller-bugs@...glegroups.com>
Subject: RE: [Linaro-mm-sig] Re: [PATCH] epoll: try to be a _bit_ better about
 file lifetimes

From: Christian Brauner
> Sent: 10 May 2024 11:55
> 
> > For the uapi issue you describe below my take would be that we should just
> > try, and hope that everyone's been dutifully using O_CLOEXEC. But maybe
> > I'm biased from the gpu world, where we've been hammering it in that
> > "O_CLOEXEC or bust" mantra since well over a decade. Really the only valid
> 
> Oh, we're very much on the same page. All new file descriptor types that
> I've added over the years are O_CLOEXEC by default. IOW, you need to
> remove O_CLOEXEC explicitly (see pidfd as an example). And imho, any new
> fd type that's added should just be O_CLOEXEC by default.

For fd a shell redirect creates you may want so be able to say
'this fd will have O_CLOEXEC set after the next exec'.
Also (possibly) a flag that can't be cleared once set and that
gets kept by dup() etc.
But maybe that is excessive?

I've certainly used:
# ip netns exec ns command 3</sys/class/net
in order to be able to (easily) read status for interfaces in the
default namespace and a specific namespace.
The would be hard if the O_CLOEXEC flag had got set by default.
(Especially without a shell builtin to clear it.)

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)