Welcome to Kevquinn's dev overlay

This is actually a set of separate overlays. Each separate area of development has a separate overlay structure as a subdirectory of the workspace. The biggest reason for this is that these development overlays include eclass modifications, and it is easier to sync to a separate overlay than it is to deal with unwanted modified eclasses.

Disclaimer: 

These are development overlays, may not always build sensibly.
If you have any trouble, email me directly at kevquinn@gentoo.org.
Do not expect any help from anyone else!

Hardened development

Hardened Modular Xorg

svn checkout http://overlays.gentoo.org/svn/dev/kevquinn/hardened/xorg

The intention is to develop Modular Xorg to a level that no longer compromises Hardened Gentoo features. So far, it is limited to just PaX/GRsecurity/Toolchain issues, but may be widened in scope later.
Note that the ebuilds in portage currently just relax the Hardened Gentoo features they need to in order to work without change.

  • x11-base/xorg-server

Fully BIND_NOW: libglx NEEDED libGLcore, libdri made a dynamic dependency on libglx

  • x11-drivers/xf86-video-ati

Fully BIND_NOW: Made dependencies of main driver on submodules dynamic.

  • x11-drivers/xf86-video-cirrus

Fully BIND_NOW: Made dependencies of main driver on submodules dynamic.

  • media-libs/mesa

Eliminate TEXTRELs, which fail on PAX_NOELFRELOCS hardened kernels in particular.
Work in progress to re-enable all asm apart from the gl-dispatch table (which is run-time generated code).

To use this it is necessary to manually load the various X modules in xorg.conf. I may try to set the relevant NEEDED entries everywhere to eliminate this in the future, but no promises :) Some example pieces for xorg.conf:

  • general 
    Load "record"
    Load "extmod"
    Load "dbe"
    Load "drm"
    Load "dri"
    Load "glx"
    Load "xtrap"
    Load "freetype"
    Load "type1"
  • vesa 
    Load    "int10"
    Load    "i2c"
    Load    "ddc"
    Load    "vbe"
    Load    "fb"
    Load    "shadow"
    Load    "xf1bpp"
    Load    "xf4bpp"
  • ati 
    Load    "fbdevhw"
    Load    "xaa"
    Load    "fb"
    Load    "exa"
    Load    "int10"
    Load    "vgahw"
    Load    "i2c"
    Load    "ddc"
    Load    "ramdac"
    Load    "vbe"
    Load    "shadowfb"

Hardened GCC-4 toolchain development

svn checkout http://overlays.gentoo.org/svn/dev/kevquinn/hardened/toolchain

This repository is now structured with just branches. There's no real trunk as such, and there are no tags (as yet). The current favoured branch is pieworld.

Note that this toolchain overlay is under active development - it'll go into the main tree once it has stabilised; in the meantime expect to have to rebuild everything later if you use it. It is currently really for early testing - using it in anything other than a development chroot would be foolish.

Modifications include:

  • gcc
    Experimental minispecs implementation available. GCC hardening now done exclusively in additional specs files (the "minispecs"); builtin specs are (effectively) unchanged. See bug #149649.
  • glibc
    Provides a stronger stack_chk_fail() implementation. Building glibc itself with SSP switched on turns out to be non-trivial, so for the moment glibc itself is built with SSP switched off. See bug #94325.
  • eselect-compiler
    Experimental tweaks to manage specs and ccache more reliably. You don't need this to use the gcc/glibc above.

You'll find the piepatches tarballs in the distfiles subdirectory of the branch. Check the toolchain.README in each branch for notes.

Branches are:

* pieworld

Creates a system where essentially everything that isn't a shared library, is built -fPIE (for position independent executables). The resulting system can't be used easily to built pure vanilla stuff - simplest to use a vanilla chroot for that. However the system is consistent, and reliably builds hardened stuff in normal circumstances. Note that "static" binaries work; although they contain position independent code they are loaded at a fixed address, they are standalone, and execute fine.

* gcc-glibc-nopie

GCC and GLIBC themselves are built non-PIE. Static libraries from these are built non-PIE. This makes it easy to build pure vanilla stuff - except when linking to static archives from other packages (which are built -fPIE)

* pie-abi

Very experimental, and only just started, to create a pseudo-multilib setup separating PIE from normal builds (annotated PFE for Position Fixed Executable). This is envisaged to create (e.g.) /libpie /libpfe instead of /lib, in the same way that multilib system operate. On existing multilib systems it would create /lib32pie /lib64pie /lib32pfe /lib64pfe and so on. It would also need native multilib support in portage; possibly something along the lines of kanaka's stuff.

The concept is to retain the toolchain closer to upstream (like gcc-glibc-nopie) but to provide static libraries in both -fPIE and -fno-PIE forms so that all linking variations are possible.

In the end, this is probably a bad idea - the rest of the toolchain doesn't really cope with anything other than 32/64 bit multilib - in particular the ELF file format and toolchain don't seem to provide scope for handling the loading of ABIs other than 32bit vs 64bit, so it could become a bit of a mess.

In practice, it'll be much easier just to have pieworld, and use a chroot for non-PIE builds that really need non-PIE libraries.