> Show me a FLOSS implementation of this standard and you will have a point
I've had a point from my first comment and it hasn't changed in validity. It's just taking time to convince you, but I think I'm making progress :)
I referenced several open implementations in my last reply, an a cursory search reveals more [1] [2]. Besides, this still doesn't help you trust the hardware, even if that hardware is entirely open like some sort of RISC chip. Can you verify every step in the supply chain? At every stage of assembly? No? Or, assuming a trusted device, can you be 100% confident something wasn't added, a simple keylogger? Most keyboards can be removed from laptops without leaving a trace, so can screen casings, speakers, batteries, etc. Plenty of places to hide something tiny.
> At the moment, I would have to trust a megacorporation obeying NSA,
That's less likely than the software you use having been compromised, for example by introducing an obfuscated bug, or MitMing as you perform a software update (many software update mechanisms have notoriously weak security, search some defcon talks on the subject).
> Your threat model may vary.
No, what I'm saying applies to all threat models, and I challenge you to name one to disprove that.
Secure boot is an open standard and can be implemented in a trustworthy and secure way, you just need to put in the work to do so. It's entirely possible to do so.
Of course if you are putting in all that work, if you are that at risk, you would need to switch your software stack entirely as well and use something like seL4 as a starting point.
[1] https://github.com/prplfoundation/prpl-secure-boot
[2] https://www.coreboot.org/