[coreboot] T450S + Coreboot

[Taiidan at gmx.com]

On 08/30/2018 11:47 AM, Nico Huber wrote:

>> 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 not simply waste money going to
another blobbed never-owner-controlled platform with a now unfriendly
vendor (such a shame AMD used to be really cool with coreboot) and
having to spend even more to create hardware initiation code etc.

Creating a POWER laptop is technically possible thanks to the low power
consumption of POWER9 - and tim said raptor will make one if sales of
the TALOS 2 are good.

The bottom line is that "jailbreaking" is rolling a boulder up a hill
that gets steeper at every rise you get to - you are supporting the
development of further anti-features if you buy new intel/amd hardware
no matter if you manage to make a hack to "free" it or not.

x86 is dead freedomwise - bottom line.

On 08/28/2018 01:50 PM, Th3Fanbus . wrote:
> Taiidan,
> 
>> I doubt those guys have the skill to do so but for those who do - you'd
>> spend tens of thousands in order to have a port for an old machine that
>> still is stuck with ME and hardware init done entirely by binary blobs.
> 
> It is not about the skill or money involved in the process, it is about the
> *possibility* of even running coreboot on said machine, which is most
> likely zer>>
>> I would save your money and instead buy an ivy/sandybridge thinkpad (can
>> nerf the ME - but not disable which is impossible)
> 
> AFAIK, you can still run me_cleaner on a Broadwell laptop. I don't think the
> ME is the main reason to get a XX20/XX30 Thinkpad over newer models.

Ivy/sandy = can nerf to BUP
post ivy/sandy = kernel still runs

I would argue there is a big difference there

> Mike,
> 
>> microcode - is optional
> 
> I assume you refer to microcode *updates*, not the microcode that is
> hard-coded inside the CPU. Still, I fail to understand why there is so much
> worry about microcode updates, as if they were going to open a backdoor
> of some sorts. To me, the only gain of not updating the microcode is in the
> number of bugs.

Mike as I said before too with piledriver cpus you need microcode
updates or you are very easily rooted via the NMI>root exploit.

> I do understand temporarily delaying the updates of known unstable
> microcode versions while awaiting for a fix, though.
> 
>> as far as I know its impossible to completely replace ME, only to trim
>> its' firmware as much as possible and hope for the best that it
>> doesn't have some undocumented "backdoor restore" mechanism that could
>> restore the original uncut blob under some conditions. Undoubtedly,
>> Intel ME is a backdoor, e.g. because it contains some antitheft
>> features which could be used to control your computer remotely: shut
>> it down, wipe or retrieve data from it, etc
> 
> 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 - lots of hardware has undocumented functions or problems that
were later patched out such as the many cisco router rooting functions
"accidently" left in again and again or the recent VIA C3 issue.

I agree that ME isn't really a "backdoor" since being a remote access is
its primary use but in this case a backdoor would be an undocumented
function that persists after one has set remote access to off or used me
cleaner.

I can't understand why some people here think it a conspiracy theory of
the fringe that there just might be an undocumented backdoor in every
computer something I imagine many organizations around the globe are
currently working on if they don't already have one.

After all ME/PSP was something that no one really asked for, IBM has a
supervisor processor with equivilant power (hehe power) however it is
open source and owner controlled no reason they couldn't have done that
here and have the hollywood DRM junk as an addon module so in a way
satisfying everyone.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xDF372A17.asc
Type: application/pgp-keys
Size: 5247 bytes
Desc: not available
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20180830/d7334f08/attachment.skr>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xDF372A17.asc
Type: application/pgp-keys
Size: 5247 bytes
Desc: not available
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20180830/d7334f08/attachment-0001.skr>