Hacker News Reader

Comment by matja | Hacker News Reader

If you bypass the installer minimum hardware checks then you're making a gamble that the official statement from Microsoft won't affect you:

> If Windows 11 is installed on ineligible hardware, your device won't receive support from Microsoft, and you should be comfortable assuming the risk of running into compatibility issues.

> Devices that don't meet these system requirements might malfunction due to compatibility or other issues. Additionally, these devices aren't guaranteed to receive updates, including but not limited to security updates.

View on HN

Aren't you guys actually talking about a TPM 2.0 device being present on the machine and not a CPU specifically? Cause the whole Windows 11 thing was (I thought) full disk encryption with TPM 2.0 attestation booted from a secure boot BIOS. That basically just means you can't take the disk and boot it on another machine. There would be no way to decrypt.

You can use a TPM for disk encryption with Linux if you want. You also get to use your own secureboot keys if you want. Your choice.

I can't be bothered. My 80386 worked fine without any of the above and I still don't need any of it on a Zen%d (except Linux)

Yea I was looking at this for work. We require full disk encryption for all operating systems but linux is the one where it's a passphrase or a yubikey. In my personal life it would just make managing my PC more annoying. Imagine a motherboard failure and boom there goes my entire disk.

> Imagine a motherboard failure

Hold up, I'm no expert on Secure Boot, but LUKS allows you to have multiple entry keys to the same drive.

This means you can have one key of random gobbledegook which is kept and auto-used by the magic motherboard, and also a passphrase that you can memorize or write down, and either one is totally sufficient on its own.

You don't even need to set them up at the same time, you can start with one and then add the other as an option later.

Secureboot is something else. It verifies the boot loader at the BIOS. This can be broken by the system itself (like if it's hacked). So it's protecting you against modifications to the boot loader. This is where kernel modules can be injected.

TPM 2.0 is something else. It's typically soldered onto the motherboard as a physical device and the key can be generated and then used to encrypt the disk. The private key can not be extracted. Only the signature and you can ask the TPM to sign a binary blob with the private key while providing you the public key to verify. This protects you against physical access to your device. No one can take your disk and decrypt it.

> the key can be generated and then used to encrypt the disk

Right, you can't recover or copy that specific key, but you also don't have to for accessing your data, if you set up some redundancy before disaster struck.

AFAIK: 99% of your storage is encrypted by a giant fixed unchanging master-key, and that is itself encrypted again with a non-master key/LS or passphrase, which is stored in the remaining "LUKS header". There's room to store multiple copies of the same master-key encrypted with different non-master options.

In that model, the TPM is simply providing (in a convoluted way) its own passphrase for one of those co-equal slots, so having one or more alternates prepared is sufficient to protect your drive from motherboard failure.

Yubikeys are very useful. I was pointed to them by a colleague and was a bit skeptical in the beginning but since then I am more than happy to use them, absolutely flawless execution. The only thing that I am a bit concerned about is that it isn't the key that I place on the device that governs all this so you can't be 100% sure that there isn't some kind of supply chain trick that would allow the manufacturer or one or more of their employees to create duplicate keys.

With Linux I think you do have the option of encrypting with your own cert using the PCKS#11 module on the Yubikey.

That's interesting, thank you, I will definitely look into this.

You can have automatic unlock with tpm2, with or without a pin, in addition to passphrase, file, fido2, pkcs#11 cert, or whatever else is supported by luks.

I've been using this for a few years now, and never had an issue.

https://wiki.archlinux.org/title/Systemd-cryptenroll

> Imagine a motherboard failure and boom there goes my entire disk.

You can also set a long-ass key in addition to the other methods, and back it up somewhere safe. It works the same as bitlocker: you have key which can decrypt the drive without external help from a TPM in case something goes wrong.

This is actually a super useful summary. Thank you.

Windows 11 officially requires TPM 2.0, secure-boot enabled, and an AMD Zen+ (Ryzen 2xxx) or later or an Intel Core Gen 8 or later.

https://arstechnica.com/gadgets/2021/10/windows-11-the-ars-t...

> ... the best rationale for the processor requirement is that these chips (mostly) support something called “mode-based execution control,” or MBEC. MBEC provides hardware acceleration for an optional memory integrity feature in Windows (also known as hypervisor-protected code integrity, or HVCI) that can be enabled on any Windows 10 or Windows 11 PC but can come with hefty performance penalties for older processors without MBEC support.

> Another theory: older processors are more likely to be running in old systems that haven’t had their firmware updated to mitigate major hardware-level vulnerabilities that have been discovered in the last few years, like Spectre and Meltdown

For some reason that risk never seemed larger than the one that Microsoft would force me into subscribing to more services because they hold my data hostage or that they would be more than happy to pass the keys to my machine to the USG.

I have a few machines which lack a supported CPU. There's CPU's only 6 years old which aren't supported. There may be some newer ones even (I didn't bother to look).

If it was 2000 - it'd be like, "OK boss, you gotta upgrade that old dog of a CPU", but software bloat really hasn't kept up with CPU performance. I've got an i3 which is serviceable enough from 2014. Is it going to be able to keep up with modern SQL Server and Teams and VSCode and all that? Probably not all at once. But totally fine for basic computing.

But if your next move is to go to Linux where all that applies as well, why would that stop you?

You are correct that a Linux installation is ineligible for support from Microsoft. Not that that means anything for private usage.

Also, Linux has a great track record for not dropping support for older hardware. I think that is a lot more informative than whatever statement Microsoft's legal team has managed to come up with.

No need to be obtuse, you knew what they meant.

There’s no functional gamble. It’s worked fine and it will continue to work fine. Everyone is seriously overreacting, they’re just scare tactic words.

Windows 11 24H2 added a dependency on the POPCNT instruction, causing CPUs that don't have it - which were otherwise fine, to fail to even boot Windows.

What will be the next instruction/ISA extension that is only supported since Intel 11th Gen that there will be a hard dependency on? Any bets?

And they fixed it. A bug like that is a seperate category of problem entirely.

Reply on news.ycombinator.com