Mission impossible: Hardening the x86 based core infrastructures

“Once upon a time, hackers lives in a world with full of libre/free software/firmware/hardware”…oh, wait, it’s not happened yet. Not sure if we can make it happen. It’s totally depends on the decision we make today. Some people might think we are already lost our freedom on x86. Because there are a bunch of shitty binary blobs during the boot/runtime( Who’s gonna watching the watchers?) process in x86, e.g: GBE( no big deal?), CPU microcode( Do we really believe the vendor don’t leave a backdoor there? Ok, it’s unlikely to happen because the “magic” constant shit is not hard to find but…possibility is still there?), VGA BIOS( the 1st rule of OptionROM is do not talk about-_-), MRC( lacking of effort to do the reversing?), Intel ME( red alert….). We may have chance to build the libre/free core infrastructure( SW/FW/HW) on ARMv8 in the near future or wait for RISC-V for another decade? I don’t know the answer. But I do know is there are huge number of desktop, server and embedded devices( did I fuc*ing say IoT shit?) running on x86, which need to be hardened. We’ve been trying hard to build the hardening solution by free/libre software/firmware for x86. Maybe we( who’s fuc* we?) still need to try harder 2 be ourselves….

Free software community has been facing the big threats from firmware level for a long time. Those free software implementation of firmware, such as Libreboot/Coreboot is still hard to apply to diverse x86 hardware. The situation we have isn’t optimistic according to the threat model.

Threat model

We’ve been losing software freedom because ME, which is the most powerful demon from Ring -3 world. Since it’s more likely an invincible enemy even Intel haven’t disable SPI by adding a similar feature into the same physical package of processor( because it’d be harmful to OEM’s interest?) yet and we’d still have some chances( illusion?) to build our defense for Ring -2 and above world. We are going to make UEFI Secure Boot, bootloader( Grub2), linux kernel and kernel modules on the chain of trust by signing/verify at each level. There are less than 5% of machines( let’s say 100 servers…damn, how long can we neutralize the ME for 100 machines and finish the bunch of regression test due to reduce the risk of business impact) are running critical/important production systems. We should do the hardening by its situation.

trade-off

Demon from RING -3: a parallel world along side of x86

Do you really understand what/why we’re doing( is wrong?) all of this to protect our digital asset and privacy( is not a joke today?). Fortunately, we’re getting closer to the current goal. First thing first, Intel ME can’t be 100% disabled but we can restrict the power of Intel ME by minizing its functions. Plz follow the instruction. We’ve been testing on some machines and me_cleaner is done well. Hope more free software hackers and security research will join us to tearing Intel ME apart. Btw, hope AMD will be more friendly to FLOSS community?

Secure Boot and bootloaders( Grub2?)

Signed kernel?

The signature signing has been integrated with reproducible builds for PaX/Grsecurity. Reproducible build is good and you can see how it work. The only side-effect we found is signed kernel image produced by reproducible builds won’t be identical. It won’t affect other files. It doesn’t matter if your build system is not being compromised in the 1st place;-)

Why PaX/Grsecurity?

Due to most packages on Debain 9 can be reproducible, why do we still need to reproducible builds by ourselves? KSPP is good starting point but far away from our hardening criteria. On non-technical( political?) side, KSPP is just a new business model to Linux foundation. They have done nothing but a bunch of PR craps and trying to take the credits makes me feel sick. PaX/Grsecurity is the origins of kernel mitigation and it’s still the strongest mitigation since 2001. Just like someone( I won’t reveal your identity;-)) said that both mitigation and isolation are different beasts. We need them both but the 1st priority to us should be the 1st one. You might find anwsers in Linux kernel mitigation checklist.

Signing Kernel Module

Generating a private key/certificate for signing kernel modules

# ./gen-x509-key.sh sha512 hardenedlinux.x509 hardenedlinux.pk
# cat hardenedlinux.x509 >> hardenedlinux.pk
# cp hardenedlinux.x509 hardenedlinux.pk /kbuild/

Those out-of-tree kernel module can be signed by the private key/certificate manually:

# ./kernel-src/scripts/sign-file sha512 /kbuild/hardenedlinux.pk /kbuild/hardenedlinux.x509 test.ko

# hexdump -C test.ko | tail

0002bb10  11 3f 49 cc f6 5c 82 89  4b e7 2e 89 e4 89 33 11  |.?I..\..K.....3.|
0002bb20  a4 9e 78 cf 4c 44 71 20  b8 07 de cc 2e ed 33 82  |..x.LDq ......3.|
0002bb30  98 65 6b 74 8b 0e ed 01  4f ad ec b4 0c 67 5b e7  |.ekt....O....g[.|
0002bb40  a9 76 91 35 8b 10 4d 7c  3b 4a 11 39 0b c8 79 db  |.v.5..M|;J.9..y.|
0002bb50  43 d6 12 72 68 58 37 4f  40 1a 39 81 6b 10 90 c7  |C..rhX7O@.9.k...|
0002bb60  e6 54 72 29 3c a3 67 47  53 45 44 c4 c0 3d c6 00  |.Tr)<.gGSED..=..|
0002bb70  00 02 00 00 00 00 00 00  00 02 d7 7e 4d 6f 64 75  |...........~Modu|
0002bb80  6c 65 20 73 69 67 6e 61  74 75 72 65 20 61 70 70  |le signature app|
0002bb90  65 6e 64 65 64 7e 0a                              |ended~.|
0002bb97