The answer which is missing from the sibling comments is that it allows Windows to restart your computer to install updates (which Windows loves to do!) in the middle of the night and it can boot back up and finish the installation without user interaction. It can even restart more than once. This benefit doesn't exist in some of the dual boot setups that have been described here though.

As others have said, attackers are meant to be prevented from getting in directly by the Windows password, and they can't just put the disk in another machine to read because it wouldn't have the right TPM. I don't know enough about TPMs to know what stops an attacker from installing an OS on another hard drive on the same motherboard and using that to access the TPM to decrypt the target drive, but presumably that's been thought of. It's certainly susceptible to turning the machine on and then physically lifting the RAM out into another machine to extract the key (cooled RAM keeps its contents reliably for long enough for this to be feasible), or dismantling the TPM, but both of these are high skill attacks.

> I don't know enough about TPMs to know what stops an attacker from installing an OS on another hard drive on the same motherboard and using that to access the TPM

The TPM cannot prevent that, you need secure boot. That will prevent the machine to boot into another operating system. But only if you delete Microsoft's public keys from your machine. Otherwise the thief can boot Windows and all Linux distros that have a Microsoft-signed shim. Deleting Microsoft's key on a machine that is supposed to run Windows as dual boot would mean that you need to sign Windows yourself. Probably doable, but yet more hassle.

So probably disk encryption with TPM, i.e. no manual disk password raises the bar enough for the average thief bringing the device to a dodgy backyard shop. But not for a somewhat dedicated attacker. No state level resources needed here at all. Given enough time I might succeed, and I have zero practical experience which such attacks, I am just a normal software developer (having worked a bit with system boot, but not a whole lot).

> The TPM cannot prevent that

Wait, why? I mean, they would be able to access the TPM, sure, but not the keys that would unlock the hard drive. This was my understanding when I played around with TPM: if the boot order has changed, no keys are given to the running OS. You can only reset them, but that just leaves you with an encrypted hard drive and no password to unlock it. I've only used it with LUKS though, not with Windows, but it'd be weird if the approach was different

As I understand it, the idea is that even without a BIOS password nor a disk encryption password, your OS can boot and only then request a session password. So effectively you only have to enter one password, rather than 2 or 3. Even if the laptop is stolen, TPM included, you still have to guess the login password. This is how Bitlocker et all operate and to be honest makes a lot of sense for a regular user (and practically everyone unless your enemy is a government-like entity than can decap/sniff TPM chips...).

Secure Boot actually does not help much here... since the idea is that thief wouldn't be able to change the disk contents.

Interesting - LUKS and Apple's Filevault take the opposite approach; wherein you must provide a password from an authorised user in order to access the contents of a filesystem/logical volume. Meaning that without authorisation your data is still encrypted.

I'm not completely familiar with Windows service management and how it handles logins - but doesn't the TPM auto decrypt function of Bitlocker mean that if you have a compromised system which has a dodgy service that starts at boot time it can potentially exfiltrate data from the machine without a user logging in?

Of course, if this is the scenario you're experiencing you have much bigger problems already haha.

You still need a password, but you you don't have to choose/enter a separate password for your disk encryption. With TPM, your computer decrypts and boots up to your OS, where a thief would have to enter in your OS password. They can't bypass it by patching the OS files or cracking the hash stored on disk, because the disk is encrypted. They also can't bypass it with a patched kernel/bootloader, because that would change the PCRs, causing the TPM to no longer auto-unlock.

> What's the point of using a TPM to decrypt your disk automatically?

It's moving the slider towards the "ease of use" end of the "security - ease of use" spectrum. It essentially outsources security to the Windows OS logon, at which point a whole bunch has started up in the background and the attack surface has substantially increased.

But it saves having to type in a second password.