[Magisk] pndwal:
Ah, thanks... That may be useful! 🙂

Well Secure boot chain of trust is implemented in hardware...

Guess you simply mean enforcement of device having TPM 2.0 for Win 11 is only implemented at OS level.(?)

Guess that may be improved then. 🙃

But secure boot can of course be disabled with Win 11 (with or without hacks to bypass TPM 2 requirement) and system will still boot!... So there's really no difference ATM AFAICS...

Either way, having hardware based cryptographic keys to provide strong attestation to secure boot looks like PC history catching up with ARM mobile soc's hardware keystore based attestations to verified bootstate that is AVB to me!... And apparently they're doing this for all the same reasons. 😉

Well Google does produce each iteration AOSP from proprietary Android (this and all major milestones being developed in house for their flagship devices and licensed differently as many Pixel users know), but of course once they finalise open source licensing and turn it over to the OHA (also their baby) it's no longer owned by but effectively gifted by Google... Android is thus still Google's mobile OS in a very real sense.

Of course gms components (GApps) are always owned by Google...

Not sure of your point here...

The point @swer45 was making was that Google has provided a means (through AVB) to obtain strong attestation to an Android device's real boot state by validating a certificate from hardware keys without even using Google's PI os S/N APIs and that Microsoft are now heading down the same path... I happen to agree.

Of course the implimentations differ, but essentially Android Verified Boot is mirrored in Microsoft's new secure boot implementation...

Further, I doubt Microsoft will 'enforce any sort of security requirements on the behalf of third party apps' any more than Google does!... In AVB / secure boot, both entities are simply providing a system whereby 'device integrity' can be reliably polled if those third party apps/Devs wish to check for runtime environment compromise.

-----​

My initial response was really because you said:

But that's only a requirement for loading Windows... It doesn't mean that if optional 'secure boot' is enabled (because some application requires it) the attestation can be bypassed or spoofed any more than a hardware-backed attestation to boot state can be falsified in Android...

And then:

But @swr45 wasn't even discussing Google device integrity API based verdicts or changes to to these APIs!... Rather:

With this (entirely different) method any app can reliably discover any devices true B/L state. Moreover there's no impact for users of old (release with pre A8 OS etc) devices either (verified boot still gives B/L state as Verified, Locked=true), so banks can use it now without any 'collateral damage' among customers...

A month ago I put links to Google documentation about this method "unrelated to calls made by the gms droidguard VM for Google API device integrity APIs" and vvb2060/Rikka's POC app at the end of this post:

https://xdaforums.com/t/magisk-general-support-discussion.3432382/post-88443625

and more information here:

https://xdaforums.com/t/magisk-general-support-discussion.3432382/post-88448315

🤪 PW