TRESOR or QUBES don't protect from compromised bootloader/BIOS. coreboot does (and I'm working on it for that reason).
But you can't use current generation Intel CPUs as devised by the GP since those (or rather their chipsets) come with embedded controllers (running updateable code signed by someone else) with way too much access to the hardware to be trustworthy.
To protect against malicious PCI devices use an IOMMU set up early (eg. while still running code from flash)
There are also facilities against hardware keyloggers, but with today's hardware integration, that's mostly a matter of physically locking down the notebook chassis.
For servers, a lot of these vectors go away, and if you're theoretically deploying 10k servers, you can spec the controllers, microcode, etc.
I gave up on PC desktops for security a long time ago; just use mobile, tablets, and things like ChromeOS for that. ARM with TrustZones should be enough to fairly easily build something.
What I'd really like is a physically tamper-responding tablet. i.e. the touchscreen, physical enclosure, and all ports sealed in an HSM-like enclosure, such that if you tamper with it, it zeroizes a platform security key, which can be used to remotely attest "I haven't been tampered yet" to servers before communicating. You would then do some kind of physical enclosure size/seals/standards to protect from skimmers layered outside the trusted device, and then some kind of device to user authentication to prove it's a valid device before entering information on it. You could pretty much build this on Android today.
Access to specifications and access to the hardware.
For coreboot, the hard bit is chipset support. With full specs, a device to work on, and having lowlevel coding experience (not necessarily coreboot), this is an effort of 3-6 months (depends on specs, on how complex the hardware is, and a bit of luck).
Once a chipset is supported, adding more boards is relatively easy.
The main issue is that specs are generally under NDA. It varies by vendor how hard it is to obtain: nVidia is near impossible (the nVidia support we have was sheer luck), Intel rather wants to see us go away (or so it seems), Via can be coerced to give specs to individuals, AMD provides code and specs.
For servers, there's the additional complication of LOM - I'm not sure how hard that would be to support, and I guess vendors vary wildly in how they hook that up to the system.
About Intel E5: We have sandybridge support (contributed by the chromebook team), but I don't know how much Intel changed between the consumer sandybridge and the Xeon stuff. It's also harder to adapt since it uses Intel's reference code as binary component (probably the best they could get out of them).
Comments
TRESOR or QUBES don't protect from compromised bootloader/BIOS. coreboot does (and I'm working on it for that reason).
But you can't use current generation Intel CPUs as devised by the GP since those (or rather their chipsets) come with embedded controllers (running updateable code signed by someone else) with way too much access to the hardware to be trustworthy.
To protect against malicious PCI devices use an IOMMU set up early (eg. while still running code from flash)
There are also facilities against hardware keyloggers, but with today's hardware integration, that's mostly a matter of physically locking down the notebook chassis.
For servers, a lot of these vectors go away, and if you're theoretically deploying 10k servers, you can spec the controllers, microcode, etc.
I gave up on PC desktops for security a long time ago; just use mobile, tablets, and things like ChromeOS for that. ARM with TrustZones should be enough to fairly easily build something.
What I'd really like is a physically tamper-responding tablet. i.e. the touchscreen, physical enclosure, and all ports sealed in an HSM-like enclosure, such that if you tamper with it, it zeroizes a platform security key, which can be used to remotely attest "I haven't been tampered yet" to servers before communicating. You would then do some kind of physical enclosure size/seals/standards to protect from skimmers layered outside the trusted device, and then some kind of device to user authentication to prove it's a valid device before entering information on it. You could pretty much build this on Android today.
What would it take to get Coreboot people to support some modern server motherboards? Ideally, Dell R720 or HP DL160 or an intel reference E5 design.
Access to specifications and access to the hardware.
For coreboot, the hard bit is chipset support. With full specs, a device to work on, and having lowlevel coding experience (not necessarily coreboot), this is an effort of 3-6 months (depends on specs, on how complex the hardware is, and a bit of luck).
Once a chipset is supported, adding more boards is relatively easy.
The main issue is that specs are generally under NDA. It varies by vendor how hard it is to obtain: nVidia is near impossible (the nVidia support we have was sheer luck), Intel rather wants to see us go away (or so it seems), Via can be coerced to give specs to individuals, AMD provides code and specs.
For servers, there's the additional complication of LOM - I'm not sure how hard that would be to support, and I guess vendors vary wildly in how they hook that up to the system.
About Intel E5: We have sandybridge support (contributed by the chromebook team), but I don't know how much Intel changed between the consumer sandybridge and the Xeon stuff. It's also harder to adapt since it uses Intel's reference code as binary component (probably the best they could get out of them).