linux-kernel - Re: [PATCH] ELF: implement AT

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: <20081002225718.6a0d803a@infradead.org>
Date:	Thu, 2 Oct 2008 22:57:18 -0700
From:	Arjan van de Ven <arjan@...radead.org>
To:	Kees Cook <kees.cook@...onical.com>
Cc:	Jakub Jelinek <jakub@...hat.com>,
	Roland McGrath <roland@...hat.com>,
	linux-kernel@...r.kernel.org, Ulrich Drepper <drepper@...hat.com>,
	libc-alpha@...rceware.org
Subject: Re: [PATCH] ELF: implement AT_RANDOM for future glibc use

On Thu, 2 Oct 2008 22:29:38 -0700
Kees Cook <kees.cook@...onical.com> wrote:

> While discussing[1] the need for glibc to have access to random bytes
> during program load, it seems that an earlier attempt to implement
> AT_RANDOM got stalled.  This implements a configurable number of
> random bytes, as a multiple of userspace pointer size, available to
> every ELF program via a new auxv AT_RANDOM vector.


while I really like the idea of passing random bytes to glibc...
... why make it complex and configurable, rather than just always
passing, say 8 or 16 bytes.
16 bytes (say 4 vectors) is easier than "variable number of" both on the
kernel and on the glibc side, and nobody other than maybe Ulrich
and Jakub wouldn't know what to answer to the KConfig question anyway.

Or lets put it differently: why would I answer anything other than the
default? Your KConfig help text sure doesn't explain my what I give up
by answering 0 or 256....  If nobody can answer anything sensible other
than the default, it shouldn't be a config option imo.
--
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/