From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8207 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Using direct socket syscalls on x86_32 where available? Date: Sun, 26 Jul 2015 12:59:07 -0400 Message-ID: <20150726165907.GM16376@brightrain.aerifal.cx> References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1437929970 19230 80.91.229.3 (26 Jul 2015 16:59:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 26 Jul 2015 16:59:30 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-8220-gllmg-musl=m.gmane.org@lists.openwall.com Sun Jul 26 18:59:27 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1ZJPGo-0004VA-6c for gllmg-musl@m.gmane.org; Sun, 26 Jul 2015 18:59:26 +0200 Original-Received: (qmail 14212 invoked by uid 550); 26 Jul 2015 16:59:22 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 14180 invoked from network); 26 Jul 2015 16:59:20 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:8207 Archived-At: On Sat, Jul 25, 2015 at 10:54:28AM -0700, Andy Lutomirski wrote: > On x86_32, the only way to call socket(2), etc is using socketcall. > This is slated to change in Linux 4.3: > > https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?h=x86/asm&id=9dea5dc921b5f4045a18c63eb92e84dc274d17eb > > If userspace adapts by preferring the direct syscalls when available, > it'll make it easier for seccomp to filter new userspace programs > (and, ideally, eventually disallow socketcall for sandbox-aware code). > > Would musl be willing to detect these syscalls and use them if available? > > (Code to do this probably shouldn't be committed until that change > lands in Linus' tree, just in case the syscall numbers change in the > mean time.) My preference would be not to do this, since it seems to be enlarging the code and pessimizing normal usage for the sake of a very special usage scenario. At the very least there would be at least one extra syscall to probe at first usage, and that probe could generate a termination on existing seccomp setups. :-p So far we don't probe and store results for any fallbacks though; we just do the fallback on error every time. This is because all of the existing fallbacks are in places where we actually want new functionality a new syscall offers, and the old ones are not able to provide it precisely but require poor emulation, and in these cases it's expected that the user not be using old kernels that can't give correct semantics. But in the case of these socket calls there's no semantic difference or reason for us to be preferring the 'new' calls. It's just a duplicate API for the same thing. Rich