Showing posts with label smi. Show all posts
Showing posts with label smi. Show all posts

Thursday, February 20, 2014

[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!

Thursday, October 31, 2013

[x86] (2) Post Mortem: ACPI/ SCI/ Q Event

Before we back to the Future world full of mobile and smart devices, let's take a look on those old bones from yesterday world...however, as the latest news I know, there are still a huge bunch of Taiwan engineers devoted their self to the x86 based, nearly dead PC and NB markets and refuse to wake up. It's really sucks that our human nature tends to follow, not to lead. Anyway, pretend you're visiting the x86 museum....with my sarcasm introduce.

 Long long time ago, there is a power saving standard called APM, the main idea is that any devices besides the CPU might notify CPU through SMI (software or hardware wired) that CPU would run the power state modify routine written in BIOS code. SMIs can't be scheduled well since it's nothing to do with OS that the system would halt while CPU's dealing with SMIs.

Well, it sucks to be so technique. Let's do it over again, CPU is a poor cook, only dealing one customer's order at one time. However, there are a bunch of crazy supervisors, they could interrupt cooker's job in the name of SMI. So the poor cook got customer complaint and supervisor take it as their huge contribution as management level.
























Boring questions you guys must know the answers.


More boring history.


ACPI's so complicated...Really? The main idea is as simple as the poor cook example in APM.



I really like this page that I draw before, however it's too detailed on ACPI events. If anyone's interested, I would append the explanation as demand.


This is my favorite page that I update it several times! Too bad it's still detailed, but I would point one thing take-away, ACPI is like the poor cook in previously example, hires one sexy waitress (that is Operating System!) to assist the order schedule including the non-sense requests from stupid supervisors. The SMI requests mentioned previously are now replaced by SCI requests.


Huh, boring power states. Can you image that all those years go by and still the general users got confused on all those damn S3/S4/S5/S0/Hibernate/Fast-Start-Up/ Connected-Stand-By things... No one really sees what are they doing and they didn't even recognize it...wow!


More Reference...


More questions... make it stop!


Good trip of old stuff, right? I had devoted a lot time and efforts on it, but now I realize that I shouldn't only learn for the job and money, or there goes the consequences that most things you know became the yesterday's ashes. At least I wake up now, ha ha.

Any questions, suggestions or comments, please show me some support, thanks!