> So, isn't this firmware protection with BootGuard only really meant to prevent rootkits from getting persistence?

I saw this "but it only prevent persistence" several times and I wonder...

Isn't preventing rootkit from getting persistence already a big win? Preventing a rootkit from getting persistence also means that should a new signed kernel contain a security fix fixing the hole the rootkit was exploiting be installed, the rootkit won't work at all anymore. The attacker now needs not only to root the machine at each boot, he also needs to cross fingers that a kernel patch closing the hole he's exploiting doesn't get installed (or he needs to both prevent the new kernel from being installed while, at the same time, managing to make believe it's been installed).

Which also raises the probability the exploit he's using at every boot gets detected at some point.

How is this a win for attackers?

Are black hat hackers really thinking "Great, BootGuard and SecureBoot are getting ubiquitous, everything up to the kernel loading is signed and enforced, so now things are easier for me!"?

Kind of true? If you disable secure boot at least on Windows BitLocker will no longer unlock your disk at boot, and so you'll need to enter the recovery code at least once.

Yes, but that will happen also without BootGuard. So what does Bootguard add with respect to physical attacks?

If the target doesn't have BootGuard, you replace the firmware with one that pretends that Secure Boot is enabled even if it isn't and Bitlocker is unaware anything's changed.

Secure Boot configuration is usually stored in flash, not battery-backed CMOS, so on most boards won't be wiped if you simply remove the battery. But if you do have physical access you can simply rewrite that variable in flash to disable it - doing so will change the TPM measurements and so Bitlocker (or whatever) will complain, so it's not silent.