Mission impossible: Hardening the x86 based core infrastructures

By citypw

rings

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.