[coreboot] T450S + Coreboot

Nico Huber nico.h at gmx.de
Thu Aug 30 17:47:24 CEST 2018


Hi Mike,

On 30.08.2018 15:51, Mike Banon wrote:
>> The fact that it's closed source and not user-controlled (Even if you had
>> the sources, you can't modify them and update it to your custom ME
>> version) is where the problem actually is. There *might* be a backdoor
>> hidden somewhere in there, or maybe there isn't, nobody knows.
> 
> I agree with your statement above. But, please look on this question
> from the end user's perspective, who might be not a software
> developer. Imagine that you have a choice between two
> similar-by-performance coreboot-supported laptops: according to
> cpubenchmark's passmark, Lenovo G505S's AMD A10-5750M = 3342 points
> (from 886 samples) while Librem 15's Intel i7-6500U = 4429 points
> (from 3345 samples), so the CPU performance difference is just 1/3 (
> and at the fresh test results there might be little to none, since the
> Intel-only Meltdown vulnerability requires a patch which eats up to
> 30% performance depending on the workload, and there are also some
> other Intel-specific "performance-eating" vulnerabilities, the most
> serious of which - TLBleed / T1TF - may soon require the disabling of
> HyperThreading at all the Intel CPUs, see [1] and [2] )

You are comparing worst case scenarios of one CPU that would be
considered secure by current research and one that hasn't been
researched as much. That alone doesn't make much sense. Also, why
do you assume that one runs untrusted code on his laptop? If one
doesn't, he also doesn't need performance eating mitigations for
these vulnerabilities. You probably need to do more research about
what Meltdown and the Spectre vulnerabilities are and what they
imply.

>> Your comparison of saying the ME is a backdoor is like saying that a
>> webcam is a spying device because it can capture images of you! [...]
>> The fact that the webcam schematics isn't open means that it could
>> still have a small wifi or GSM chip embedded inside
> 
> Yes, but I could easily put a tape over that webcam, disconnect and
> remove a webcam module from the laptop's case (or even make a custom
> DIY kill-switch). Same for a microphone - could be easily desoldered
> (and maybe soldered back but through a kill-switch). And for the
> speakers: according to the recent researches the speakers could act as
> a microphone - see [3] - so Librem 15 should have a kill-switch for
> the speakers as well. Meanwhile you can't throw away ME the same easy
> way.

Your are talking past each other. That you can put some tape over a
webcam doesn't answer the question if you should call it a spying
device. What if you buy a webcam to use it as webcam? is it a spying
device?

> 
>> you yourself said earlier, when talking about the AtomBIOS
>> that "it could be disassembled quite well with AtomDis -
>> https://github.com/mikebdp2/AtomDis - reducing any security concerns
>> regarding this blob to a minimum.", well, the ME can be disassembled
>> with any x86 disassembler, so why can't you also say that "reduces any
>> security concerns regarding the ME to a minimum".
> 
> Actually this AtomBIOS blob is not required to run this laptop, only
> to initialize its' display. It is possible to turn this laptop into a
> miniPC/server and still use its' hardware without this blob, although
> it wouldn't be exactly a laptop after that. But if we would consider
> this blob as required: here is a quality of disassembly I'm getting
> with AtomDis - https://pastebin.com/xKW9FV58 . All the command tables
> and data tables are named and in many cases it could be understood
> what some particular piece of code is doing even after a quick glance.
> Are you sure that your ME blob x86 disassembly is providing a similar
> or higher level of transparency? Perhaps it is this level of
> transparency which allowed to 95% complete the development of the
> opensource AtomBIOS alternative called OpenAtom ( I think the
> development efforts have stopped partially because no-one have noticed
> any backdoors after completing the 95% and it became much less
> interesting to complete the remaining 5% , [4] )

Can you point me to these 95%? What I see in the repository is rather
1% (I only see a replay). Maybe I'm just looking at the wrong files.
Regarding the disassembly, I don't understand shit in there (and I've
written display init code myself).

> Actually it might be a good idea for Purism to at least consider the
> switch to AMD Ryzen CPUs. Yes, unlike the 15h/early16h gen AMD CPUs,
> their new Ryzen CPUs contain the PSP, Platform Security Processor -
> which is also a management engine. But it is significantly younger
> than Intel ME (Skylake's ME is already generation 11), so PSP should
> have less sophisticated protections and it should be easier to
> "jailbreak" this "young PSP" rather than "modern ME". Early ME
> implementations were also weak, after all, and I expect "young PSP" to
> be weak also.

I agree that Purism should evaluate AMD options. Actually I assume,
they do. Saying that a younger version is less sophisticated seems odd
though, as the vulnerabilities in ME11 didn't exist earlier. Also,
investing in a platform that you would have to "jailbreak" is wrong.
You'd be giving them money for something you don't want.

> Also, those AMD CPUs do not suffer from the
> recently-discovered Intel-specific vulnerabilities and their
> performance-degrading patches will not be required. Finally, AMD had a
> good collaboration history with coreboot (although this collaboration
> is not active currently, it might be renewed if there will be enough
> mutual interest) - and I believe AMD at least will not be as hostile
> towards your opensource/reverse-engineering efforts as Intel is
> currently. If any of these statements seems reasonable to you, please
> think of trying to make your Purism company to at least consider this
> AMD switch.

Again, that AMD CPUs don't suffer as much from the research of Intel
CPUs as Intel CPUs seems clear. You are assuming that there are less
problems in AMD CPUs. I assume that there is less research on AMD CPUs.

Maybe AMD is not hostile against reverse engineering. But you seem to
forget that they don't provide any documentation at all atm (for fam17h/
Ryzen) to write firmware. If you want to get coreboot running on Ryzen,
you better start collecting funds, maybe $500k for a kick off?

Nico

> "disable Intel hyperthreading" :
> [1] - https://news.ycombinator.com/item?id=17829790
> [2] - https://marc.info/?l=openbsd-tech&m=153504937925732&w=2
> speaker as a microphone:
> [3] - https://security.stackexchange.com/questions/154343/can-a-speaker-be-used-as-a-microphone
> [4] - https://mail.coreboot.org/pipermail/coreboot/2018-January/085979.html



More information about the coreboot mailing list