[coreboot] T450S + Coreboot

Angel Pons th3fanbus at gmail.com
Fri Aug 31 04:01:25 CEST 2018


Hello again,

> Sorry, I'm going to read the documentation more and make this a
> personal goal by the end of 2019. I didn't want to stir up so much
> drama. Time and money are not constraints on this particular
> problem. One way or another by January 22, 2019 I will have either
> figured it out or I will pay to figure it out. I have used Linux since
> college. I have no kids. I have no girlfriend. I have tons of free time.

Pardon my understanding, or its lack thereof: What will you have
figured out or will have paid to figure out?
If you are referring about Intel Boot Guard, only Intel and/or Lenovo
have the information to bypass it, and I don't believe neither of them
will be willing to give away control over Boot Guard, since it is a
security "feature" (defective by design IMHO). Disclosing information
such as keys or bypass methods would imply knowingly creating a
backdoor, which can be severely damaging to either business'
reputation should this backdoor be made public. I would not expect
neither Intel nor Lenovo to release any material.
If you want some personal goals, I have some recommendations: Get
something that is easy to get coreboot on such as a mainboard that is
already supported, or one with supported chips but not supported by
coreboot yet. If getting the latter option, I feel the easiest boards
to port to coreboot are Ivy/Sandybridge desktop boards. If the
mainboard's SuperIO is supported as well, porting such a board is
easy. I have ported two boards like that, and it is in fact easy.

> according to cpubenchmark's passmark

I find it rather puzzling that you are using the performance scores
provided by such a thing, and at the same time complaining about the
openness of the ME.

> I might be saying wrong things here but aren't ALL cpus affected by
> meltdown?

Not all, IIRC Meltdown (CVE-2017-5754) affects mainly Intel and ARM
chips. And on Intel CPUs, the newer the CPU is, the lower the
performance impact is because of better hardware mechanisms (PCID I
think?).
Regarding AMD, I recall reading Meltdown is not an issue and Spectre
Variant 2 (CVE-2017-5715) is ineffective compared to Intel, but I am
not sure of the latter claim since I barely read about this topic.

> Most CPU's require microcode updates as there are critical errors in
> manufacturing microcode.

Spectre Variant 3a (CVE-2018-3640) seems to be fixed by microcode
updates only, accoring to Intel. And this is not the only error that
has been found in microcode.

>> Actually it might be a good idea for Purism to at least consider the
>> switch to AMD Ryzen CPUs.
> Absolutely not.
> If anything they should leave x86

Suggesting Ryzen as an alternative to Intel for Purism is, in my view,
rather unsound. There is nothing done for Ryzen in coreboot, and even
if there was (probably lots of money are needed to accomplish this),
what do you do about:
- The PSP? The ME was one of the reasons to drop Intel, but Ryzen has
something similar. This is, in fact, the most meaningless issue.
- Memory/silicon init? Would AMD cooperate and release source
code/full datasheets, or would they distribute a blob like the FSP, if
they release anything at all? This is the biggest issue.
- The VBIOS? Most Intel iGPUs can light up using libgfxinit (or NGI),
but what about AMD? Right now the only reasonable option is the VBIOS
(I don't see any progress being made by AtomDis).
- The XHCI blob? Considered an "optional" blob by some, but is it
optional? There is a ML thread regarding an Intel Denverton board
which seems to lack EHCI controllers. If EHCI disappears from AMD too,
what happens with USB support without that "optional" blob? Should a
PCIe card be used instead? Not an option on laptops!
IMHO these issues make Ryzen for Purism stay as a dream, at least in
the foreseeable future.

I am not an economist, but I strogly consider leaving x86 is a losing
move (if things don't change much). There are far more people locked
on x86 for various reasons than people willing to switch to POWER or
RISC-V. I am not saying such a laptop is a bad idea, but would be met
with little profit (large investment, low return). If x86 starts
losing power to POWER (no pun intended) or RISC-V, then a non-x86
laptop (or any type of computer) may gain traction and sound more
reasonable.

> Ivy/sandy = can nerf to BUP
> post ivy/sandy = kernel still runs
> I would argue there is a big difference there

I thought the large ME change was in Skylake with ME version 11,
according to this: [1]

>> This makes me feel I should recall what Nico told you earlier:
>> "please don't spread FUD on this list."
> It isn't exactly "FUD" to believe that there are undocumented ME
> functions

I feel like the important point in Nico's message is not the "FUD"
itself, but rather "don't spread ... on this list". It does not matter
what you believe in if you keep it for yourself. Spreading your
beliefs as if they were objective information is what starts fires.

> After all ME/PSP was something that no one really asked for

The ME on business computers provides rather useful features for a
company (anti-theft, remote management...), even though the
implementation seems to me defective by design. Probably big companies
pushed forward, maybe Intel wanted it for their own usage... Regarding
PSP, I am afraid I am uninformed.

> My suggestion: pick a laptop or system you like, for whatever reason you like it. And work on it. And produce and upstream code.
> If you do that, and you create more code, you are moving us all to a better place. The more knowledge we can put into source code form, the better.
> And, if you are one of those people moving us to a better place (and you all are, since you are here), please support the others of us who are also trying to do the right thing, maybe in a different way.
> We're all trying to do the right thing. We're all dealing with the compromises that arise from our particular set of decisions. We don't always agree on those choices. I think we should be able to agree that increasing our knowledge and skills as
> we have in this project is good for all.

Ron, those are a true wise man's words. Thank you for reminding what
we should strive for. I feel that is much more productive than
arguing. I realized how pleasing it is to contribute code and feel
something is being produced.

Best regards,

Angel Pons

[1]: https://github.com/corna/me_cleaner/wiki/How-does-it-work%3F



More information about the coreboot mailing list