Are Intel still disabling random features in the K versions of their processors for market segmentation reasons? Figuring out what processors had what features locked off was getting truly ridiculous.
In the case of TXT I don't think everyone would consider it a desirable feature since it's part of the trusted computing stuff, but in the past they've also disabled more friendly features like virtualisation.
If you're not using TXT, your full disk encryption is completely useless if an attacker can get access to your laptop for 5 minutes¹. They can just backdoor the bootloader (or, on Linux, your kernel/initramfs which are not encrypted) to get a foot into your system at the highest level of privileges.
If you're using TXT, maybe the NSA can still do that by getting the ACM signing keys from Intel. But that's still an improvement from just the standard FDE setup most people use, which could be trivially hacked by someone with the skill of an average university student.
¹ Make that 15min if you have a BIOS password and a static boot order that disallows booting on any kind of external device. It just requires a bit more preparation, but on most laptops it's not hard to put a clip on the NVRAM that stores BIOS settings and reset what needs to be reset.
This is simply not correct, TXT is not required for this, the TPM can still and does protect your OS and boot loader from tampering, it's also not required for Windows Secure Boot.
TXT extends the chain of trust to the BIOS/UEFI by having the CPU take charge of some of the verification, secure boot supported UEFI's (if they meet the UEFI standard version 2.3.1c or higher) can also extend the protection envelope beyond the OS/MBR but the main function of TXT is to protect tampering with low level firmware not OS/bootloaders.
"Intel TXT uses a Trusted Platform Module (TPM) and cryptographic techniques to provide measurements of software and platform components so that system software as well as local and remote management applications may use those measurements to make trust decisions. This technology is based on an industry initiative by the Trusted Computing Group (TCG) to promote safer computing. It defends against software-based attacks aimed at stealing sensitive information by corrupting system and/or BIOS code, or modifying the platform's configuration."
Secure Boot's aim is mostly to protect against malware persisting through the boot process ("bootkits"). Given that it's anchored in the firmware and the firmware is unverified in almost all consumer x86 motherboards, an attacker with physical access can still bypass it in a trivial amount of time (it requires some preparation to figure out what to patch, but the patching itself is quick).
In theory anything can be bypassed including TXT, TXT on it's own does not provide any substantial amount of protection against tampering at least not over traditional TPM setups.
What it does is centralizes all of the measurements in one place and adds DRM.
It's not bad in any way but it's also not required to run a secure boot encryption setup.
My 9 year old HP Compaq 6910p Centrino with TPM can offer almost the same level of protection as any modern Intel vPro laptop.
Case for Bitlocker (one of the few FDE's that actually has good integrity checks)
BIOS / UEFI modification (Update, revision, settings
change etc.) - both will trigger recovery mode
-Boot loader modification - both will trigger recovery mode
-Boot order change - both will trigger recovery mode
-Boot attempt number does match between TPM & HDD (e.g.
when the HDD was removed and attempted to be booted in another device, or when the machine was booted not from the HDD) - both will trigger recovery mode
-Data partition changed - both will trigger recovery mode
The only difference is that if my device is in either S4 and S5 mode TXT can still continue to make measurements, and the measurements that TXT allows you to do are very generic unlike standard TPM/Secureboot which only checks for specific parameters.
You also need to understand that FDE is not designed to protect your information in such cases where you lose control of the physical security of the device and do not treat it as untrustworthy afterwards, it's more or less excellent at protecting your data while it's in rest if the device is lost or stolen but that's it.
And while yes secure boot can be bypassed and TPM's could also potentially be broken (which invalidates TXT as well since it uses the TPM as the cryptographic storage device for the signatures) an adversary that can bypass one could most likely bypass the others (you also need to remember that with TXT the measurement plan is stored in the UEFI flash/ram/nvram not in the TPM) and with any system your overall level of confidence should be as high as the weakest component.
Can you elaborate on this a bit? I'm definitely not an encryption expert, but I was under the impression that full disk encryption on Linux with a sufficiently long passphrase was secure.
I personally use cryptsetup (dm-crypt/LUKS) on my laptop running Arch Linux just in case it were stolen. Are you saying that bypassing the bootloader with a live USB, etc, could give an attacker access to the data stored on the encrypted drive (outside of the boot partition, of course)? That seems like it would defeat the purpose of full disk encryption. Note: I understand that this is assuming that the attacker does not gain access to the system while it is up and running.
> Are you saying that bypassing the bootloader with a live USB, etc, could give an attacker access to the data stored on the encrypted drive (outside of the boot partition, of course)?
No, of course not. (Well, disregarding cold boot attacks).
But it gives access to data stored inside the boot partition, allowing for fun things like patching your kernel to send dm-crypt keys to http://fbi.gov/submit_key.cgi - makes sense now?
There are ways to also encrypt the boot partition.
There are various protection mechanism that rely on software alone (bootloader), software + hardware (TPM), software + firmware and software + hardware + firmware.
The question is always what do you want besides encrypting the main partition mainly in terms of integrity checks.
And older BIOS with a TPM or a modern UEFI with or without a TPM can provide additional integrity check for both the host configuration (BIOS/Device settings) as well as storage device specific integrity checks.
TXT basically allows you to measure various elements using the UEFI and more importantly for OEM's at least TXT has extensive DRM capabilities that can restrict the user from installing "untrusted" operating systems or making modifications to the host it self (e.g. chaging bios settings).
Beyond that TXT gives only a slight improvement as far as actual security goes against cold boot attacks as it allows you to take measurement when switching between S4 and S5 power states (soft off and hibernate) it still doesn't allow any measurement for S1-S3 states which are legacy sleep mode.
A modern UEFI with or without a TPM can ensure that the OS will not boot or will boot into recovery mode if any changes were made to the hardware or firmware configurations as well as if any tampering was done to the bootloader (secure boot keys) with a TPM you can be slightly more assured that no one tampered with anything since the TPM is a better cryptographic storage than the UEFI's ram/nvram.
Full-disk encryption protects against anyone who steals your laptop. However, if someone can get access to your laptop without your knowledge, and you subsequently use the laptop, they could install a hardware or software mechanism to obtain your passphrase.
Yep. TXT or TPM can cryptographically verify boot integrity but aren't magic pixie dust for passphrase recovery via hardware tampering. In the end your adversary can just put in a hardware keylogger between the laptop keyboard and the motherboard.
It once occurred to me that it's possible to encrypt the disk completely and put bootloader/kernel/etc on a flash drive attached to your keyring (the physical kind).
Then it all boils down to BIOS security. With physical WP pins on flash chips it ought to be possible to make BIOS reflashing a reasonable PITA, especially for someone who wasn't prepared for such surprise.
This wouldn't prevent the computer from booting into a new key-stealing bootloader newly installed on the hard disk. You probably wouldn't even notice that the computer wasn't actually booting from the USB drive.
With how overclocking is done on UEFI enabled motherboards TXT will not work anyhow.
Virtually no OEM uses K series processors, the vast majority of computers that come with TPM's are laptops which use a different SKU family, the few workstations that do will not use the desktop K series of CPU's.
Intel TXT is also not available on their more "workstation" oriented prosumer line of CPU's like the 5820 and the 5860's.
One thing I've really hated about Intel in recent times has been that you can't really tell what you're getting based on the model number.
I got bitten by this when I built up a system and picked a Core 2 Quad Q8200, only to discover after powering it on that it did NOT have virtualization support.
The problem is only worse now; is that i7-xxxx dual-core or quad-core? Should I get i5-yyyy instead?
Warning: ARK is not much safe either, I saw on reddit some days ago some guy complaining that he bought a I3 after checking it on ARK, and after the purchase, Intel disabled the feature on all i3 and changed ARK too, silently. (It was related to some feature Intel also tried to implement in the 2 previous generations but seemly is buggy)
EDIT: I hit the post limit... Yes, I do think it was TSX
Also some Skylake i5s and i7s had TSX issues, but I don't know whether Intel managed to fix them or is going to disable TSX. So far ARK lists them as supported.
I wouldn't expect anything different, but saying that disabling a feature that was advertised and paid for it's a good thing is plain weird. A good thing would be a recall or reimbursement.
When it works, you get support for database-like transactions on RAM (only small transactions, it isn't black magic).
When it fails, you get all kinds of random crashes at random times.
Introduced in Haswell, turned out to be buggy and Intel famously disabled it with ucode update. Since then, they quietly disabled it also for several Broadwells and Skylakes which didn't fare much better than Haswell.
edit: it seems I misread parent's post as "what is TSX"
