Wednesday, 28 July 2010

Grsecurity, Firefox, MPROTECT and You!

Firefox is definitely one of this pieces of software where you want to have all of the available security options enabled :) And one of those features that you might REALLY want is MPROTECT (brought to you by the grsecurity ;)). Making long story short, it works by restricting the mprotect() system call which makes life of an attacker much more difficult because they cannot simply change protection of a specific memory region (mark it as executable if it wasn't originally executable) or create a new writeable&executable memory mapping using the mmap() call. Without this feature, all the 'non-executable memory regions' hype in your system is more or less useless, as the permission could be simply changed by the attacker. So far so good :)

However, you can notice that Gentoo by default disables this protection (without really telling user why!) as it usually wreaks havoc with flash and java plugins and sometimes the browser itself...but what if you don't really care about these and you do want to have this on? Well, it gets more interesting...historically, Firefox had issues with MROTECT every now and then, so how does it look like with the latest 3.6.8 release?

During the emerge process you can see this:

* Legacy EI PaX marking -m
* /var/tmp/portage/www-client/firefox-3.6.8/image///usr/lib64/mozilla-firefox/firefox
* PT PaX marking -m
* /var/tmp/portage/www-client/firefox-3.6.8/image///usr/lib64/mozilla-firefox/firefox

Which can be also confirmed by using the paxctl tool:

# paxctl -v /usr/lib64/mozilla-firefox/firefox
PaX control v0.5
Copyright 2004,2005,2006,2007 PaX Team

- PaX flags: -----m-x-e-- [/usr/lib64/mozilla-firefox/firefox]
MPROTECT is disabled
RANDEXEC is disabled
EMUTRAMP is disabled

Not really what we wanted...let's reset it! (you need to run this command as root)

# paxctl -z /usr/lib64/mozilla-firefox/firefox
# paxctl -v /usr/lib64/mozilla-firefox/firefox
PaX control v0.5
Copyright 2004,2005,2006,2007 PaX Team

- PaX flags: ------------ [/usr/lib64/mozilla-firefox/firefox]

That's better! Ok, but does it actually work?

$ firefox
Segmentation fault

Ooops...not good! So what's the problem? Last few lines of strace output show the answer:

mmap(NULL, 65536, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 EPERM (Operation not permitted)
mprotect(0xfffffffffffff000, 69632, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 ENOMEM (Cannot allocate memory)
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
unlink("/home/radegand/.mozilla/firefox/ekyjebvs.default/lock") = 0
rt_sigaction(SIGSEGV, {SIG_DFL, [], SA_RESTORER, 0x3434af56120}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [SEGV], NULL, 8) = 0
tgkill(26608, 26608, SIGSEGV) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Segmentation fault

The mmap() call above tries to create a writeable and executable memory mapping (which is not permitted by Grsecurity) which is followed by a call to mprotect() to set the same permission ('rwx'), which is also not then it segfaults...:)

Luckily, there's a workaround! From information gathered on IRC, the following two options would allow Firefox to run with the MPROTECT feature on:

user_pref("", false);
user_pref("javascript.options.jit.content", false);

They should be added in the prefs.js file located in the Firefox profile folder:


...and then Firefox will run happily ever after...or so one would hope... ;)

Of course you could disable MPROTECT, start Firefox, go to about:config and add the options above. But do you really want to run your browser without this protection, even just for few seconds? ;) Well, if JIT really needs 'rwx' pages, given for instance this issue, I'm not sure if I would... ;P

Ok, but what is the real cause of the problem? Let's see...unpack the source code and have a poke around - Gentoo ebuild system comes handy here:

# ebuild /usr/portage/www-client/firefox/firefox-3.6.8.ebuild unpack
# cd /var/tmp/portage/www-client/firefox-3.6.8/work/
work # grep -R -i PROT_EXEC *
mozilla-1.9.2/js/ctypes/libffi/src/closures.c: don't attempt PROT_EXEC|PROT_WRITE mapping at all, as that
mozilla-1.9.2/js/ctypes/libffi/src/closures.c: ptr = mmap (NULL, length, (prot & ~PROT_WRITE) | PROT_EXEC,
mozilla-1.9.2/js/ctypes/libffi/src/closures.c: ptr = mmap (start, length, prot | PROT_EXEC, flags, fd, offset);
mozilla-1.9.2/js/ctypes/libffi/src/closures.c: with ((prot & ~PROT_WRITE) | PROT_EXEC) and mremap with
mozilla-1.9.2/js/ctypes/libffi/testsuite/ page = mmap (NULL, size, PROT_READ | PROT_WRITE | PROT_EXEC,
mozilla-1.9.2/js/ctypes/libffi/testsuite/ page = mmap (NULL, size, PROT_READ | PROT_WRITE | PROT_EXEC,
mozilla-1.9.2/js/ctypes/libffi/testsuite/libffi.special/ffitestcxx.h: page = mmap (NULL, size, PROT_READ | PROT_WRITE | PROT_EXEC,
mozilla-1.9.2/js/ctypes/libffi/testsuite/libffi.special/ffitestcxx.h: page = mmap (NULL, size, PROT_READ | PROT_WRITE | PROT_EXEC,
mozilla-1.9.2/js/src/nanojit/avmplus.cpp: flags |= PROT_EXEC;
mozilla-1.9.2/js/src/nanojit/avmplus.cpp: PROT_READ | PROT_WRITE | PROT_EXEC,
mozilla-1.9.2/layout/base/tests/TestPoisonArea.cpp: return mprotect((caddr_t)page, PAGESIZE, PROT_READ|PROT_WRITE|PROT_EXEC);
mozilla-1.9.2/layout/base/tests/TestPoisonArea.cpp: // (mmap(PROT_EXEC) may fail when applied to anonymous memory.)
mozilla-1.9.2/nsprpub/lib/msgc/src/unixgc.c: addr = mmap(lastaddr, size, PROT_READ|PROT_WRITE|PROT_EXEC,
mozilla-1.9.2/nsprpub/lib/msgc/src/unixgc.c: addr = mmap(base + oldSize, allocSize, PROT_READ|PROT_WRITE|PROT_EXEC,
mozilla-1.9.2/nsprpub/pr/src/md/unix/nextstep.c: case PROT_EXEC: mach_prot = VM_PROT_EXECUTE; break;
mozilla-1.9.2/nsprpub/pr/src/md/unix/unix.c: prot |= PROT_EXEC;
mozilla-1.9.2/toolkit/crashreporter/google-breakpad/src/google_breakpad/common/minidump_exception_mac.h: /* EXC_I386_EXTOVRFLT = 9: mapped to EXC_BAD_ACCESS/(PROT_READ|PROT_EXEC) */

So here are your potential offenders...The next step would be to investigate the code further and try to remove the PROT_EXEC flag where it does not seem necessary, compile and test...believe it or not, it's sometimes much easier than it sounds!

...but more about it next time...

Wednesday, 28 April 2010

mplayer PIE on amd64 :)

For ages it was not possible to compile mplayer as Position Independent Executable (at least not on amd64) - until today! To my greatest surprise it compiled fine using the default gentoo hardened gcc spec, including PIE support.

So simply sync your portage tree, emerge mplayer-1.0_rc4_p20100427 and enjoy! Watching your favourite movie has never felt so safe before! ;]

./ --file /usr/bin/mplayer
Full RELRO Canary found NX enabled PIE enabled /usr/bin/mplayer

...or alternatively:

readelf -h /usr/bin/mplayer
ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: DYN (Shared object file)
Machine: Advanced Micro Devices X86-64
Version: 0x1
Entry point address: 0xcae48
Start of program headers: 64 (bytes into file)
Start of section headers: 9064016 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 10
Size of section headers: 64 (bytes)
Number of section headers: 27
Section header string table index: 26

Enjoy the PIE! ;]

Thursday, 15 April 2010

KVM setup with bridged networking

The other day I hat to run my virtual machines on the same network as the host system itself and as I found information on the net to be a bit confusing I thought I could share how I came to terms with it :)

As usual I've used the following information resources - both of which have different view on the networking setup... ;) They do, however, mention all the prerequisites which have to met in order for the networking to work. So I assume that you have emerged bridge-utils and that kernel support for TUN/TAP device driver, "802.1d Ethernet Bridging" and "802.1Q VLAN Support" is enabled.

If you've been using NATed networking before, you need to remove vde from your start-up script:

rc-update vde del default

In my case my host and my VMs were getting addresses via DHCP. You could use static addresses as well - just specify the addresses for each interface manually and remember to add line for default route (see the links above for some examples on this). So below is my /etc/conf.d/net file.

bridge_br0="eth0 tap0 tap1" config_eth0=( "null" )
config_br0=( "dhcp" )
brctl_br0=( "setfd 0" "sethello 0" "stp off" )
rc_need_br0=( "net.tap0" "net.tap1" "net.eth0" )

config_tap0=( "null ")
tunctl_tap0="-u radegand"
config_tap1=( "null ")
tunctl_tap1="-u radegand"

Ok, section by section...
The first section defines the bridge to be comprised of three interfaces: one physical (eth0) and two virtual (tap0 and tap1). It then specifies that no ip address is required for eth0, instead it specifies that interface br0 will obtain it ip settings via DHCP. It also specifies some bridge options and sets dependencies for the br0 so when the init.d script is executed it can handle these properly.

The next two sections define tap0 and tap1 interfaces. It specifies that no IP address is needed for each of them (VM will get the IP instead - more on it later), the device type, the user who will have access to that device - this should be the same user who would run the VM itself. Finally - a specific mac address (you can be creative here! ;)) needs to be assigned to each tap device. You need such a section for each VM that will use the bridged network and each of such virtual interface can be used by one VM only.

Ok, time two start the new shiny interfaces! ;) Make sure that you have all the required links to start them:

ln -s /etc/init.d/net.lo /etc/init.d/net.tap0
ln -s /etc/init.d/net.lo /etc/init.d/net.tap1
ln -s /etc/init.d/net.lo /etc/init.d/net.br0

...and start them of course!:

/etc/init.d/net.tap0 start
/etc/init.d/net.tap1 start
/etc/init.d/net.br0 start

Remember to add them to a relevant boot level using rc-update when everything is tested and working fine...

Rite, now the interfaces should be up and ready to test! Let's see...

# ifconfig
br0 Link encap:Ethernet HWaddr 00:aa:bb:cc:dd:ee
inet addr: Bcast: Mask:
RX packets:201 errors:0 dropped:0 overruns:0 frame:0
TX packets:150 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:16269 (15.8 KiB) TX bytes:38080 (37.1 KiB)

eth0 Link encap:Ethernet HWaddr 00:aa:bb:cc:dd:ee
RX packets:202 errors:0 dropped:0 overruns:0 frame:0
TX packets:157 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:20135 (19.6 KiB) TX bytes:39152 (38.2 KiB)

tap0 Link encap:Ethernet HWaddr 00:a0:b0:c0:d0:f0
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:21 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

tap1 Link encap:Ethernet HWaddr 00:a1:b1:c1:d1:f1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:21 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

Note that the mac address of the br0 is the same as eth0 (yes, I did amended them a bit here, they're not my real mac addresses but they DO match nevertheless...)

Time to start VMs! So the magic command that needs to be added to the qemu/kvm command line which will get you bridged network is...:

-net tap,ifname=tap0,script=no,downscript=no -net nic,macaddr=00:a0:b0:c0:d0:f1

Now, the important bits are highlighted - for each of your VMs you need to use separate tap interface. Moreover, you need to specify mac address for the VM and it has to be different that the one specified for given tap interface in /etc/conf.d/net file. Of course it can be entirely different, not only by last byte - I just keep it this way to keep track of my VMs...But don't take my world for that - try using the same mac address for your VM as you set for the tap interface...and then when your VM is up and running grep the /var/log/kern.log file on your host system for:

tap0: received packet with own address as source address

So for each VM you run use different tap interface and remember to set different mac address than the tap device itself...

Ok, now you should have KVM setup up with bridged additional setup is need - no need for specific iptables rules and you don't even need to have the ip forwarding (/proc/sys/net/ipv4/ip_forward) enabled for it to work! Now - how cool is that? ;)

PS. No - it won't work with wireless, only with ethernet...if you need a wireless bridge - have a look here.

Saturday, 13 March 2010

New paxtest 0.9.9

New paxtest has been recently released! ...along with the new hardened-sources-2.6.33 ebuild (testing from the hardened-development overlay). This had to be tested! ;]

Although paxtest ebuild itself has not been updated yet, you can compile it from source or update ebuild in your local repository..

Anyway - results below:

# paxtest blackhat
PaXtest - Copyright(c) 2003,2004 by Peter Busser
Released under the GNU Public Licence version 2 or later

Writing output to paxtest.log
It may take a while for the tests to complete
Test results:
PaXtest - Copyright(c) 2003,2004 by Peter Busser
Released under the GNU Public Licence version 2 or later

Mode: blackhat
Linux quad 2.6.33-hardened #1 SMP Sat Mar 13 10:00:54 GMT 2010 x86_64 Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz GenuineIntel GNU/Linux

Executable anonymous mapping : Killed
Executable bss : Killed
Executable data : Killed
Executable heap : Killed
Executable stack : Killed
Executable shared library bss : Killed
Executable shared library data : Killed
Executable anonymous mapping (mprotect) : Killed
Executable bss (mprotect) : Killed
Executable data (mprotect) : Killed
Executable heap (mprotect) : Killed
Executable stack (mprotect) : Killed
Executable shared library bss (mprotect) : Killed
Executable shared library data (mprotect): Killed
Writable text segments : Killed
Anonymous mapping randomisation test : 33 bits (guessed)
Heap randomisation test (ET_EXEC) : 40 bits (guessed)
Heap randomisation test (PIE) : 40 bits (guessed)
Main executable randomisation (ET_EXEC) : 32 bits (guessed)
Main executable randomisation (PIE) : 32 bits (guessed)
Shared library randomisation test : 33 bits (guessed)
Stack randomisation test (SEGMEXEC) : 40 bits (guessed)
Stack randomisation test (PAGEEXEC) : 40 bits (guessed)
Return to function (strcpy) : paxtest: return address contains a NULL byte.
Return to function (memcpy) : Vulnerable
Return to function (strcpy, PIE) : paxtest: return address contains a NULL byte.
Return to function (memcpy, PIE) : Vulnerable

Return to function is the key! ;]

Sunday, 14 February 2010

Gcc-4.4.3 on Gentoo Hardened

Freshly released version of gcc-4.4.3 is now available on gentoo hardened! ;] As usually, it is available via the hardened-development overlay. Thanks guys!

# gcc-config -l
[1] x86_64-pc-linux-gnu-3.4.6
[2] x86_64-pc-linux-gnu-3.4.6-hardenednopie
[3] x86_64-pc-linux-gnu-3.4.6-hardenednopiessp
[4] x86_64-pc-linux-gnu-3.4.6-hardenednossp
[5] x86_64-pc-linux-gnu-3.4.6-vanilla
[6] x86_64-pc-linux-gnu-4.4.3 *
[7] x86_64-pc-linux-gnu-4.4.3-hardenednopie
[8] x86_64-pc-linux-gnu-4.4.3-hardenednossp
[9] x86_64-pc-linux-gnu-4.4.3-vanilla

Tuesday, 9 February 2010

Installing Pentoo on Hard Drive with LUKS encryption

Pentoo is a great Linux distro created with security testing in mind - be it a penetration testing or wireless testing. I know - Backtrack 4 is out there and is cool too ;P however, being a Gentoo user you simply cannot resist Pentoo... ;) It might be just me but I find it so much easier to customise as well! And how many times you had to install something from source? And then getting all the header files and tricky dependencies right can be cumbersome...with Pentoo - you have the full Gentoo portage tree plus lots of security tools available as ebuilds at hand. If something's not there - it's so god damn easy to...compile it! ;]

Anyway - here's a quick howto how to get Pentoo installed on your hard drive with LUKS encrypted root partition and encrypted swap, too... LiveCD is great, but you might want to have something more permanent and here it goes!

Installation guides that I've used for reference:
and here:

Boot the LiveCD and check that networking is fine and that sshd is running (you don't necessarily need networking at this stage but I prefer to do the installation remotely). Also change root password:

dhcpcd eth0
/etc/init.d/sshd start

Create installation partitions. You'll at least need /boot, / (root), and swap. My setup was as follows:

pentoo ~ # fdisk -l

Disk /dev/sda: 60.0 GB, 60011642880 bytes
16 heads, 63 sectors/track, 116280 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes
Disk identifier: 0x6ce2c029

Device Boot Start End Blocks Id System
/dev/sda1 1 195 98248+ 83 Linux
/dev/sda2 196 4071 1953504 83 Linux
/dev/sda3 4072 116280 56553336 83 Linux

sda1 - boot
sda2 - swap
sda3 - root

Onto encrypted partition creation... ;) You can of course tune the encryption options (see the cryptsetup manpage)

pentoo ~ # cryptsetup --verbose --cipher "aes-cbc-essiv:sha256" --key-size 256 --verify-passphrase luksFormat /dev/sda3

This will overwrite data on /dev/sda3 irrevocably.

Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase:
Verify passphrase:
Command successful.

Now open the encrypted partition and create the mapping needed for installation:

pentoo ~ # cryptsetup luksOpen /dev/sda3 root
Enter passphrase for /dev/sda3:
Key slot 0 unlocked.

Create filesystems on newly created partitions. Feel free to use your favourite filesystem - just beware with /boot partition as, for instance, grub doesn't really work with ext4...

pentoo ~ # mkfs.ext3 /dev/sda1
mke2fs 1.41.9 (22-Aug-2009)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
24576 inodes, 98248 blocks
4912 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=67371008
12 block groups
8192 blocks per group, 8192 fragments per group
2048 inodes per group
Superblock backups stored on blocks:
8193, 24577, 40961, 57345, 73729

Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 33 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.

And the root partition to follow:

pentoo ~ # mkfs.ext3 /dev/mapper/root
mke2fs 1.41.9 (22-Aug-2009)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
3538944 inodes, 14138077 blocks
706903 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
432 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424

Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 37 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.

Mount partitions...

pentoo ~ # mount /dev/mapper/root /mnt/gentoo/
pentoo ~ # mkdir /mnt/gentoo/boot
pentoo ~ # mount /dev/sda1 /mnt/gentoo/boot/

Don't worry about swap partition - we'll encrypt it later.

Now we need to copy files form LiveCD onto the hard drive. As there will be some overwriting happening, it's useful to unalias the cp command first:

pentoo ~ # alias
alias aemerge='ACCEPT_KEYWORDS="~x86" emerge'
alias cp='cp -i'
alias grep='grep --color=auto'
alias ll='ls -l'
alias ls='ls --color'
alias mv='mv -i'
alias rm='rm -i'

Unalias then!

unalias cp

...and then start copying the files:

cp -avf /mnt/livecd/* /mnt/gentoo
cp -avf /etc /root /mnt/gentoo
cp -avf /usr/portage /mnt/gentoo/usr

From there on it's pretty much a straight forward Gentoo installation - all tweaks allowed! ;]

pentoo ~ # mount -t proc none /mnt/gentoo/proc
pentoo ~ # mount -o bind /dev /mnt/gentoo/dev
pentoo ~ # chroot /mnt/gentoo /bin/bash
pentoo / # env-update
>>> Regenerating /etc/
pentoo / # source /etc/profile
pentoo / # export PS1="(chroot) $PS1"

Just out of curiosity:

(chroot) pentoo src # gcc-config -l
[1] i686-pc-linux-gnu-4.3.4 *
(chroot) pentoo src # eselect profile list
Available profile symlink targets:
[1] default/linux/x86/10.0 *
[2] default/linux/x86/10.0/desktop
[3] default/linux/x86/10.0/developer
[4] default/linux/x86/10.0/server
[5] hardened/linux/x86/10.0
[6] selinux/2007.0/x86
[7] selinux/2007.0/x86/hardened
[8] selinux/v2refpolicy/x86
[9] selinux/v2refpolicy/x86/desktop
[10] selinux/v2refpolicy/x86/developer
[11] selinux/v2refpolicy/x86/hardened
[12] selinux/v2refpolicy/x86/server

Not bad! You could always switch to the hardened profile, enable the graphite extension and recompile world... ;)

Anyway - kernel compilation! I'd use a hardened-sources from the hardened-development overlay (you'll need to emerge git for that) but you can as well just stay with the stock kernel...

(chroot) pentoo src # ls -la
total 20
drwxr-xr-x 5 root root 4096 Jan 22 13:55 .
drwxr-xr-x 16 root root 4096 Dec 3 23:31 ..
lrwxrwxrwx 1 root root 31 Dec 3 23:30 linux -> /usr/src/linux-2.6.31-pentoo-r3
drwxr-xr-x 24 root root 4096 Dec 3 23:30 linux-2.6.31-pentoo-r3
drwxr-xr-x 24 root root 4096 Jan 22 13:56 linux-2.6.32-hardened-r2
drwxr-xr-x 12 root root 4096 Dec 3 21:39 mosref-2.0_beta3

The easiest way to get the kernel config file:

(chroot) pentoo src # zcat /proc/config.gz > /usr/src/linux/.config

And then you can modify it or leave it alone... :)

Edit /etc/genkernel.conf. Not really required but I like to disable clean and mrproper and add LUKS line:

# Run 'make mrproper' before configuration/compilation?

For multicore you could also add there (number of cores+1):


Compile! Well, not yet...if you run genkernel now it will fail with:

ld: cannot find -lcrypt

rebuilding genkernel did not help about rebuilding glibc?

(chroot) pentoo linux # emerge -av glibc
* IMPORTANT: 2 news items need reading for repository 'gentoo'.
* Use eselect news to read news items.
These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild U ] sys-libs/glibc-2.10.1-r1 [2.9_p20081201-r2] USE="-debug -gd -glibc-omitfp (-hardened) (-multilib) -nls -profile (-selinux) -vanilla" 16,511 kB

Total: 1 package (1 upgrade), Size of downloads: 16,511 kB
Would you like to merge these packages? [Yes/No]

Once it's done (few cups of chai later...)

(chroot) pentoo linux # genkernel --luks all
* Gentoo Linux Genkernel; Version 3.4.10
* Running with options: --luks all

* Linux Kernel 2.6.31-pentoo-r3 for x86...
* >> Running oldconfig...
* config: --no-clean is enabled; leaving the .config alone.
* >> Compiling 2.6.31-pentoo-r3 bzImage...
* >> Compiling 2.6.31-pentoo-r3 modules...
* Copying config for successful build to /etc/kernels/kernel-config-x86-2.6.31-pentoo-r3
* busybox: >> Applying patches...
* busybox: >> Configuring...
* busybox: >> Compiling...
* busybox: >> Copying to cache...
* initramfs: >> Initializing...
* >> Appending base_layout cpio data...
* >> Appending auxilary cpio data...
* Including LUKS support
* >> Appending busybox cpio data...
* >> Appending e2fsprogs cpio data...
* E2FSPROGS: Adding support (compiling binaries)...
* e2fsprogs: >> Configuring...
* e2fsprogs: >> Compiling libs...
* e2fsprogs: >> Compiling e2fsck...
* e2fsprogs: >> Compiling mke2fs...
* e2fsprogs: >> Copying to cache...
* >> Copying to bincache...
* >> Appending modules cpio data...
* Kernel compiled successfully!
* Required Kernel Parameters:
* real_root=/dev/$ROOT
* Where $ROOT is the device node for your root partition as the
* one specified in /etc/fstab
* If you require Genkernel's hardware detection features; you MUST
* tell your bootloader to use the provided INITRAMFS file. Otherwise;
* substitute the root argument for the real_root argument if you are
* not planning to use the initrd...

* Additional kernel cmdline arguments that *may* be required to boot properly...

* Do NOT report kernel bugs as genkernel bugs unless your bug
* is about the default genkernel configuration...
* Make sure you have the latest genkernel before reporting bugs.
(chroot) pentoo linux #


Edit the /etc/fstab file:

/dev/sda1 /boot ext3 noauto,noatime 1 2
/dev/mapper/root / ext3 noatime 0 1
/dev/mapper/crypt-swap none swap sw 0 0

Ok, time to create LUKS mappings:

vi /etc/conf.d/dmcrypt

...and add your swap partition:


Now the bootloader:

nano /boot/grub/menu.lst

If you've installed the stock kernel that's how it should look like:

title Pentoo Linux 2.6.31-r3
root (hd0,0)
kernel /boot/kernel-genkernel-x86-2.6.31-pentoo-r3 crypt_root=/dev/sda3 real_root=/dev/mapper/root
initrd /boot/initramfs-genkernel-x86-2.6.31-pentoo-r3

Rite - unfortunately we now need to install new config file manually - run grub:

GNU GRUB version 0.97 (640K lower / 3072K upper memory)

[ Minimal BASH-like line editing is supported. For the first word, TAB
lists possible command completions. Anywhere else TAB lists the possible
completions of a device/filename. ]

grub> root (hd0)
Filesystem type unknown, using whole disk

grub> root (hd0,0)
Filesystem type is ext2fs, partition type 0x83

grub> setup (hd0)
Checking if "/boot/grub/stage1" exists... yes
Checking if "/boot/grub/stage2" exists... yes
Checking if "/boot/grub/e2fs_stage1_5" exists... yes
Running "embed /boot/grub/e2fs_stage1_5 (hd0)"... 17 sectors are embedded.
Running "install /boot/grub/stage1 (hd0) (hd0)1+17 p (hd0,0)/boot/grub/stage2 /boot/grub/menu.lst"... s


Voila! Few boot script tweaks...

(chroot) pentoo linux # rc-update del autoconfig default
* service autoconfig removed from runlevel default
(chroot) pentoo linux # rc-update add keymaps default
* service keymaps added to runlevel default
(chroot) pentoo linux #rc-update add dmcrypt boot
* service dmcrypt added to runlevel default

Edit the keymap file if you wish...

nano /etc/conf.d/keymaps

Done...reboot & enjoy! ;]

Saturday, 23 January 2010

Nouveau driver with KMS support on Hardened

I got annoyed recently with the nv driver and still not being able to use the proprietary nvidia driver I decided to try nouveau driver...and it worked! :) Additional bonus was - KMS - fast switching between X and console...finally!

Ok, here we go. A recent kernel will be needed, I'm using the 2.6.32 hardened sources, but anything >= 2.6.31 should do. xorg-server-1.7 will be required though. So before you try, make sure that you have it up and running and that everything works as it should - I had some non obvious dependencies to solve...anyway!

There's a installation guide provided which helps a lot ;]

Make sure that your kernel have debugfs support compiled (in "Kernel Hacking" enable "Debug Filesystem") and I also had to enable UVESA option ( "Device drivers" -> "Graphics support" -> "Support for framebuffer devices" -> "Userspace VESA VGA support"). Recompile and reboot to your new kernel.

Disable the proprietary module if you were using it (unlikely on hardened! ;P). As per guide switch opengl to X11:

# eselect opengl set xorg-x11
Switching to xorg-x11 OpenGL interface... done

Make sure you have USE="dri" and VIDEO_CARDS="nouveau" set in make.conf. Try emerging this (You'll probably need to keyword and unmask these ebuilds):

# emerge -va nouveau-drm libdrm xorg-server xf86-video-nouveau

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild N ] x11-drivers/nouveau-firmware-20091212 0 kB [1]
[ebuild N ] x11-libs/libdrm-9999 USE="-static-libs" 0 kB [1]
[ebuild N ] x11-base/nouveau-drm-99999999 0 kB [1]
[ebuild R ] x11-base/xorg-server-1.7.4 USE="hal ipv6 nptl sdl xorg -debug -dmx -kdrive -minimal -tslib" 0 kB [0]
[ebuild N ] x11-drivers/xf86-video-nouveau-9999 USE="-static-libs" 0 kB [1]

Total: 5 packages (4 new, 1 reinstall), Size of downloads: 0 kB
Portage tree and overlays:
[0] /usr/portage
[1] /usr/local/portage/layman/x11

Would you like to merge these packages? [Yes/No]

This should look similar to this above. Pay attention to packages that need to be pulled from the x11 overlay rather than portage tree.

Once everything is compiled, change the xorg.conf to use new driver - replace:

Driver "nv"


Driver "nouveau"

Enable relevant modules to be loaded during boot. The /etc/conf.d/modules should something like this:

modules_2_6="dri nouveau"

Do not modprobe the nouveau driver from within X! It will kill it... ;] Stop X, modprobe and start X again...or simply reboot...end enjoy the new driver and KMS!