linux-kernel - Re: [PATCH 4/5] Add a sysconf syscall

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>] [day] [month] [year] [list]

Message-ID: <20110516173956.GE25898@one.firstfloor.org>
Date:	Mon, 16 May 2011 19:39:56 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Steve Munroe <sjmunroe@...ibm.com>
Cc:	Andi Kleen <andi@...stfloor.org>, Andi Kleen <ak@...ux.intel.com>,
	libc-alpha@...rceware.org, linux-kernel@...r.kernel.org,
	Denys Vlasenko <vda.linux@...glemail.com>
Subject: Re: [PATCH 4/5] Add a sysconf syscall

On Mon, May 16, 2011 at 12:06:40PM -0500, Steve Munroe wrote:
d  Seems like the Aux Vector would do job. Simple, in memory, LIBC already

It's difficult to update the aux vector dynamically after the program has
started.  Applications in theory could reuse it for something else, so it 
wouldn't be safe to poke in there (and quite complex too)

One of the main motivations for the new call was _SC_NPROCESSORS_ONLN,
which can change dynamically.

So if we put that into the aux vector the program would only ever know about
the CPUs online at startup time. Not good.

> fills in some sysconf values from the auxv and has infrastructure for that.
> And the perform conscious hacker can access the auxv directly if they want.

rlimits are not static and the they don't map to clone semantics (see all the
other mails on this) Various values are based on rlimits.

vsyscalls would work for the online CPUs, but not for a lot of other things.

I suppose if this was just to solve the online cpu case it may be a suitable 
solution, but I tried to be a bit more general.

Here's a handy reference table:

                            vdso            aux            syscall
constant values               x               x                x         
rlimit based values           -*              -                x 
runtime values like cpus      x               -                x
portable to all archs         -               x                x
performance                  best            best            good enough
coding complexity            high            low               low

* unless you break clone and add a writable page to each program and be complex

So you can see the aux vector is not doing very well overall.
The vdso is somewhat better, but only if you sacrify the rlimits
and accept high complexity.

The syscall is imho still the sweet spot overall. It's excellent 
everywhere, except it doesn't have the best performance. But it seems
good enough.

-Andi
--
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/