[coreboot] Remote security exploit in all 2008+ Intel platforms

[Zoran Stojsavljevic]

> The reason we want to prioritize the ME vs. the FSP, is because a lot
more people were interested in getting rid of the ME,
> so it is a higher priority, *but the FSP is also going to be reversed
eventually and coreboot deblobbed entirely*.

This is very serious claim, Youness. In FSP you do have much more than ONLY
MRC (actually, several MRC algorithms, a bunch tied/bundled together,
depending upon what the initial DRAM SPD discovery mechanism is, my best
guess). You do have BSP CPU init, then APP CPU(s) init(s), and then PCH
init as well, on the system registry level. There is also platform init
phase in there, the very minimal one. Also I throw-in PCIe discovery
algorithm. Serious stuff.

If you ask me, I would keep up with disabling ME on application level
(since ME FW booting is A MUST, as my best understanding of ME FW stands
for now). In other words, if I guessed correctly, to make newest ME 11.x
engine, based on x86 HW (quark most likely), to run idler process all the
time, if Dmitry is correct, and we have MINIX3 micro-kernel running on the
top of quark there.

Divide and Conquer, the evergreen idiom: first to take ME, FSP should come
after (they can be well divided)... ;-)

My two cent thoughts,
Zoran

On Wed, May 3, 2017 at 1:39 AM, Youness Alaoui <
kakaroto at kakaroto.homelinux.net> wrote:

> Looks like I failed at answering Taiidan without generating a flame war.
> Sorry if anyone got offended, that wasn't my aim.
> To answer the various questions that were thrown, here's what I think :
>
> Taiidan, you ask why Purism doesn't just create laptops using FX2 or ARM
> or whatever... Well, because that's not what most people want, out there.
> If you want a RYF laptop using old or underpowered hardware or non-x86
> architectures, that's a problem that has already been solved, there are
> various resellers of such devices. The idea here is not to "Use what we can
> find to make RYF" but rather "Bring RYF to the hardware that people want".
> What I believe Purism is trying to do is to create a modern laptop for
> *everyone* with the extra value of security and privacy, and in the process
> make FLOSS appealing to mainstream instead of letting it be confined in a
> niche. I think everyone will be better off with tools to protect their
> privacy/security without asking them to throw the baby with the bathwater
> by requiring them to use hardware that does not interest them (otherwise,
> if old or non-x86 architectures were so appealing, you would have seen that
> become the norm rather than the exception).
>
> As for the ME and DMCA, I believe this exempts us from it :
> https://www.ftc.gov/news-events/blogs/techftc/2016/10/dmca
> -security-research-exemption-consumer-devices
> ...Considering that the research is done in order to protect users. Also,
> an exploit to run a custom firmware on the ME isn't something that gives
> access to copyrighted material, so I'm not sure why the DMCA would even
> apply here.
> As for your argument of an arms race and Intel "fixing" the weaknesses
> allowing us to neutralize the ME, I don't see how that would matter either,
> because you will be able to control the image on your own machine
> *today*... if you neutralize it today, even if Intel wanted to take over
> the ME in your system to patch it, well... they can't get in, because you
> already neutralized it. And if they want to change it for future models,
> they will have to change it in the silicon of future models, which is way
> out in the future.
>
> To answer Sam:
> Thanks for the kudos! The reason C is used is because I didn't think to
> use anything else. I love C and that's what I like to use. But beyond that
> answer, there are many reasons for using C. It's because this is an
> assembly to C translation, if the code is 'prone to errors' it's only
> because the original ME binary instructions had those errors in it, which
> is good for us, since we're looking for exploits. Also, the long term goal
> is to be able to generate binary-compatible images (imagine, you compile
> the ME source and get a binary with the same hash as the one intel is
> providing, so you can be 100% sure that it's the same code that you're
> auditing as the one that is running). If we were to use any high level
> language, we would never have enough fine control over the resulting binary
> to be able to get binary compatibility.
>
> Zoran: Thanks for your comments and encouragement! :) the talks with Intel
> as far as I know are not for open-sourcing the ME (which is a much harder
> thing to ask for), but rather for a ME-less design. Basically, for Intel to
> release a chip with the ME core simply disabled and with no firmware
> running on it. That's a much easier goal to attain, but then again, we're
> talking about Intel, so it's still a difficult goal to attain, but Todd has
> been bugging them for a while and is constantly in talks with Intel to try
> and achieve that.
>
>
> to answer Nico's other post:
> I'm quite surprised and disappointed by your answer. You have every right
> to say that you are disappointed or distrusting Purism due to past actions,
> but I find it harsh for you to be repeatedly saying "fraud" and "scammed"
> when that is not the case at all. I think Ron has responded quite well to
> that and said exactly what I wanted to say, there is a difference between
> being naive and underestimating the task, vs actively "trying to scam
> people". If they were scamming people, they wouldn't have shipped any
> product and they wouldn't have reimbursed those who changed their mind or
> were unsatisfied with what they got, and actually, I wouldn't even have
> been contracted in the first place.
>
> Attributing to malice what was the result of honest mistakes, while you
> know how complex this is both on the software and hardware side, is why
> your tone was disappointing. Careless name-calling leads to people getting
> hurt and flame wars and all that.
>
> I would just like to answer you with a few more items that I believe are
> true (I may be mistaken myself as I'm still quite new to Purism):
>
>    - Everything that was promised is still on the roadmap and a
>    work-in-progress (as far as I know), so it's more of an issue of missing
>    the deadlines/estimates rather than not wanting to deliver anything that
>    was promised. The "Vision" of the company in an initial crowdfunding
>    campaign does not mean "this is an immediately attainable milestone".
>    - The priority was to actually have a working product before working
>    on its coreboot port (wouldn't you agree that makes more sense?) There were
>    a ton of issues to solve with production/delivery to begin with, and Purism
>    is understaffed (most are volunteers as far as I know, and people with the
>    skills to do a coreboot port are quite rare, as you know... and some that
>    Purism hired before went dark). It would have been useless to focus all
>    efforts on coreboot for a hardware product in the making. Purism brought me
>    on and I had no knowledge of coreboot... let that sink in for a minute:
>    people able and willing to do that work are so rare that they had to train
>    one from scratch!
>    - The reason there is no coreboot port for the original
>    Broadwell-based Librem 15 yet is because the most logical approach was to
>    finalize the initial work that had been done on the Librem 13 as per Ron's
>    suggestion (making the learning curve a bit less steep by not having to
>    start from scratch), and then to prioritize work towards the upcoming
>    hardware so Purism can attempt to have it ready in time for it to be
>    factory-preloaded instead of causing additional trouble for future users.
>    The original Librem 15 is still going to be ported, but I can't do
>    everything at the same time, so things have to be prioritized. After the
>    initial learning curve, I am now jumping into the deep end of the coreboot
>    pool by porting a new board from scratch, so that's definitely an
>    interesting challenge.
>    - The reason we want to prioritize the ME vs. the FSP, is because a
>    lot more people were interested in getting rid of the ME, so it is a higher
>    priority, but the FSP is also going to be reversed eventually and coreboot
>    deblobbed entirely.
>    - Purism is trying to do the right thing and trying to defend privacy
>    and security the best way it can (it even became a Social Purpose
>    Corporation to protect that goal)... but instead of saying "You are
>    mistaken on this and that, let me enlighten you and help you", you are
>    instead bashing and trying to drive it into the ground because, for some
>    reason unknown to me, you feel personally slighted by Purism's legitimate
>    mistakes? How is that going to help protect people as a whole? It takes
>    time to do things right, and being stuck in the past does not help things
>    move forward. Give it a chance!
>    - What did you see on the website making wrong claims? Let me know and
>    I will pass on the message to get it fixed. The info on it is a *lot* more
>    accurate than it was a few months ago, and pretty much any coreboot/ME
>    claim has clear "work-in-progress" disclaimers along with it (without
>    writing a huge wall of text on every page). Give me specifics and I'll
>    forward the information to be corrected. I know there is a best effort to
>    rectify mistakes and make things clear and unambiguous, if something
>    remains unclear it's certainly just an oversight, not malice.
>
>
> Thanks for reading,
> Youness.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20170503/2f94774a/attachment-0001.html>