[coreboot] T450S + Coreboot

[Youness Alaoui]

On Thu, Aug 30, 2018 at 9:51 AM Mike Banon <mikebdp2 at gmail.com> wrote:
>
> Hi Youness,
>
> > 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] )
>
I might be saying wrong things here but aren't ALL cpus affected by
meltdown? so the 30% performance drop would affect the G505S as well?
Also, when I buy a laptop, I don't look at a benchmark and chose the
one with the higher 'points', there are many many other variables to
consider (the design, the other features, the linux compatibility, the
reputation of the company, the build quality, the keyboard/mouse feel,
the price, etc..) and yes, the G505s might come from a reputable
company who builds quality laptops with a good keyboard and it might
be cheap, but maybe I'll find it too old/obsolete, or maybe I'll want
to support a smaller company that is trying its hardest to improve
linux/freedom support, or maybe I won't care. My point is, that's not
how people chose their next laptop, there are countless variables and
if you decide the G505s is the better solution for your needs, then
great, buy/use that, if it's another model or brand, then chose that.
Freedom also comes from being free to chose what we want, there isn't
one single solution that will fit everybody.
Regardless, I have no idea why, when I say that you spread FUD about
the ME with no backing, and state rumors as facts, your answer is "but
the G505s is better than the Librem".. I actually don't even see what
the Librem has to do with any of this....

> The essential power user features like 16GB RAM support and Xen-level
> hardware virtualization technologies ( IOMMU / AMD-V RVI / NPT/SLAT )
> - are also well supported by G505S. But, one laptop has a creepy
> management engine (could be creepy enough to a user who didn't study
> the tons of Intel documentation) where there *might* be a backdoor, is
> not user-controlled (currently) and has a closed-source firmware
> (currently). While another laptop does not contain any hardware
> management engine at all, neither ME nor PSP. Which laptop you would
> have chosen - as a user, not as an employee of Purism - company which
> for some unknown-to-me-reasons is hard-tied to Intel CPUs? Even if we
> wouldn't be considering the significant price difference between G505S
> and Librem 15 - which more than compensates the possible performance
> advantage (if it would still exist after patching those Intel-specific
> vulnerabilities) as well as lack of some nice features like
> kill-switches (unless a user would DIY them), at least to me the
> choice is obvious:
The laptop I use is a T440s, that's the one I bought when I became a
contractor some 5 years ago and that's the one I still use today. Its
CPU is probably outdated, It only has 8GB of RAM, it probably has an
ME in it (I never even checked if AMT is enabled or not, I never
bother to neutralize the ME, etc..). I have some 10 librems here, but
I only use them for testing, not for actual work.
Why? because to me, I give more value to the machine that I spent
weeks researching and customizing and which I paid a high price for
while I was still unemployed, and I'm used to its crappy screen and
used to its keyboard, etc.. so it has more value to me than one of the
newer librems that are sitting on my desk unused. So no, the choice is
not obvious because each person has different views, values,
preferences, but you keep giving your own opinion as a fact.
So again, my point is : I know very very well what the ME is, but I'm
not worried about it because while I don't *know* for sure, I do
*trust* that it's not and that it doesn't have a backdoor. So I don't
care about it. If you tell me that you found a deliberate backdoor
feature in the ME which can only be accessed by some 3rd party, and
there is no way to disable it, then it's another story, but that's not
the case, all you're saying is that "It's there, for sure, trust me,
because my own fear is proof enough"
And again, I still have no idea what "this brand/model" vs "this other
brand/model" has to do with your tendency to state opinions as fact.

>
> no management engine = one less potential problem, one less headache
> to deal with...
>
Yeah, sure, I'll agree with that 100%, because you're saying it's a
"potential problem". Actually, I'd even say that the ME is a problem,
but because it's closed sourced and not user-replaceable, but I don't
consider it a problem because it's a CIA backdoor. Otherwise every
single proprietary code would be considered as such...

> > 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.
>
I don't see your point, I gave you an analogy to show how ridiculous
your statement was. Sure, you can tape the webcam and microphone, but
it becomes a "taped webcam" not a "disabled spying drone for the US
military". You're completely ignoring my point though.. if you agree
with what I said or have no valid counter argument, then why insist on
replying besides the point?

> > 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] )
>
Again, that's beside the point, the fact that it was disassembled and
people read its assembly and figured out what it did has nothing to do
with your statement of "you can disassemble it, reducing any security
concerns regarding this blob to a minimum" which is, again,
ridiculous, as it can be applied to the ME just as well.
As for your pastebin, I don't know what you mean by "it could be
understood even after a quick glance" cause that's most certainly not
true.

> > We're about to get full control back of the ME. I've been working for
> > the past few weeks on reproducing the PTResearch buffer overflow
> > exploit on the ME, and yesterday they released a PoC for Apollolake
> > (in case you missed it : https://github.com/ptresearch/IntelTXE-PoC),
> > so with the progress I made and with that, I should be able to soon
> > port it to skylake (and write docs on how to port to other platforms
> > as well) which will at least give us the ability to gain back the
> > 'user-controlled' aspect of it as we'd have code execution on it.
>
> Indeed, the things might change if you will find a way to get full
> control back of the ME. If you will discover a way to completely
> "unlock" it and run your own code on it, this Intel Quark CPU core (on
> which Librem 15 Skylake's ME is based) could be really useful - and
> not necessarily for the remote management purposes, perhaps there are
> infinite possibilities of what you could do with this core. So it
> could be turned into the competitive advantage which will be valid
> even from a paranoid point of view. It will be really nice to see it
> happen. But it didn't happen yet - and I am worried that Intel's
> hostile actions might prevent the completion of your benevolent
> research or at least prevent it from going public. Because I remember
> how they took down your "FSP Reverse Engineering" articles as well as
> the source code associated with it. What will prevent them from doing
> it again? And if they can't DMCA your work because the reverse
> engineering is legal at many countries including USA, they could just
> threaten to stop supplying Librem laptops with their CPUs (like they
> probably did) and it's all over now.
Even if I do finish this, the ME wouldn't be "open" because there
would still be code executing from the ROM all the way to the moment
the exploit happens, so it's not a magical solution, but it is better
than nothing and it would give us user-control of the CPU. Also, Intel
didn't "take down" my article, and it had nothing to do with the DMCA
or whatever. It was not a cease&desist letter, it was not an Intel
lawyer contacting us, or anything of the sort. It was a software
manager who sent a nice and respectful email, asking us to remove the
article because the license of the FSP prevents reverse engineering. I
believe we are in the right, and there are plenty of responses we
could have given, but I think it was better to simply remove it
instead of fighting it, no harm done.

>
> 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. 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.
>
That's a very weak argument. The PSP isn't "less sophisticated" than
the ME because it's younger.. that's just not how software works.
Maybe the PSP is smaller/simpler, and therefore less likely to have
bugs that can be exploited, maybe the QA team at AMD is better than
the one at Intel, or that they have additional tests/steps in their
validation. As for "I believe AMD at least will not be as hostile"..
why do you believe that? what makes you believe that? why would you
suggest AMD, a corporation, would be less likely to try and defend
what it considers to be its rights?
That being said, future hardware is not exclusively Intel, all avenues
are explored. If AMD is indeed better, then AMD might be chosen, but
that decision won't be based on "the PSP will be easier to crack
because it's younger" nor will it be based on "for some unknown
reason, AMD will be fine with us reverse engineering it".
Besides, my understanding is that coreboot does not support ryzen
CPUs, so a huge amount of work would be required if we went that way,
no ?

> Best regards,
> Mike
>
> "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
> On Thu, Aug 30, 2018 at 12:41 AM Youness Alaoui
> <kakaroto at kakaroto.homelinux.net> wrote:
> >
> >  Wow, Mike, seriously, I am going to side 100% with Nico, you are
> > spreading FUD, making your own personal opinions (which are themselves
> > derived from other people's FUD) and stating them as the universal
> > law.
> > The ME is not known to be a backdoor. It doesn't mean that it's not a
> > backdoor, it simply means that it's not known to be a backdoor. 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, but
> > there has been a lot of research done on the ME and so far, none have
> > been found as far as I know.
> >
> > Your worry about what the ME does, how it can give someone control
> > over the PC, etc.. are NOT what qualifies it as a "backdoor", but like
> > Nico said, it's a frontdoor, it's not a "hidden access", it's a
> > "promoted access" to the PC, it's the main ME functionality which is
> > well documented. You don't have to use some "only known to some secret
> > person" trick to access the ME, you just need to point your web
> > browser to the right port on localhost.
> > 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! Yeah,
> > sure, that's technically true, it can capture images of you, but only
> > after you plug it in and open an image capture software, and you still
> > have control of those images. The fact that the webcam schematics
> > isn't open means that it could still have a small wifi or GSM chip
> > embedded inside which makes it send the images to the CIA, but it's
> > not a guarantee that it does. So, yes, you can complain that the
> > webcam isn't open hardware so you can't technically trust what it
> > does, but you can't just come out and say with absolute certainty that
> > any and all webcams in the world are spying devices for the CIA,
> > that's just ridiculous.
> >
> > So, back to the ME, we know exactly what it does, it's all extremely
> > well documented and explained, the fact that it allows remote control
> > of the PC is actually the reason for its existence and it's a very
> > very valid reason in the corporate context and the fact that those
> > features also 'coincidentally' resemble the features of an actual
> > 'trojan horse' virus, doesn't mean that the ME itself is a virus..
> > otherwise the 'rm' linux command would be considered a virus since it
> > deletes files and there are some viruses that can delete your files as
> > well....
> > Now the problem is that it's closed source, and not user controlled
> > (remote control features *are* user controlled, I'm talking about
> > being able to replace the firmware with your own), so yes, it can't be
> > audited by the larger open source community, but that also doesn't
> > guarantee any security necessarily (how many open source programs
> > still have security bugs?).
> >
> > Either way, 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".
> >
> > We're about to get full control back of the ME. I've been working for
> > the past few weeks on reproducing the PTResearch buffer overflow
> > exploit on the ME, and yesterday they released a PoC for Apollolake
> > (in case you missed it : https://github.com/ptresearch/IntelTXE-PoC),
> > so with the progress I made and with that, I should be able to soon
> > port it to skylake (and write docs on how to port to other platforms
> > as well) which will at least give us the ability to gain back the
> > 'user-controlled' aspect of it as we'd have code execution on it.
> > Which by the way, also means that BootGuard can be disabled (since the
> > ME is the one checking for the boot guard signatures), which should
> > enable the ability to port coreboot to a lot more machines (including
> > the T450S that this thread is supposed to be about). Hopefully....
> >
> > On Wed, Aug 29, 2018 at 5:50 AM Mike Banon <mikebdp2 at gmail.com> wrote:
> > >
> > > > What suspicious activities? I know, for many people the Intel ME firmware
> > > > contains unwanted features. But these features are documented.
> > > > In your world, a device becomes backdoored because somebody
> > > > didn't read the manual?!?
> > >
> > > Somewhere I've seen a report about Intel ME suspicious network
> > > activities (if I remember correctly they were using Wireshark on a PC
> > > placed between a computer with ME and the outside network) which has
> > > affected my personal opinion. Although it could be argued that its
> > > just some OEM has set up their ME in such a way, maybe even in a
> > > documented way (although a way undesirable to the end user), still it
> > > didn't look good to me. In addition, regarding all those Intel ME
> > > vulnerabilities recently discovered: one could assume that at least
> > > some of these "vulnerabilities" @ were actually the backdoors which
> > > have been patched just because they have been discovered by someone
> > > else than the american intelligence agencies who always knew them @ .
> > > Now Intel has patched these "vulnerabilities", but we do not know if
> > > some other "vulnerabilities" have been left unnoticed by the outsiders
> > > or if some new "vulnerabilities" have been added. And we the open
> > > source enthusiasts can't even verify that personally, because the
> > > source code of Intel ME firmware is closed. I cannot understand, how
> > > such a high level professional open source developer as you, Nico,
> > > finds it okay to just trust Intel ME despite its' deeply proprietary
> > > nature. Management engine with a closed source proprietary firmware -
> > > it even sounds awful..... I totally agree with Richard Stallman when
> > > he calls Intel ME a backdoor - https://stallman.org/intel.html
> > >
> > > > Please read [1] and [2] very carefully, I hope even you will spot
> > > > technical differences. [...] You cannot just take somebody's words
> > > > and give them a different meaning just because somebody else used
> > > > them in a different context. [...] You did it again, btw., stating something
> > > > (definition of frontdoor) and making it look like the generally accepted definition.
> > >
> > > Before receiving your message I knew only one definition of a
> > > "frontdoor" computing term which I described in my previous message.
> > > Although I don't know which definition is more popular, sorry for
> > > misunderstanding you.
> > >
> > > Mike
> > >
> > >
> > > On Wed, Aug 29, 2018 at 12:24 AM Nico Huber <nico.h at gmx.de> wrote:
> > > >
> > > > *sigh*,
> > > >
> > > > On 28.08.2018 22:00, Mike Banon wrote:
> > > > > You are right, my choice of words has been far from ideal. I apologize
> > > > > for that. However, to be confident that Intel ME is a backdoor
> > > > > (personal opinion) - one does not have to be its' creator.
> > > >
> > > > sorry I meant the creator of us (God) not the ME. I doubt the creator
> > > > of the ME knows everybody's opinion either. Which is what I was talking
> > > > about. A good practice is to quote and answer below that quote, this way
> > > > you can easily check if what you write makes sense in the given context.
> > > >
> > > > > I think
> > > > > there are enough documents describing its' functionality and enough
> > > > > evidence gathered by the independent security researchers about the
> > > > > suspicious activities of this hardware module. If it looks like a
> > > > > duck, swims like a duck, and quacks like a duck, then it probably is a
> > > > > duck?
> > > >
> > > > WTF again? what suspicious activities? I know, for many people the ME
> > > > firmware contains unwanted features. But these features are documented.
> > > > In your world, a device becomes backdoored because somebody didn't read
> > > > the manual?!?
> > > >
> > > > > There are no technical differences between the 'backdoor', and
> > > > > 'frontdoor'.
> > > >
> > > > Please read [1] and [2] very carefully, I hope even you will spot tech-
> > > > nical differences.
> > > >
> > > > > Like a 'conspiracy theorist', 'frontdoor' is a term
> > > > > coming from the american 3-letter-agencies. 'Frontdoor' is their term
> > > > > for a 'backdoor' to which only they (currently) have an access. This
> > > > > article summarizes it well:
> > > > > https://www.justsecurity.org/16503/security-front-doors-vs-back-doors-distinction-difference/
> > > > > . 'Backdoor' term has a negative reputation, so they would like to
> > > > > push this 'frontdoor' term forward.
> > > >
> > > > This is very infantile. You cannot just take somebody's words and give
> > > > them a different meaning just because somebody else used them in a dif-
> > > > ferent context. When I say frontdoor, I mean a door at a front where
> > > > everyone can see it. A backdoor implies something hidden, the ME fea-
> > > > tures were never hidden (AFAIK, a stupid OEM may prove me wrong, but I
> > > > don't know any instance).
> > > >
> > > > You did it again, btw., stating something (definition of frontdoor) and
> > > > making it look like the generally accepted definition.
> > > >
> > > > Nico
> > > >
> > > > [1] https://en.wiktionary.org/wiki/back_door
> > > > [2] https://en.wiktionary.org/wiki/front_door