linux-kernel - Re: [PATCH v2 0/2] vfs: Define new syscall getumask.

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: <CALCETrX20sVXEQruJXy=uet4e-vnc3NeWYHe3Cm6TOqn772-Bg@mail.gmail.com>
Date:	Thu, 14 Apr 2016 10:56:38 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Pavel Emelyanov <xemul@...allels.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Florian Weimer <fw@...eb.enyo.de>,
	Josh Triplett <josh@...htriplett.org>,
	iulia manda21 <iulia.manda21@...il.com>,
	Cyrill Gorcunov <gorcunov@...il.com>,
	Alexey Dobriyan <adobriyan@...il.com>,
	dave hansen <dave.hansen@...ux.intel.com>,
	gorcunov <gorcunov@...nvz.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Ingo Molnar <mingo@...hat.com>,
	Eric B Munson <emunson@...mai.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	linux-api <linux-api@...r.kernel.org>,
	rostedt <rostedt@...dmis.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrea Arcangeli <aarcange@...hat.com>,
	mguzik <mguzik@...hat.com>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	"Richard W.M. Jones" <rjones@...hat.com>,
	Arnd Bergmann <arnd@...db.de>, zab <zab@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Davidlohr Bueso <dave@...olabs.net>,
	Milosz Tanski <milosz@...in.com>,
	Al Viro <viro@...iv.linux.org.uk>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH v2 0/2] vfs: Define new syscall getumask.

On Apr 13, 2016 2:01 PM, "Mathieu Desnoyers"
<mathieu.desnoyers@...icios.com> wrote:
>
> ----- On Apr 13, 2016, at 11:39 AM, Mathieu Desnoyers mathieu.desnoyers@...icios.com wrote:
>
> > ----- On Apr 13, 2016, at 8:57 AM, Richard W.M. Jones rjones@...hat.com wrote:
> >
> >> v1 -> v2:
> >>
> >> - Use current_umask() instead of current->fs->umask.
> >>
> >> - Retested it.
> >>
> >> ----------------------------------------------------------------------
> >>
> >> It's not possible to read the process umask without also modifying it,
> >> which is what umask(2) does.  A library cannot read umask safely,
> >> especially if the main program might be multithreaded.
> >>
> >> This patch series adds a trivial system call "getumask" which returns
> >> the umask of the current process.
> >
> > In addition to this system call, we could extend a variation of my
> > thread_local_abi system call (https://lkml.org/lkml/2016/4/4/455)
> > (could be without features flags, or an entirely new system call
> > specifically for a umask cache) to register a "current umask" cache
> > located in a TLS area.
> >
> > Basically, reading the current umask value would be a simple load from
> > a TLS variable.
>
> I'm actually discussing 3 separate things here: the umask, sigmask, and
> cpu affinity mask.
>
> Not sure if caching the umask in a TLS would be that useful, though.
> The caching idea seems to make more sense for signal mask and cpu
> affinity mask.
>

I think this is of questionable value.

Keep in mind that every feature like this adds overhead to lots of
code paths as well as additional complexity.  Such features should be
justified by big performance benefits.

Given that processes can easily track their own umasks and signal
masks if they care, I don't see why the kernel would want to help.

--Andy