netdev - Re: [PATCH v4 0/7] kernel tinification: optionally compile out splice family of syscalls (splice, vmsplice, tee and sendfile)

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: <20141125185806.GA28116@thunk.org>
Date:	Tue, 25 Nov 2014 13:58:06 -0500
From:	Theodore Ts'o <tytso@....edu>
To:	David Miller <davem@...emloft.net>
Cc:	paulmck@...ux.vnet.ibm.com, rdunlap@...radead.org,
	pieter@...sman.nl, josh@...htriplett.org,
	alexander.h.duyck@...el.com, viro@...iv.linux.org.uk,
	ast@...mgrid.com, akpm@...ux-foundation.org, beber@...eeweb.net,
	catalina.mocanu@...il.com, dborkman@...hat.com,
	edumazet@...gle.com, ebiederm@...ssion.com, fabf@...net.be,
	fuse-devel@...ts.sourceforge.net, geert@...ux-m68k.org,
	hughd@...gle.com, iulia.manda21@...il.com, JBeulich@...e.com,
	bfields@...ldses.org, jlayton@...chiereds.net,
	linux-api@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-nfs@...r.kernel.org,
	mcgrof@...e.com, mattst88@...il.com, mgorman@...e.de,
	mst@...hat.com, miklos@...redi.hu, netdev@...r.kernel.org,
	oleg@...hat.com, Paul.Durrant@...rix.com, pefoley2@...oley.com,
	tgraf@...g.ch, therbert@...gle.com,
	trond.myklebust@...marydata.com, willemb@...gle.com,
	xiaoguangrong@...ux.vnet.ibm.com, zhenglong.cai@...c.com.cn
Subject: Re: [PATCH v4 0/7] kernel tinification: optionally compile out
 splice family of syscalls (splice, vmsplice, tee and sendfile)

On Tue, Nov 25, 2014 at 01:24:45PM -0500, David Miller wrote:
> 
> And then if some fundamental part of userland (glibc, klibc, etc.) finds
> a useful way to use splice for a fundamental operation, we're back to
> square one.

I'll note that the applications for these super-tiny kernels are
places where it's not likely they would be using glibc at all; think
very tiny embedded systems.  The userspace tends to be highly
restricted for the same space reasons why there is an effort to make
the kernel as small as possible.

In these places, they are using Linux already, but they're using a 2.2
or 2.4 kernel because 3.0 is just too damned big.  So the goal is to
try to provide them an alternative which allows them to use a modern,
but stripped down kernel.  If glibc or klibc isn't going to work
without splice, then it's not going to work on a pre 2.6 kernel
anyway, so things are no worse with these systems anyway.

After all, if we can get these systems to using a 3.x kernel w/o
splice, that's surely better than their using a 2.2 or 2.4 kernel w/o
the splice system, isn't it?

Cheers,

					- Ted
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html