From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4530 Path: news.gmane.org!not-for-mail From: "Anthony G. Basile" Newsgroups: gmane.linux.lib.musl.general Subject: Re: yet another alternative libc Date: Thu, 30 Jan 2014 10:00:10 -0500 Message-ID: <52EA68FA.8000404@opensource.dyc.edu> References: <52E97075.4030306@gentoo.org> <20140130060641.GS24286@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1391093990 31453 80.91.229.3 (30 Jan 2014 14:59:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 30 Jan 2014 14:59:50 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4534-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jan 30 15:59:58 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1W8t5y-0002GJ-3v for gllmg-musl@plane.gmane.org; Thu, 30 Jan 2014 15:59:58 +0100 Original-Received: (qmail 14101 invoked by uid 550); 30 Jan 2014 14:59:57 -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 14093 invoked from network); 30 Jan 2014 14:59:57 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 In-Reply-To: <20140130060641.GS24286@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:4530 Archived-At: On 01/30/2014 01:06 AM, Rich Felker wrote: > On Wed, Jan 29, 2014 at 04:19:49PM -0500, Anthony G. Basile wrote: >> Hi everyone, >> >> I just thought I'd let everyone know that I've built a musl stage4 >> for amd64 and put it on the mirrors [1]. If you don't know about >> musl, you can read about it here [2]. Its yet another libc which >> aims to be a slim and fast. > > Glad to hear you're at the point of announcing this! Or more to the point, releasing it in usable form ;) > >> I've got a stage4 (kinda/sorta). It is not made using catalyst but >> rather starts from a musl chroot and builds a new chroot using a >> ROOT=rootfs emerge -ev @system technique. The scripts are on the >> releng repo [3]. Right now there are lots of packages which do not >> immediately build with musl. Mostly these are due to header >> locations, gnu-isms, gnulib (which assumes way too much about >> internal implementations) and at least one bug in musl or gcc >> (depending on who you ask --- exit() compiled with >> --stack-protector-all). The patches are on the hardened-dev::musl >> overlay [4]. They are "quickies" and may need work if any are to go >> upstream. >> >> A few points about the stage: 1) it doesn't use busybox for its core >> utilities. I like a robust native development environment from >> which you can build. 2) Despite the fact that the profile is under >> hardened, it is still a vanilla stage. I'm working on getting it >> hardened, but a few packages break when we turn on pie, ssp, relro >> and/or bind_now. > > A few notes from our side (musl) regardinging your status for > hardening: > > 1. relro is presently not supported in musl, but it's just a no-op > (the relro range will remain writable after relocations) so it > shouldn't hurt to turn it on. > > 2. musl doesn't support lazy binding at all (and won't), so whether or > not you turn on bind_now at the linker level, it's always in effect. I don't think relro or bind_now are causing the issues I hit, but I didn't investigate enough. Right now I'm "entertaining" myself by building up that stage into a usable desktop. But soon I will run a full rebuild with hardening and see what happens. The biggest show stopper was gcc itself could not rebuild itself, ie, gentoo's vanilla gcc can build our hardened gcc which "works" but cannot in turn build hardened gcc again. I will provide details. > > 3. We're interested in any reports of problems with PIE and SSP. The > issue of SSP not getting initialized in tiny (configure-script-test > sized) programs that don't reference __stack_chk_fail is known, but > any other SSP-related problems would likely be something new we should > check out. I will certainly report. I assume the list is fine? > > Rich > -- Anthony G. Basile, Ph. D. Chair of Information Technology D'Youville College Buffalo, NY 14201 (716) 829-8197