linux-kernel - Re: [RFC] x86: restrict pid namespaces to 32 or 64 bit syscalls

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: <20110815201419.GA20296@openwall.com>
Date:	Tue, 16 Aug 2011 00:14:19 +0400
From:	Solar Designer <solar@...nwall.com>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Andi Kleen <andi@...stfloor.org>,
	Vasiliy Kulikov <segoon@...nwall.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	James Morris <jmorris@...ei.org>,
	kernel-hardening@...ts.openwall.com, x86@...nel.org,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	Will Drewry <wad@...omium.org>
Subject: Re: [RFC] x86: restrict pid namespaces to 32 or 64 bit syscalls

On Mon, Aug 15, 2011 at 11:59:56AM -0700, H. Peter Anvin wrote:
> There is really no bloody difference between i386 vs x86-64 and, say,
> sys_oldstat versus sys_stat, or anything else along those lines.

There is a difference from a sysadmin standpoint: a sysadmin knows that
certain containers have Linux distro userlands for i386 and certain
others for x86-64, so he/she can configure things accordingly.  Even if
a customer using one of those containers installs extra software
packages, this extra software will work just fine as long as it's for
the same ABI.  The same doesn't hold true for sys_oldstat versus
sys_stat, etc.

> Putting in a bunch of ad hoc facilities because of semi-plausible
> performance wins rather than building a sane filtering facility which
> can be optimized as a single path is ridiculous.

I don't mind having a general filtering facility if it gets accepted
into the kernel (somehow Will's patch is not applied yet), and I don't
mind optimizing it to the point where it's not any slower for the "all
syscalls permitted but not all ABIs are" case.  I suspect that the
result of such optimizations will be similar to having these things
implemented separately, though - but I could be wrong.

So how do we proceed from here?  Start by getting Will's patch applied?

Alexander
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/