On 05/01/2017 06:44 PM, ron minnich wrote:
On Mon, May 1, 2017 at 1:17 PM Rene Shuster rene.shuster@bcsemail.org wrote:
Yes Puri.sm has been debunked.
I disagree. I've seen the systems. From what I can see, Puri.sm has made a good faith effort to go as far possible *with modern x86 chipsets* toward getting rid of the blobs. They can't get to 100%, but they're trying to get as close as possible.
ron
Name one thing that they have done themselves?
https://www.reddit.com/r/linux/comments/3anjgm/on_the_librem_laptop_purism_d... (yeah its leah but shes right about the coreboot community being corrupted)
Everything they "do" is someone elses code, and their "coreboot" has zero actual init code it is entirely blobbed.
Their marketing is the only thing that is good.
On Mon, May 1, 2017 at 4:22 PM Taiidan@gmx.com Taiidan@gmx.com wrote:
Name one thing that they have done themselves?
Until you've done a port of a new board and taken it all the way through manufacturing test and verification, interfacing with folks at the vendor, and dealing with all the nasty stuff that comes up, I don't think you can fully appreciate just how much work that is. The code is in many ways the least part.
ron
On Mon, May 1, 2017 at 7:22 PM, Taiidan@gmx.com Taiidan@gmx.com wrote:
On 05/01/2017 06:44 PM, ron minnich wrote:
On Mon, May 1, 2017 at 1:17 PM Rene Shuster rene.shuster@bcsemail.org
wrote:
Yes Puri.sm has been debunked.
I disagree. I've seen the systems. From what I can see, Puri.sm has made
a good faith effort to go as far possible *with modern x86 chipsets* toward getting rid of the blobs. They can't get to 100%, but they're trying to get as close as possible.
ron
Name one thing that they have done themselves?
https://www.reddit.com/r/linux/comments/3anjgm/on_the_librem _laptop_purism_doesnt_believe_in/ (yeah its leah but shes right about the coreboot community being corrupted)
Everything they "do" is someone elses code, and their "coreboot" has zero actual init code it is entirely blobbed.
Their marketing is the only thing that is good.
-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Without entering into a flamewar, you're asking "name one thing that they have done themselves" and I will answer that. Full disclaimer: I am working for Purism, and I have been a paid contractor working since last December (part time initially, full time since March) on bringing coreboot and the ME-disablement effort to the Librem line of laptops (more precisely Librem 13 v1, and now working on the Librem 13 v2 hardware which is set to be released/shipped next month).
First, here's a timeline of the coreboot work explained here : https://puri.sm/coreboot/timeline/ That timeline mentions for example that the original port was made by coreboot developers (which seems to be a huge scandal for some reason) after Purism donated 4 laptops for that work. You can also read my blog posts on what exactly I have done (in great detail) in order to bring coreboot to the Librem (from the "I'm a total n00b" to the "I'm still a n00b but slightly less") : https://puri.sm/posts/diving-back-into-coreboot-development/ https://puri.sm/posts/librem-13-coreboot-report-january-12-2017/ https://puri.sm/posts/librem-13-coreboot-report-february-3rd-2017/ https://puri.sm/posts/librem-13-coreboot-report-february-25th-2017/ https://puri.sm/posts/preventing-interference-from-the-old-bios-while-flashi... There's also a pretty big article about NVMe issues that I'm (currently) fixing, which is half-written and which I'd be happy to send you the link to once it's published.
Ron couldn't be more right when he says that you can't appreciate how much work it is to go from a "it works" to a "it's tested/verified and made into a *product* for actual users". It took me 6 months of work to finish the 4 days of work that Duncan Laurie did (I believe it took him 4 days to do the initial port, feel free to correct me if I'm mistaken, and yes of course, I am totally new to the coreboot world, so a lot/most of that time was spent on the learning curve).
You can also see my actual contributions to coreboot (and one unmerged to SeaBIOS) here : https://review.coreboot.org/#/q/owner:%22Alaoui%22 I have also contributed in the past couple of weeks to flashrom by reviewing and commenting in Nico Huber's branch which adds Skylake support to flashrom : https://review.coreboot.org/#/q/topic:intel_chipset_support
Now that was the coreboot work that was done, here is the ME work that was done : While the me_cleaner was tested and verified to work on the Librem (see here: https://puri.sm/posts/neutralizing-intel-management-engine-on-librem-laptops...), the actual work of me_cleaner was done by someone else, but the testing and verification was still done by us, I think that counts for something. Also note that an advantage of the librems here is that they come unfused which is what allows me_cleaner to work on them (see https://puri.sm/learn/intel-me/). Any laptop with the boot guard fuse enabled will shut down immediatly if the ME is cleaned with me_cleaner.
For actual ME-related work that wasn't done by someone else, I will point you to this file : https://github.com/kakaroto/purism-playground/blob/master/me_re/romp.c That is a full C re-implementation of the ROMP module (the smallest of the two modules that me_cleaner does not remove). This is the RAPI header it uses : https://github.com/kakaroto/purism-playground/blob/master/me_re/rapi.h That code is a C reimplementation with every instruction accounted for. It has not been compiled (it serves more as a proof of concept/pseudocode, although it should probably compile), and it's not meant to generate a binary-compatible file (that could be a long term goal to generate binary compatible images from C source with official intel-provided images). Note that I have done the entire Assembly->C conversion myself, but I do want to give credit to Igor Skochinsky for his help (which saved me weeks/months of work) as he shared his notes of his ME reverse engineering efforts (memory layouts, RAPI structures and address->function_name mappings, etc..) This ROMP work and details about that work are also part of the pending article that I mentioned earlier, so you'll get to read about it too if you ever decide to read about my adventures dealing with NVMe.
Now this is what I, personally, have done as a contractor working for Purism, since last December, and I'm not going to mention anything else done by anyone else on the team. After all, you only asked for someone to "name one thing". I hope that answers your question Taiidan.
Now back to the ME exploit subject of this thread. Something to take note of in that ROMP module (note that the binary is just under 1KB of code), it has a bug where it passes the 'partition size' directly as argument to the rom_lock_mem_range function, instead of passing (size << 2) as argument. This causes 3/4th of the memory region not to be locked (the partition size in the header is for some reason in 32-bits units) and the module hashes are contained within that unlocked 3/4th region, and this happens after the signature is verified. So yes, that *could* be a really nice exploit to give us unsigned code execution, if we were to modify some code and its corresponding hash in the unlocked memory after signatures are checked and before the code is executed. Unfortunately according to Igor, it can't be exploited, because this happens before the DRAM is initialized, so it probably only happens in the internal RAM of the ARC Core to which the main CPU doesn't have access anyways (maybe it can be exploited differently, if the copy-to-dram also copies the region-locking boundaries... remains to be seen when more is reversed/understood).
The really interesting part is that ROMP was one of the smallest modules with less than 1KB of code, I wasn't expecting to find a bug/exploit in it, but I just wanted to reverse it to get my feet wet, so to speak, since it wast the smallest of the two that me_cleaner keeps. But ROMP already has this bug, so what other bugs could we find in the 1.6MB of binaries that the ME holds (or worse, in the 10MB version of the ME). I'm not at all surprised that there was an exploit for all these years, the quality of their code is probably not very high, I'm just surprised that it wasn't released sooner. After I'm done with my coreboot work (for the v2 hardware), I'll continue reverse engineering the ME, and maybe something nice will come out of it. Ultimately I hope we can get full unsigned code execution running, and full auditable C code equivalent of any binary code that gets executed between power-on and the exploit/custom code being executed.
-
ron minnich -
Taiidan＠gmx.com -
Youness Alaoui