[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4675DFA8.6060703@gentoo.org>
Date: Mon, 18 Jun 2007 03:28:08 +0200
From: Alexander Gabert <pappy@...too.org>
To: Arjan van de Ven <arjan@...radead.org>, libc-alpha@...rceware.org,
linux-kernel@...r.kernel.org, hardened@...too.org
Subject: Re: AT_ENTROPY1 and AT_ENTROPY2 values for include/linux/auxvec.h
Arjan van de Ven schrieb:
> On Mon, 2007-06-18 at 01:40 +0200, Alexander Gabert wrote:
>
>> Hello glibc and kernel maintainers,
>>
>> could you please add two AT_ entries to include/linux/auxvec.h in the
>> upstream kernel and the respective elf/elf.h definitions in glibc.
>>
>
>
> while I'm not per se against adding such aux vectors, I think it's a bad
> mistake to make them a config option (and 2 options at that!!)
>
Well our glibc patch (still under development, here comes a snippet)
will conditionally check for the auxv and if not "fall back" to normal
SSP entropy:
- /* Set up the stack checker's canary. */
- uintptr_t stack_chk_guard = _dl_setup_stack_chk_guard ();
+ /* Set up the stack checker's canary, optional kernel entropy */
+ uintptr_t stack_chk_guard;
+
+ if (GLRO(dl_entropy) != 0) {
+ stack_chk_guard = GLRO(dl_entropy);
+ }
+ else {
+ stack_chk_guard = _dl_setup_stack_chk_guard ();
+ }
Hence the config option for the kernel- it's philosophy at Gentoo to
make choices available to users how they want their systems to behave,
even on the expense of added complexity and need to "understand" how
things work in the first place.
If you add the aux vector behaviour as a default, there would surely be
a backport of the default behaviour to the more "Gentoo flavoured"
choice-based system of activating/deactivating it to your own needs.
For your second question, why two config options: entropy is a precious
resource and many critical apps rely on it.
Until SSPx (http://dev.gentoo.org/~pappy/sspx/ssxp.pdf) is not
available, we don't want to force users to have two vector entries with
one containing unneeded (wasted?) entropy. SSP already works good, so
if this stuff makes it's way into the kernel or kernel and glibc folks
tell me which numbers i can use, i can make my patches and add the logic
to Gentoo kernel sources and glibc.
Sincere thanks,
Alex
-
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/
Powered by blists - more mailing lists