[llvm-dev] A libc in LLVM

[Shawn Webb via llvm-dev]

Hey Siva,

HardenedBSD is a derivative of FreeBSD that aims to perform a
clean-room reimplementation of the publicly-documented bits of the
grsecurity patchset. We're extremely interested in llvm's CFI to fill
the gap of PaX's/grsecurity's patented/GPLv3'd excellent RAP
implementation. We've made measurable and tangible progress in
researching and integrating Cross-DSO CFI (even producing a pre-alpha
Call-For-Testing of Cross-DSO CFI in HardenedBSD base).

One hard problem I need to solve is tight integration of the sanitizer
library into both our libc and our RTLD while also attempting to keep
diffs minimal with our upstream FreeBSD.

Having a libc that was sanitizer-centric (or, at least, aware) and
could serve as a drop-in replacement for our libc would be a major
win and would even enable quicker development of novel security
technologies in the future.

On Mon, Jun 24, 2019 at 03:23:20PM -0700, Siva Chandra via llvm-dev wrote:
> Hello LLVM Developers,
> 
> Within Google, we have a growing range of needs that existing libc
> implementations don't quite address. This is pushing us to start working on
> a new libc implementation.
> 
> Informal conversations with others within the LLVM community has told us
> that a libc in LLVM is actually a broader need, and we are increasingly
> consolidating our toolchains around LLVM. Hence, we wanted to see if the
> LLVM project would be interested in us developing this upstream as part of
> the project.
> 
> To be very clear: we don't expect our needs to exactly match everyone
> else's -- part of our impetus is to simplify things wherever we can, and
> that may not quite match what others want in a libc. That said, we do
> believe that the effort will still be directly beneficial and usable for
> the broader LLVM community, and may serve as a starting point for others in
> the community to flesh out an increasingly complete set of libc
> functionality.
> 
> We are still in the early stages, but we do have some high-level goals and
> guiding principles of the initial scope we are interested in pursuing:
> 
> 
>    1.
> 
>    The project should mesh with the "as a library" philosophy of the LLVM
>    project: even though "the C Standard Library" is nominally "a library,"
>    most implementations are, in practice, quite monolithic.
>    2.
> 
>    The libc should support static non-PIE and static-PIE linking. This
>    means, providing the CRT (the C runtime) and a PIE loader for static
>    non-PIE and static-PIE linked executables.

Having a portable, permissively-licensed CSU/CRT that supports static
PIE would be a very welcomed project, especially if HardenedBSD could
make use of it.

>    3.
> 
>    If there is a specification, we should follow it. The scope that we need
>    includes most of the C Standard Library; POSIX additions; and some
>    necessary, system-specific extensions. This does not mean we should (or
>    can) follow the entire specification -- there will be some parts which
>    simply aren't worth implementing, and some parts which cannot be safely
>    used in modern coding practice.
>    4.
> 
>    Vendor extensions must be considered very carefully, and only admitted
>    when necessary. Similar to Clang and libc++, it does seem inevitable that
>    we will need to provide some level of compatibility with other vendors'
>    extensions.
>    5.
> 
>    The project should be an exemplar of developing with LLVM tooling. Two
>    examples are fuzz testing from the start, and sanitizer-supported testing.
> 
> 
> There are also few areas which we do not intend to invest in at this point:
> 
> 
>    1.
> 
>    Implement dynamic loading and linking support.

That is correct. Implementing a runtime linker (RTLD) is orthogonal.
However, it seems to be the next logical (and welcomed!) step. Not
within scope of a libc implementation, though.

>    2.
> 
>    Support for more architectures (we'll start with just x86-64 for
>    simplicity).
> 
> 
> For these areas, the community is of course free to contribute. Our hope is
> that, preserving the "as a library" design philosophy will make such
> extensions easy, and allow retaining the simplicity when these features
> aren't needed.
> 
> We intend to build the new libc in a gradual manner. To begin with,  the
> new libc will be a layer sitting between the application and the system
> libc. Eventually, when the implementation is sufficiently complete, it will
> be able to replace the system libc at least for some use cases and contexts.
> 
> So, what do you think about incorporating this new libc under the LLVM
> project?

Even if the new libc isn't merged into llvm, it would be very
interesting to collaborate on. I would hope that Google would remain
interested in keeping in open sourced, and perhaps maintained in a
fashion that multiple OS vendors can adopt.

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/20190624/be5a96cf/attachment.sig>