[x86] (9) PFAT aka. BIOS Guard and its flaw

Back to x86 again everyone, for responsible to curious feedback from 王御多, here's some little explain for PFAT aka. BIOS Guard.



Alright, I know some might feel it's too short for explaining the PFAT, however, it's really necessary to understand the basis of RSA first. If you do familiar with RSA, the only mist of PFAT to you is "Use HW solution to replace SMI method".

Using SMI method to verify and update BIOS package is okay in traditional way since in early days, people aren't so familiar with SMI. However, now days we have various software tools and spec. help us to catch and hijack the SMI.

So here's the PFAT (HW solution), the main idea is extremely simple, doing the verify and update in the hideout, block the interrupt and fetch the package data from HW-specified memory part. See, it's really simple so say so, PFAT is doing the exactly same thing except it's hiding in specified HW place.

Well, it's pretty nice, isn't?

However, someone just forgot a little thing about compatibility with BIOS recovery...what? how they get messed up since BIOS recovery is so conventional? Well, they did forget it. You may seem BIOS recovery as another kind BIOS update package only difference is the package itself is previously stored in BIOS ROM and it runs in PEI phase. Sounds fine...but PFAT module only runs in DXE phase....WTF?! BIOS recovery module could never pass the verify phase!

Anyway, I'm pretty sure it's just a little flaw had been fixed by now, just to share the experience that even the mighty one would make such funny issue.

Please leave me any comments or questions, I'd be thankful and response as soon as possible! Thanks!

[x86] (5) Talking about the Working Model of OEM and ODM on RSA Keys Manufacture

If you're not familiar with "Security Boot", "Boot Guard" or "BIOS Guard" stuffs, you might find this subject quite boring. In case that, I think the better way is to explain it as usual sarcasm style.

Previous features I mentioned are designed or claimed for better security integration on platform, it's like a series of locks that you might only pass with right identity. For example, assume as following scene:

Lock: blocks the boot flow unless the right key is accepted.

Right Keys: Can only manufactured by OS vendor and OEM/ ODM (OEM has the right to decide to use only OEM key or both of OEM and ODM keys)

Since right keys can only manufactured by OS vendor, OEM or ODM, here's the funny question: What if the right is leaked, who should be responsible for it?

Well, four kinds of situation:

(1) OS vendor's key leaked: No doubt that OS vendor should be responsible for it since none can access the key but their self, right?

(2) Only OEM Key used and it's leaked: Of course it's OEM's fault, however, if this method is used, OEM should maintain a safe server allowing ODM to upload the signature file to be signed by OEM's internal private key and download from the server. Guess what? Some OEM takes the effort quickly but some just take other methods...

(3) Only ODM key used and it's leaked: Of course it's ODM's fault, however, every one would blame it on OEM. If any bad things happen, ha ha, some poor engineer would be kicked out. Don't worry about the supervisor, they always find the way out.

(4) OEM and ODM keys used and one leaked: Why we need this method? Why not only OEM key used? Well, it's because some OEM's too lazy to build the safe server responsible for ODM's signature, but still wanna ensure which ODM leaks their key and make sure ODM wouldn't produce other non-official keys. Oh man, it's really complicated, right? More to that, what if OEM or ODM would like to change or testify their own keys in the same BIOS code-base? There we need the compile switch provided by IBV to determine if the OEM/ ODM keys changed or not in current compile time. It's complicated, however, once built, it's easy to use to OEM or ODM, and lazy OEM doesn't have to own the safe server. How lazy and brilliant. By the way, I'm the guy worldwide first figured out this working model to satisfy the lazy OEM supervisor...

Finally, based on the experience I shared previously.  I realize there are two ways to work in OEM:

(1) To Follow and get SLAPPED by supervisor.

-> Advantage: Keep your job well and stable.
-> Disadvantage: Get slapped all the time.

(2) To Create and get FIRED by supervisor.

-> Advantage: Be creative to flexible working models to satisfy various needs.
-> Disadvantage: Be creative is bitching and jealous supervisor finds excuse to fire you someday.



Any way, it's been cool to share some experience with you, if you find any questions, suggestions or comments, please give me some feed-backs, thanks a lot!