Re: [coreboot] T450S + Coreboot
On Sat, Sep 8, 2018 at 2:31 PM Peter Stuge wrote: > > Youness Alaoui wrote: > > So, back to the ME, we know exactly what it does, it's all extremely > > well documented and explained > > I disagree with this. > > It is absolutely true that *some* of what the ME does is extremely well > documented and explained by the vendor, web services APIs and all, but > I would argue that in fact *most* of what the ME does is *not* documented > by the vendor, nor by independent research. > I mostly agree, I was referring to Mike's talk about the remote control features, so yes, I should have said "AMT is well documented", but yes, there are huge portions of what the ME itself does (such as the power on sequence, or what/how it sets some registers) which are totally undocumented. So yes, even if we don't know exactly what the ME does during the power sequence (among other things), we still know that "it initializes hardware", we just don't know how it achieves that task. So we know "what it does", but we don't know "exactly what it does" and we don't know "how it does it", which is where I was wrong in my previous statement. However, we need to differentiate between "this ME is something obscure that we have no idea what it's for" versus "we know what this ME thing is supposed to be for or what it's supposed to be doing, we just have no way to be sure that it doesn't do anything else or that it does what it's supposed to". I disagree with the idea that the ME is this black box, this sort of "hidden spy device" that gives full remote capabilities to some unknown entity in the same way that I would disagree that because MS Windows is closed source that any Windows machine is fully remote-controlled by M$ employees at any time or that the OS is commissioned by the CIA or whatever. I do agree that because it's closed source, we can't know whether it is or not, but it's just not a guarantee that it is. > Since the ME is colocated with the x86 VM host, has access to all x86 VM > memory *and* is a proprietary machine or subsystem I actually don't > believe that we will ever "know exactly what it does". > Well, we could know, if we reverse engineer its code from the maskrom to the BUP, but yes, it would be very hard to fully know for certain. Besides, I'd assume that anything malicious would probably be written in silicon rather than in reverse-engineerable code. So I'd apply the same idea to the whole PCH/CPU. The major problem with the ME when compared to my previous comparison with MS Windows is that we can chose Linux instead of Windows, but we can't choose to disable or to use a custom ME firmware (i.e: the not-user-controlled issue). > > > Now the problem is that it's closed source, and not user controlled > > Right. > > > //Peter > > -- > coreboot mailing list: coreboot@coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] T450S + Coreboot
Youness Alaoui wrote: > So, back to the ME, we know exactly what it does, it's all extremely > well documented and explained I disagree with this. It is absolutely true that *some* of what the ME does is extremely well documented and explained by the vendor, web services APIs and all, but I would argue that in fact *most* of what the ME does is *not* documented by the vendor, nor by independent research. Since the ME is colocated with the x86 VM host, has access to all x86 VM memory *and* is a proprietary machine or subsystem I actually don't believe that we will ever "know exactly what it does". > Now the problem is that it's closed source, and not user controlled Right. //Peter -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] T450S + Coreboot
On Wed, August 29, 2018 9:41 pm, Youness Alaoui wrote: > > 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 Look forward to this. Would be good to regain control of parts I paid good money for. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] T450S + Coreboot
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
Re: [coreboot] T450S + Coreboot
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. Just my take. ron p.s. Mike, just one thing. If you have never installed coreboot before, your first trip should be on a system known to work, before you start on a system not known to work. It's harder than it looks. p.p.s. I keep telling folks that the coreboot conference (now osfc) is the most fun, and interesting, and creative event I get to go to. I am really looking forward to seeing you all again! -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] T450S + Coreboot
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. 0xDF372A17.asc Description: application/pgp-keys 0xDF372A17.asc Description: application/pgp-keys -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] T450S + Coreboot
I agree that the G505S is a superior choice vs the ivy/sandy thinkpads as it has no ME/PSP thus making it the newest and last owner controlled x86 laptop but everyone be aware that it NEEDS a microcode update or you are very easily rooted due to the piledriver+ NMI CPU exploit additionally without the microcode the IOMMU won't work (and thus no qubes) Most CPU's require microcode updates as there are critical errors in manufacturing microcode. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] T450S + Coreboot
On Thu, Aug 30, 2018 at 9:51 AM Mike Banon 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
Re: [coreboot] T450S + Coreboot
On Thu, Aug 30, 2018 at 2:15 AM Brian Herman wrote: > > 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. > Sorry to see your thread going off-topic. I don't know if it will help you but I've wirtten detailed blog posts on my experience in getting coreboot to work on the broadwell and skylake librems. It's not a "guide how to port to coreboot" but it explains some of the problems I've had and it might help you save some time. You can go to https://puri.sm/coreboot/timeline/ and search for "Youness" to see my blog posts in chronological order on the right side bar. Good luck with your project! > Make It So, > Brian Herman > > > > > > > > > > > > So you have made it to the end.. > Thanks for reading! > > On Wed, Aug 29, 2018 at 4:42 PM Youness Alaoui > 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
Re: [coreboot] T450S + Coreboot
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
Re: [coreboot] T450S + Coreboot
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] ) 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: no management engine = one less potential problem, one less headache to deal with... > 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. > 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] ) > 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
Re: [coreboot] T450S + Coreboot
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. Make It So, Brian Herman So you have made it to the end.. Thanks for reading! On Wed, Aug 29, 2018 at 4:42 PM Youness Alaoui < kakar...@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 wrote: > > > > > What suspicious activities? I know, for many people the Intel ME > firmware > > > contains unwanted features. But these features are
Re: [coreboot] T450S + Coreboot
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 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
Re: [coreboot] T450S + Coreboot
> 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 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 -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] T450S + Coreboot
*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 -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] T450S + Coreboot
Hi Nico, 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. 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? There are no technical differences between the 'backdoor', and 'frontdoor'. 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. Mike On Tue, Aug 28, 2018 at 9:20 PM Nico Huber wrote: > > Hi Mike, > > you can be as much biased as you want, and you can express that here. I > have no trouble with that. What I don't like is your choice of words. > For instance with "Undoubtedly, Intel ME is a backdoor," you imply to > know everybody's opinion on the matter. Because I don't think you are > the creator himself, this draws a big WTF? into my brain. > > You can say "In my opinion, Intel ME is a backdoor, ..." but you can't > say it's undoubted. I don't only doubt that, IMHO, it is a frontdoor. > > You also claim that things are well studied which are not. A replay of > a proprietary program might be open-source technically, but it doesn't > mean that anybody has a clue how it works. > > So please, if you want to express your *personal* opinion or "knowledge" > please always state so. And don't make it look like the general under- > standing (especially not when experts disagree). > > Nico -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] T450S + Coreboot
Hi Mike, you can be as much biased as you want, and you can express that here. I have no trouble with that. What I don't like is your choice of words. For instance with "Undoubtedly, Intel ME is a backdoor," you imply to know everybody's opinion on the matter. Because I don't think you are the creator himself, this draws a big WTF? into my brain. You can say "In my opinion, Intel ME is a backdoor, ..." but you can't say it's undoubted. I don't only doubt that, IMHO, it is a frontdoor. You also claim that things are well studied which are not. A replay of a proprietary program might be open-source technically, but it doesn't mean that anybody has a clue how it works. So please, if you want to express your *personal* opinion or "knowledge" please always state so. And don't make it look like the general under- standing (especially not when experts disagree). Nico -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] T450S + Coreboot
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 zero. > 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. 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. 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." Regards, Angel Pons -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] T450S + Coreboot
Hi Nico, Although it can't be denied that I'm a bit biased here (since I own that G505S), I'm less critical towards G505S blobs partially because some of these blobs are indeed completely optional (e.g. xHCI - never used it; microcode - is optional if you don't need a stable low level Xen HVM virtualization) while others have been studied very well - to a point where the almost working opensource replacements of them have been created. For example, AtomBIOS - https://github.com/alterapraxisptyltd/openatom , also it could be disassembled quite well with AtomDis - https://github.com/mikebdp2/AtomDis - reducing any security concerns regarding this blob to a minimum. Also there aren't any blobs which are locked down and could not be replaced completely, so currently that seems to be the most powerful laptop which has some chance to be FSF RYF'ed eventually. Meanwhile, 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 Mike On Tue, Aug 28, 2018 at 11:20 AM Nico Huber wrote: > > Hi Mike, > > please don't spread FUD on this list. > > On 28.08.2018 09:54, Mike Banon wrote: > > And even if there weren't any problem with Intel Boot Guard, its not > > that easy to add a support for new board (impossible to do it over > > weekends, especially for the newcomers). > > The T450s would probably benefit a lot from the existing support for > ThinkPads. But Broadwell really isn't a weekend port (Sandy or Ivy > Bridge would be for a ThinkPad) because we have few Broadwell ports > and an ugly blob situation. > > Anyway, chances are close to 100% that the T450s has BootGuard in > verification mode. > > > If I were you I would have > > sold these T450S and bought some machine already supported by > > coreboot. It could be one of those Intel Thinkpads (although you'll > > have to spend time cleaning Intel ME) > > You don't *have to* spend time cleaning the ME, you *can* spend time > with it. It is actually unknown if that lowers or highers security, > so there is really no reason to advice to do it (unless you need more > flash space for fancy stuff). > > > or maybe Lenovo G505S quadcore > > AMD laptop which doesn't have any Intel ME / AMD PSP backdoors in its' > > CPU at all - so no need to clean anything. > > The G505s requires a lot of other blobs, IIRC: xHCI (optional), AtomBIOS > for GFX (which even runs in the OS on the host CPU), maybe more I don't > remember. I don't see how that is better (you seemed to want to sell > that by only stating absence of blobs, ignoring those it has instead). > > Nico -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] T450S + Coreboot
Pointless IMO. 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. I would save your money and instead buy an ivy/sandybridge thinkpad (can nerf the ME - but not disable which is impossible) or a G505S (owner controlled, no ME/PSP) and maybe also buy a KCMA-D8 (libre firmware, no ME/PSP thus owner controlled and can play the latest games at max settings in a VM with a good AMD graphics card) or TALOS 2 (open source firmware, it is a brand new high performance OpenPOWER system, it is a true special rarity) etc. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] T450S + Coreboot
hi, at the current state it is not possible to properly install Coreboot to a ThinkPad, that is newer than the **3* series, because since Haswell, Intel introduced a new technology called "Intel Boot Guard"- which prevents any firmware that is not signed by Intel firmware to be used by the device. Therefore, no effort went into these devices yet, and probably never will, until there is a way to disable it permanently. Best regards Sellerie/Christoph Pomaska Am 27. August 2018 03:24:47 schrieb Brian Herman : I am in contact with a person with the means to reprogram a T450S. https://www.allservice.ro/forum/viewtopic.php?t=1311 What would I have to do to make coreboot work? I think I would have to have two laptops or at least motherboards right? -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] T450S + Coreboot
Hi Mike, please don't spread FUD on this list. On 28.08.2018 09:54, Mike Banon wrote: > And even if there weren't any problem with Intel Boot Guard, its not > that easy to add a support for new board (impossible to do it over > weekends, especially for the newcomers). The T450s would probably benefit a lot from the existing support for ThinkPads. But Broadwell really isn't a weekend port (Sandy or Ivy Bridge would be for a ThinkPad) because we have few Broadwell ports and an ugly blob situation. Anyway, chances are close to 100% that the T450s has BootGuard in verification mode. > If I were you I would have > sold these T450S and bought some machine already supported by > coreboot. It could be one of those Intel Thinkpads (although you'll > have to spend time cleaning Intel ME) You don't *have to* spend time cleaning the ME, you *can* spend time with it. It is actually unknown if that lowers or highers security, so there is really no reason to advice to do it (unless you need more flash space for fancy stuff). > or maybe Lenovo G505S quadcore > AMD laptop which doesn't have any Intel ME / AMD PSP backdoors in its' > CPU at all - so no need to clean anything. The G505s requires a lot of other blobs, IIRC: xHCI (optional), AtomBIOS for GFX (which even runs in the OS on the host CPU), maybe more I don't remember. I don't see how that is better (you seemed to want to sell that by only stating absence of blobs, ignoring those it has instead). Nico -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] T450S + Coreboot
And even if there weren't any problem with Intel Boot Guard, its not that easy to add a support for new board (impossible to do it over weekends, especially for the newcomers). If I were you I would have sold these T450S and bought some machine already supported by coreboot. It could be one of those Intel Thinkpads (although you'll have to spend time cleaning Intel ME) or maybe Lenovo G505S quadcore AMD laptop which doesn't have any Intel ME / AMD PSP backdoors in its' CPU at all - so no need to clean anything. More information here - https://www.reddit.com/r/coreboot/comments/98zez2/what_can_the_me_do_when_neutered/e4oln0x/ Best regards, Mike Banon On Tue, Aug 28, 2018 at 2:07 AM Th3Fanbus . wrote: > > Hello Brian, > > As far as I am concerned, Haswell or newer ThinkPads ship with Intel Boot > Guard enabled in Verified Mode. This prevents coreboot from running on them. > I assume this is the case on your machine as well, thus I advise you to check > before proceeding, to avoid wasting time. > > Best regards, > > Angel Pons > > On Tue, Aug 28, 2018, 00:48 Brian Herman wrote: >> >> im sorry i should really read the documentation first i want to create the >> support for a t450s ill do that this weekend >> >> Sent from my iPhone >> >> > On Aug 27, 2018, at 8:34 AM, Mike Banon wrote: >> > >> > Sorry but T450S is not supported by coreboot. >> > Here is a list of laptops that ARE supported: >> > https://www.coreboot.org/Supported_Motherboards/old >> > On Mon, Aug 27, 2018 at 4:23 AM Brian Herman >> > wrote: >> >> >> >> I am in contact with a person with the means to reprogram a T450S. >> >> https://www.allservice.ro/forum/viewtopic.php?t=1311 >> >> What would I have to do to make coreboot work? >> >> I think I would have to have two laptops or at least motherboards right? >> >> -- >> >> coreboot mailing list: coreboot@coreboot.org >> >> https://mail.coreboot.org/mailman/listinfo/coreboot >> >> -- >> coreboot mailing list: coreboot@coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] T450S + Coreboot
Hello Brian, As far as I am concerned, Haswell or newer ThinkPads ship with Intel Boot Guard enabled in Verified Mode. This prevents coreboot from running on them. I assume this is the case on your machine as well, thus I advise you to check before proceeding, to avoid wasting time. Best regards, Angel Pons On Tue, Aug 28, 2018, 00:48 Brian Herman wrote: > im sorry i should really read the documentation first i want to create the > support for a t450s ill do that this weekend > > Sent from my iPhone > > > On Aug 27, 2018, at 8:34 AM, Mike Banon wrote: > > > > Sorry but T450S is not supported by coreboot. > > Here is a list of laptops that ARE supported: > > https://www.coreboot.org/Supported_Motherboards/old > > On Mon, Aug 27, 2018 at 4:23 AM Brian Herman > > wrote: > >> > >> I am in contact with a person with the means to reprogram a T450S. > >> https://www.allservice.ro/forum/viewtopic.php?t=1311 > >> What would I have to do to make coreboot work? > >> I think I would have to have two laptops or at least motherboards right? > >> -- > >> coreboot mailing list: coreboot@coreboot.org > >> https://mail.coreboot.org/mailman/listinfo/coreboot > > -- > coreboot mailing list: coreboot@coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot > -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] T450S + Coreboot
im sorry i should really read the documentation first i want to create the support for a t450s ill do that this weekend Sent from my iPhone > On Aug 27, 2018, at 8:34 AM, Mike Banon wrote: > > Sorry but T450S is not supported by coreboot. > Here is a list of laptops that ARE supported: > https://www.coreboot.org/Supported_Motherboards/old > On Mon, Aug 27, 2018 at 4:23 AM Brian Herman > wrote: >> >> I am in contact with a person with the means to reprogram a T450S. >> https://www.allservice.ro/forum/viewtopic.php?t=1311 >> What would I have to do to make coreboot work? >> I think I would have to have two laptops or at least motherboards right? >> -- >> coreboot mailing list: coreboot@coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] T450S + Coreboot
Sorry but T450S is not supported by coreboot. Here is a list of laptops that ARE supported: https://www.coreboot.org/Supported_Motherboards/old On Mon, Aug 27, 2018 at 4:23 AM Brian Herman wrote: > > I am in contact with a person with the means to reprogram a T450S. > https://www.allservice.ro/forum/viewtopic.php?t=1311 > What would I have to do to make coreboot work? > I think I would have to have two laptops or at least motherboards right? > -- > coreboot mailing list: coreboot@coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
