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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160418021259.GB16600@x>
Date:	Sun, 17 Apr 2016 19:12:59 -0700
From:	Josh Triplett <josh@...htriplett.org>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	"H. Peter Anvin" <hpa@...or.com>, Theodore Ts'o <tytso@....edu>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	"Richard W.M. Jones" <rjones@...hat.com>,
	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	mingo@...hat.com, Andrew Morton <akpm@...ux-foundation.org>,
	luto@...nel.org, viro@...iv.linux.org.uk, zab <zab@...hat.com>,
	emunson@...mai.com,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Andrea Arcangeli <aarcange@...hat.com>,
	Pavel Emelyanov <xemul@...allels.com>, sfr@...b.auug.org.au,
	Milosz Tanski <milosz@...in.com>,
	rostedt <rostedt@...dmis.org>, arnd@...db.de,
	ebiederm@...ssion.com, gorcunov <gorcunov@...nvz.org>,
	iulia manda21 <iulia.manda21@...il.com>,
	dave hansen <dave.hansen@...ux.intel.com>,
	mguzik <mguzik@...hat.com>, adobriyan@...il.com,
	Davidlohr Bueso <dave@...olabs.net>,
	linux-api <linux-api@...r.kernel.org>, gorcunov@...il.com,
	fw@...eb.enyo.de, Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH v2 0/2] vfs: Define new syscall getumask.

On Mon, Apr 18, 2016 at 10:09:25AM +0900, Greg KH wrote:
> On Sun, Apr 17, 2016 at 05:38:24PM -0700, H. Peter Anvin wrote:
> > On 04/13/16 19:13, Theodore Ts'o wrote:
> > > 
> > > One other reason to suggest using a /proc file is that you're not at
> > > the mercy of the glibc folks to wire up a new system call.  (Glibc has
> > > been refusing to wire up getrandom(2), for example.   Grrrr.....)
> > > 
> > 
> > This brings right back up the libinux idea.  There are continued
> > concerns about type compatibility, but saying "oh, use syscall(3)
> > instead" has worse properties than a Linux-kernel-team maintained
> > libinux.  Last I heard the glibc team had (reluctantly?) agreed to do
> > something to deal with linux-specific system calls, but last I heard
> > nothing had happened.  The last discussion I see on the glibc mailing
> > list dates back to November, and that thread seems to have died from
> > bikeshedding, again.
> > 
> > There aren't a *lot* of such system calls, but even in that thread the
> > "oh, only two applications need this, let them use syscall(3)" seems to
> > remain.
> 
> And only 2 applications will continue to use it because no one wants to
> write syscall() wrappers for their individual applications, so it's a
> vicious cycle :(
> 
> I really like the 'libinux' idea, did anyone every hack up a first-pass
> at this?  And I'm guessing we have more syscalls now that would need to
> be added (like getrandom(), but that shouldn't be too difficult.

Personally, I'd suggest that libinux should wire up *all* (non-obsolete)
syscalls, not just those that haven't already been exposed via any
particular libc implementation.  Each such syscall function would have
minimal overhead, since unlike libc these wrappers would not have any
special handling (other than use of the vdso) and would directly map to
the kernel syscall signature.  Given a standard prefix like sys_ or
linux_, that would provide a clear distinction between direct-syscall
functions and libc functions, and avoid any future conflict if libc adds
a function named the same as the syscall.

As a random example, sys_getpid() would *always* call the getpid
syscall, rather than reading a cache within the library.  (And
sys_gettid would call the gettid syscall, rather than failing to exist.)