* yet another alternative libc
@ 2014-01-29 21:19 Anthony G. Basile
2014-01-29 21:44 ` Daniel Cegiełka
2014-01-30 6:06 ` Rich Felker
0 siblings, 2 replies; 6+ messages in thread
From: Anthony G. Basile @ 2014-01-29 21:19 UTC (permalink / raw)
To: gentoo-embedded-cnFmAm88PdgLnqt3yJz4RQ,
gentoo-hardened-cnFmAm88PdgLnqt3yJz4RQ,
musl-ZwoEplunGu1jrUoiu81ncdBPR1lH4CV8
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.
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.
Enjoy or ignore at your discretion.
--Tony
Refs.
[1] http://distfiles.gentoo.org/experimental/amd64/musl/
[2] http://www.musl-libc.org/
[3]
http://git.overlays.gentoo.org/gitweb/?p=proj/releng.git;a=tree;f=tools-musl
[4] http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-dev.git;a=tree
--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail : blueness-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA
GnuPG ID : F52D4BBA
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: yet another alternative libc
2014-01-29 21:19 yet another alternative libc 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
1 sibling, 1 reply; 6+ messages in thread
From: Daniel Cegiełka @ 2014-01-29 21:44 UTC (permalink / raw)
To: musl; +Cc: gentoo-embedded, gentoo-hardened
Nice. I'm also develop stage4 (amd64) but with own replacement for
(huge) portage/python (in C/shell).. Everything is statically linked:
gcc-4.8.2: 61.5MB
binutils-2.23.2: 13.8MB
gdb-7.5.1: 6.3MB
In fact, hardened gcc+musl is a bit problematic...
btw. with relro/ssp binaries are a bit bigger.
ok., I'm starting to install :)
thx,
Daniel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: yet another alternative libc
2014-01-29 21:19 yet another alternative libc Anthony G. Basile
2014-01-29 21:44 ` Daniel Cegiełka
@ 2014-01-30 6:06 ` Rich Felker
2014-01-30 15:00 ` Anthony G. Basile
1 sibling, 1 reply; 6+ messages in thread
From: Rich Felker @ 2014-01-30 6:06 UTC (permalink / raw)
To: musl; +Cc: gentoo-embedded, gentoo-hardened
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: yet another alternative libc
2014-01-30 6:06 ` Rich Felker
@ 2014-01-30 15:00 ` Anthony G. Basile
2014-02-01 1:01 ` Rich Felker
0 siblings, 1 reply; 6+ messages in thread
From: Anthony G. Basile @ 2014-01-30 15:00 UTC (permalink / raw)
To: musl
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: yet another alternative libc
2014-01-30 15:00 ` Anthony G. Basile
@ 2014-02-01 1:01 ` Rich Felker
0 siblings, 0 replies; 6+ messages in thread
From: Rich Felker @ 2014-02-01 1:01 UTC (permalink / raw)
To: musl
On Thu, Jan 30, 2014 at 10:00:10AM -0500, Anthony G. Basile wrote:
> 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.
What happens when it fails? Crash or meaningful error message? I'd
very much like any reports of GCC failures since even if they seem to
be a result of your configuration, it might be that the configuration
is just uncovering a bug in musl that happened not to be hit in other
configurations. I can think of at least two such instances in the
past; one was a real, serious bug in musl and the other was musl's
qsort behaving in a perfectly conforming way that GCC did not expect
(calling the comparison function with the same element for both
arguments) and causing an assertion failure in GCC. I "fixed" the
latter anyway. :)
> >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?
Yes, it's the best place. Maybe post-1.0 we'll add a bug tracker but
we don't have one yet.
Rich
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-02-01 1:01 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-01-29 21:19 yet another alternative libc 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
2014-01-30 15:00 ` Anthony G. Basile
2014-02-01 1:01 ` Rich Felker
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).