From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6407 Path: news.gmane.org!not-for-mail From: Andy Lutomirski Newsgroups: gmane.linux.lib.musl.general Subject: Re: magic constants in some startup code Date: Fri, 31 Oct 2014 14:29:32 -0700 Message-ID: <5453FF3C.2030500@amacapital.net> References: <45BFC4C3-FA51-49B5-8C58-1C1FC075BD28@cognitive-electronics.com> <20141031141844.GA22465@brightrain.aerifal.cx> <8B3E5DDE-2691-4377-8934-362ACC7BEA69@cognitive-electronics.com> <20141031160913.GC22465@brightrain.aerifal.cx> <5453EEE3.1040208@amacapital.net> <20141031210513.GF22465@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1414790998 18519 80.91.229.3 (31 Oct 2014 21:29:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 31 Oct 2014 21:29:58 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6420-gllmg-musl=m.gmane.org@lists.openwall.com Fri Oct 31 22:29:52 2014 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XkJlW-0008Tj-6L for gllmg-musl@m.gmane.org; Fri, 31 Oct 2014 22:29:50 +0100 Original-Received: (qmail 19546 invoked by uid 550); 31 Oct 2014 21:29:48 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 19528 invoked from network); 31 Oct 2014 21:29:47 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=7DpuS8MPJa2vTwgv32UEEAe+/g6SkPQH4znwhFUIuw0=; b=GX244NuX4Sb1FWoUvbtrUVP4KNiyYivy+ANmc0LZonI+YamLSNbch1WaLHGWBh32QB yPgB9ElFT8YgNoTh81xlJGtb3zpL50QunQ5MFC+gTCYBzVB1aSS2Df2qDOb5fNKu+jky Kw2EVPl+vmJ8aoEnMbJrOkRdyW4vYTEpp42PuGW6ZMggjhdwIXW/qPKZX5Wa5XqxjyE9 KFsuOZQ6reyON2umLeqkg1BLvb1P86SINg3yb9RztTLzTf6/BLgIbQLbs2yeVM1QX5Un /6ZxIMoBVZsbNT2xat8h8gyn9o5OcNhuDeQri2GgLF2daXnOMtUqEyoBCcKMo4RG/fpU u4nQ== X-Gm-Message-State: ALoCoQmNKV2U1BevLR0ygPinUJPyF6Me/oMMQ78SA9gT0RvcFxeajnJ5/A/JcMkBYBq9nOcsZxuD X-Received: by 10.67.3.36 with SMTP id bt4mr26985169pad.99.1414790975112; Fri, 31 Oct 2014 14:29:35 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 In-Reply-To: <20141031210513.GF22465@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:6407 Archived-At: On 10/31/2014 02:05 PM, Rich Felker wrote: > On Fri, Oct 31, 2014 at 01:19:47PM -0700, Andy Lutomirski wrote: >> On 10/31/2014 09:09 AM, Rich Felker wrote: >>> On Fri, Oct 31, 2014 at 10:31:45AM -0400, Richard Gorton wrote: >>>> Thank you (and a follow up question) - what code looks at this >>>> canary? It is assigned to pthread_self()->canary, but I do not see >>>> any code inside musl itself that checks that value? A work in >>>> progress? Or does other code check this value? >>> >>> It's part of the stack-protector feature at the compiler level. gcc, >>> clang, and any other compilers that implement this feature generate >>> code to read the canary at the start of a function protected by stack >>> protector, store it between the saved return address and local >>> buffers, and check that it hasn't been clobbered before returning. >> >> I'm a bit confused by the code now. Is the canary intended to be >> per-thread or global? There's a copy in struct pthread. > > That's a matter of matching the ABI the compiler expects/imposes. For > some archs where accessing globals is expensive and accessing TLS is > cheap, GCC reads the canary from a fixed thread-pointer-relative > address. For others, it accesses the global. > >> Also, would it make sense for musl to implement getauxval? If so, it >> might be nice to do something to avoid inadvertent misuse of the part of >> AT_RANDOM value used here. > > musl does provide getauxval. That'll teach me to look at the wrong version of musl. > >> For example, musl could implement a trivial DRBG seeded by AT_RANDOM and >> replace the AT_RANDOM data with the first output from the DRBG at >> startup. Then getauxval users are safe and musl can also have a stream >> of decent random numbers for internal use. > > This imposes a large code size cost in the mandatory startup code even > on programs that have no interest in AT_RANDOM (99% or more). Instead, > the first call to getauxval could do this, though, but I'm not sure > it's a good approach anyway. Linux has added the getrandom syscall > which can provide the BSD getentropy function or the more featureful > getrandom API, so using getauxval(AT_RANDOM) seems like a bad idea. > Even if we avoided reuse of the same data that went into the canary, > there's no way for callers using getauxval(AT_RANDOM) to tell whether > some other library code in the same process has already consumed > entropy from AT_RANDOM, so using it is not library-safe. It seems like > we should try to discourage use of getauxval(AT_RANDOM) as an entropy > source rather than giving false hope that it's safe. getrandom(2) has the annoying problem that you can't ask it for best-effort entropy. This caused systemd to add a /dev/urandom fallback a few days ago (sigh). Maybe I'll try to get a GRND_BESTEFFORT flag for getrandom into the kernel. I suppose that a musl getrandom wrapper could emulate that flag (only) or something on older kernels. Or maybe glibc and musl could both agree to add some get_sort_of_decent_entropy function based on AT_RANDOM. > >> If you think this is a good idea, I could implement it. The main >> downside would be that it'll require some crypto primitive. There's >> already a SHA-256 implementation in musl that could be reused, but it >> would be a bit unfortunate to pull it in to all musl-linked static binaries. > > Yes, code size is a concern, but it could be tucked away as a > dependency of other functions instead of being a dependency of the > startup code. Most or all existing getauxval users are unlikely to be using AT_RANDOM, so doing this without any bloat might be hard. --Andy