How can I confirm my current firmware's signature and protect it from exploitation?

I was browsing reddit's network security section and stumbled upon this 0-day attack on my mac's firmware. How could I check the current signature on it and reinstall the OS while being protected from this kind of attack? Credit to the site's author @https://reverse.put.as/2015/05/29/the-empire-strikes-back-apple-how-your-mac-fir mware-security-is-completely-broken/

"It means that you can overwrite the contents of your BIOS from userland and rootkit EFI without any other trick other than a suspend-resume cycle, a kernel extension, flashrom, and root access.

Wait, am I saying Macs EFI can be rootkitted from userland without all the tricks from Thunderbolt that Trammell presented? Yes I am! And that is one **** of a hole :-).

Let me show you how it happens. The following is the flashrom output of a freshly rebooted MacBook Pro Retina 10,1 running the latest EFI firmware available (this is the firmware that was released to “fix” Thunderstrike)."

"What we can see here is that the flash lockdown is active (FLOCKDN=1) and that the BIOS region is mostly read-only. The hole that is writable is the NVRAM portion that is necessary for setting boot options, crash logs and so on. The addresses where EFI binaries are located is lock down by the flash protections (PR0/PR1). The Dark Jedi attack would allow to unlock these areas and make them writable.

After I close the MacBook and let it sleep for a few seconds (30 seconds or something is best, sometimes it doesn’t work and needs to sleep some extra time), we get the following flashrom output after waking up the machine:"

"This time we have FLOCKDN=0 and the protected range registers (PR0/PR1) without any contents. The flash is unlocked and now you can use flashrom to update its contents from userland, including EFI binaries. It means Thunderstrike like rootkit strictly from userland.

"Update:

It appears I miscalculated this thing and appears to be an effective 0day. Doesn’t really matter since I always wanted to disclose it and not sell it due to its very powerful nature (and not working in newer machines). Never assume all bugs are shallow.

You might ask if I am into something against Apple judging by the tone of some posts. I am not. I like OS X and I respect Apple security people who I met a few times. My goal is to make OS X better and more secure.

"...How can you mitigate/detect a possible EFI compromise?

You can build a SPI dumper and use Trammell’s software to directly dump the BIOS chip. Then you can compare its contents against the firmware files provided by Apple. I asked Apple to start publishing these files and their signatures so we can have a good baseline to compare against. Hopefully they will do this one day. I built some tools for this purpose but they aren’t public.
This solves the EFI problem but others are left. For example there is SMC. Alex Ionescu made a very interesting presentation about it a few years ago at NoSuchCon. SMC has a very interesting potential for compromise so it’s also something that needs more research. And now we have PoC regarding GPU rootkits. Every single chip that has firmware and somehow talks to the operating system is open for compromise. We need to think different and start a trust chain from hardware to software. Everyone is trying to solve problems starting from software when the hardware is built on top of weak foundations.
Apple has a great opportunity here because they control their full supply chain and their own designs. I hope they finally see the light and take over this great opportunity. Google is trying with Chromebook.

Is physical access required to exploit this bug?

No, there’s no physical access required to exploit this. You can trigger sleep with “sudo pmset sleepnow” (thanks Trammell). And then you just wait to come back from sleep and continue exploitation."

And an interesting post on the matter...

"Would this be bypassed if the system drive was FileVault 2 enabled since you couldn't gain root access on the recovery volume unless you brute forced a password to decrypt the drive?

So I read you can dump it and compare to a stock one. Where would I find this?

BTW, I didnt just post the link because on my last post I was told not to.