mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@aerifal.cx>
To: musl@lists.openwall.com
Cc: gentoo-embedded@lists.gentoo.org, gentoo-hardened@lists.gentoo.org
Subject: Re: yet another alternative libc
Date: Thu, 30 Jan 2014 01:06:41 -0500	[thread overview]
Message-ID: <20140130060641.GS24286@brightrain.aerifal.cx> (raw)
In-Reply-To: <52E97075.4030306@gentoo.org>

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!

> 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.

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.

Rich


  parent reply	other threads:[~2014-01-30  6:06 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-29 21:19 Anthony G. Basile
2014-01-29 21:44 ` Daniel Cegiełka
2014-01-29 23:22   ` Luca Barbato
2014-01-30  6:06 ` Rich Felker [this message]
2014-01-30 15:00   ` Anthony G. Basile
2014-02-01  1:01     ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140130060641.GS24286@brightrain.aerifal.cx \
    --to=dalias@aerifal.cx \
    --cc=gentoo-embedded@lists.gentoo.org \
    --cc=gentoo-hardened@lists.gentoo.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).