[llvm-dev] A libc in LLVM

[Shawn Webb via llvm-dev]

On Tue, Jun 25, 2019 at 03:47:15PM -0700, Siva Chandra via llvm-dev wrote:
> On Mon, Jun 24, 2019 at 3:37 PM Jake Ehrlich <jakehehrlich at google.com>
> wrote:
> 
> > disclaimer: I work at Google so don't take my +1 as an independent vote
> > forward.
> >
> > We would like to use this on Fuchsia and I am particularly interested in
> > creating a dynamic linking library for ELF with Roland McGrath's guidance.
> > We spoke about creating a library for writing dynamic linkers internally
> > and I don't see why this can't be upstreamed.
> >
> 
> If dynamic linking support is added in a "as a library" fashion, so that it
> can easily be excluded if not required without affecting the rest of the
> system, I do not see any problems adding it.

It would be very cool to see an RTLD in llvm, especially one that
could support multiple formats, like ELF and LLVM IR. If I understand
llvm's Cross-DSO CFI support properly (which I may not), the entire
address space for a dlopen()ed DSO (as in, where the DSO was loaded in
memory) is added to the cfi-icall whitelist. An RTLD in llvm that can
intelligently integrate with the sanitizers to provide the same level
of granularity for dlopen()ed libraries as ELF::DT_NEEDED ones.

One could also complete the required SafeStack integration with the
RTLD, which requires bringing in the sanitizer framework, anyways.

A portable libc and RTLD provided by llvm that can make integral use
of the sanitizers, especially CFI and SafeStack, would be absolutely
lovely. If not done within llvm, HardenedBSD needs to do it, anyways,
in order to apply SafeStack and Cross-DSO CFI properly to both DSOs
and applications. If not done within llvm, HardenedBSD will simply
continue using and maintaining patches on top of the libc and RTLD
we inherit from our upstream FreeBSD.

Thanks,

-- 
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

Tor-ified Signal:    +1 443-546-8752
Tor+XMPP+OTR:        lattera at is.a.hacker.sx
GPG Key ID:          0xFF2E67A277F8E1FA
GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9  3633 C85B 0AF8 AB23 0FB2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190626/d0319763/attachment.sig>