coreboot August 2018

coreboot@coreboot.org

43 participants
110 discussions

Re: [coreboot] REG : GOP Driver
by nagaraj a 30 Aug '18

30 Aug '18

Hi DeVillier, Thanks a lot for the kind response. << Windows is fine as long as valid VBT data has been loaded into the Intel ACPI OpRegion, and the OpRegion is valid/has been fully populated. >> For the above note this holds good for already installed OS. In case if we are trying to install windows OS for the first time and GOP driver is not loaded for the Intel iGPU in that case I understand there will be blank out. Correct me if I'm wrong. //BR Nagaraj A On Thu, 30 Aug 2018, 8:57 pm Matt DeVillier, <matt.devillier(a)gmail.com> wrote: > with Intel iGPUs and using Tianocore UEFI payload, Linux is fine > regardless if the display is initialized or not by GOP driver. Windows is > fine as long as valid VBT data has been loaded into the Intel ACPI > OpRegion, and the OpRegion is valid/has been fully populated. > > On Thu, Aug 30, 2018 at 7:57 AM nagaraj a <nagarajnn(a)gmail.com> wrote: > >> All, >> >> I have query regarding GOP driver in UEFI. Here is query details. >> >> If BIOS don't load UEFI GOP driver for GPU and system boots into OS. >> Will latest windows /linux OS will be up with display or the display will >> be blank out. >> >> //BR >> Nagaraj A >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot > >

1 0

Re: [coreboot] T450S + Coreboot
by Nico Huber 30 Aug '18

30 Aug '18

Hi Mike, On 30.08.2018 15:51, Mike Banon wrote: >> The fact that it's closed source and not user-controlled (Even if you had >> the sources, you can't modify them and update it to your custom ME >> version) is where the problem actually is. There *might* be a backdoor >> hidden somewhere in there, or maybe there isn't, nobody knows. > > I agree with your statement above. But, please look on this question > from the end user's perspective, who might be not a software > developer. Imagine that you have a choice between two > similar-by-performance coreboot-supported laptops: according to > cpubenchmark's passmark, Lenovo G505S's AMD A10-5750M = 3342 points > (from 886 samples) while Librem 15's Intel i7-6500U = 4429 points > (from 3345 samples), so the CPU performance difference is just 1/3 ( > and at the fresh test results there might be little to none, since the > Intel-only Meltdown vulnerability requires a patch which eats up to > 30% performance depending on the workload, and there are also some > other Intel-specific "performance-eating" vulnerabilities, the most > serious of which - TLBleed / T1TF - may soon require the disabling of > HyperThreading at all the Intel CPUs, see [1] and [2] ) You are comparing worst case scenarios of one CPU that would be considered secure by current research and one that hasn't been researched as much. That alone doesn't make much sense. Also, why do you assume that one runs untrusted code on his laptop? If one doesn't, he also doesn't need performance eating mitigations for these vulnerabilities. You probably need to do more research about what Meltdown and the Spectre vulnerabilities are and what they imply. >> Your comparison of saying the ME is a backdoor is like saying that a >> webcam is a spying device because it can capture images of you! [...] >> The fact that the webcam schematics isn't open means that it could >> still have a small wifi or GSM chip embedded inside > > Yes, but I could easily put a tape over that webcam, disconnect and > remove a webcam module from the laptop's case (or even make a custom > DIY kill-switch). Same for a microphone - could be easily desoldered > (and maybe soldered back but through a kill-switch). And for the > speakers: according to the recent researches the speakers could act as > a microphone - see [3] - so Librem 15 should have a kill-switch for > the speakers as well. Meanwhile you can't throw away ME the same easy > way. Your are talking past each other. That you can put some tape over a webcam doesn't answer the question if you should call it a spying device. What if you buy a webcam to use it as webcam? is it a spying device? > >> you yourself said earlier, when talking about the AtomBIOS >> that "it could be disassembled quite well with AtomDis - >> https://github.com/mikebdp2/AtomDis - reducing any security concerns >> regarding this blob to a minimum.", well, the ME can be disassembled >> with any x86 disassembler, so why can't you also say that "reduces any >> security concerns regarding the ME to a minimum". > > Actually this AtomBIOS blob is not required to run this laptop, only > to initialize its' display. It is possible to turn this laptop into a > miniPC/server and still use its' hardware without this blob, although > it wouldn't be exactly a laptop after that. But if we would consider > this blob as required: here is a quality of disassembly I'm getting > with AtomDis - https://pastebin.com/xKW9FV58 . All the command tables > and data tables are named and in many cases it could be understood > what some particular piece of code is doing even after a quick glance. > Are you sure that your ME blob x86 disassembly is providing a similar > or higher level of transparency? Perhaps it is this level of > transparency which allowed to 95% complete the development of the > opensource AtomBIOS alternative called OpenAtom ( I think the > development efforts have stopped partially because no-one have noticed > any backdoors after completing the 95% and it became much less > interesting to complete the remaining 5% , [4] ) Can you point me to these 95%? What I see in the repository is rather 1% (I only see a replay). Maybe I'm just looking at the wrong files. Regarding the disassembly, I don't understand shit in there (and I've written display init code myself). > Actually it might be a good idea for Purism to at least consider the > switch to AMD Ryzen CPUs. Yes, unlike the 15h/early16h gen AMD CPUs, > their new Ryzen CPUs contain the PSP, Platform Security Processor - > which is also a management engine. But it is significantly younger > than Intel ME (Skylake's ME is already generation 11), so PSP should > have less sophisticated protections and it should be easier to > "jailbreak" this "young PSP" rather than "modern ME". Early ME > implementations were also weak, after all, and I expect "young PSP" to > be weak also. I agree that Purism should evaluate AMD options. Actually I assume, they do. Saying that a younger version is less sophisticated seems odd though, as the vulnerabilities in ME11 didn't exist earlier. Also, investing in a platform that you would have to "jailbreak" is wrong. You'd be giving them money for something you don't want. > Also, those AMD CPUs do not suffer from the > recently-discovered Intel-specific vulnerabilities and their > performance-degrading patches will not be required. Finally, AMD had a > good collaboration history with coreboot (although this collaboration > is not active currently, it might be renewed if there will be enough > mutual interest) - and I believe AMD at least will not be as hostile > towards your opensource/reverse-engineering efforts as Intel is > currently. If any of these statements seems reasonable to you, please > think of trying to make your Purism company to at least consider this > AMD switch. Again, that AMD CPUs don't suffer as much from the research of Intel CPUs as Intel CPUs seems clear. You are assuming that there are less problems in AMD CPUs. I assume that there is less research on AMD CPUs. Maybe AMD is not hostile against reverse engineering. But you seem to forget that they don't provide any documentation at all atm (for fam17h/ Ryzen) to write firmware. If you want to get coreboot running on Ryzen, you better start collecting funds, maybe $500k for a kick off? Nico > "disable Intel hyperthreading" : > [1] - https://news.ycombinator.com/item?id=17829790 > [2] - https://marc.info/?l=openbsd-tech&m=153504937925732&w=2 > speaker as a microphone: > [3] - https://security.stackexchange.com/questions/154343/can-a-speaker-be-used-a… > [4] - https://mail.coreboot.org/pipermail/coreboot/2018-January/085979.html

1 0

Re: [coreboot] REG : GOP Driver
by Matt DeVillier 30 Aug '18

30 Aug '18

with Intel iGPUs and using Tianocore UEFI payload, Linux is fine regardless if the display is initialized or not by GOP driver. Windows is fine as long as valid VBT data has been loaded into the Intel ACPI OpRegion, and the OpRegion is valid/has been fully populated. On Thu, Aug 30, 2018 at 7:57 AM nagaraj a <nagarajnn(a)gmail.com> wrote: > All, > > I have query regarding GOP driver in UEFI. Here is query details. > > If BIOS don't load UEFI GOP driver for GPU and system boots into OS. > Will latest windows /linux OS will be up with display or the display will > be blank out. > > //BR > Nagaraj A > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] T450S + Coreboot
by Mike Banon 30 Aug '18

30 Aug '18

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 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. 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. 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-a… [4] - https://mail.coreboot.org/pipermail/coreboot/2018-January/085979.html On Thu, Aug 30, 2018 at 12:41 AM Youness Alaoui <kakaroto(a)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(a)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(a)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-disti… > > > > . '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

1 0

REG : GOP Driver
by nagaraj a 30 Aug '18

30 Aug '18

All, I have query regarding GOP driver in UEFI. Here is query details. If BIOS don't load UEFI GOP driver for GPU and system boots into OS. Will latest windows /linux OS will be up with display or the display will be blank out. //BR Nagaraj A

1 0

Re: [coreboot] T450S + Coreboot
by Brian Herman 30 Aug '18

30 Aug '18

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 < kakaroto(a)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(a)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(a)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-disti… > > > > . '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(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] T450S + Coreboot
by Youness Alaoui 29 Aug '18

29 Aug '18

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(a)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(a)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-disti… > > > . '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

1 0

Fwd: USB to Serial Converters
by zahra rahimkhani 29 Aug '18

29 Aug '18

Hello Friends , I compiled Coreboot 4.5 for Minnow board max and see this message in consol. "Memory Configure Data Hob is not present. Not updating MRC data in flash." what is Data Hob? Cold you help me how to solve it? Best wishes , Zhara ---------- Forwarded message --------- From: zahra rahimkhani <zrahimkhani2014(a)gmail.com> Date: Tue, Aug 21, 2018 at 4:52 PM Subject: Fwd: [coreboot] USB to Serial Converters To: cc: Coreboot <coreboot(a)coreboot.org> ---------- Forwarded message --------- From: zahra rahimkhani <zrahimkhani2014(a)gmail.com> Date: Sat, Aug 18, 2018 at 12:47 PM Subject: Re: [coreboot] USB to Serial Converters To: David Hendricks <david.hendricks(a)gmail.com> Hello David Thank you very much for your help . I used version 4.8 but it shows this message on consol and do not boot usb flash or sata. Running option rom at c000:0003 Turning on vga text mode console SeaBIOS (version rel-1.11.2-0-gf9626cc) EHCI init on dev 00:1d.0 (regs=0xd061e020) WARNING - Timeout at i8042_flush:71! AHCI controller at 00:13.0, iobase 0xd061d000, irq 10 Searching bootorder for: /pci@i0cf8/*@12 Found 0 lpt ports Found 1 serial ports Searching bootorder for: /pci@i0cf8/usb@1d/hub@1/storage@1/*@0/*@0,0 Searching bootorder for: /pci@i0cf8/usb@1d/hub@1/usb-*@1 USB MSC vendor='UFD 2.0' product='Silicon-Power8G' rev='1100' type=0 removable=1 USB MSC blksize=512 sectors=15730688 Initialized USB HUB (1 ports used) All threads complete. Scan for option roms Press ESC for boot menu. Searching bootorder for: HALT drive 0x000f62c0: PCHS=0/0/0 translation=lba LCHS=979/255/63 s=15730688 Space available for UMB: cd800-ed800, f5b60-f62c0 Returned 253952 bytes of ZoneHigh e820 map has 18 items: 0: 0000000000000000 - 000000000009fc00 = 1 RAM 1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED 2: 00000000000f0000 - 0000000000100000 = 2 RESERVED 3: 0000000000100000 - 0000000020000000 = 1 RAM 4: 0000000020000000 - 0000000020100000 = 2 RESERVED 5: 0000000020100000 - 000000007ad9c000 = 1 RAM 6: 000000007ad9c000 - 0000000080000000 = 2 RESERVED 7: 00000000e0000000 - 00000000f0000000 = 2 RESERVED 8: 00000000feb00000 - 00000000fec01000 = 2 RESERVED 9: 00000000fed01000 - 00000000fed02000 = 2 RESERVED 10: 00000000fed03000 - 00000000fed04000 = 2 RESERVED 11: 00000000fed05000 - 00000000fed06000 = 2 RESERVED 12: 00000000fed08000 - 00000000fed09000 = 2 RESERVED 13: 00000000fed0c000 - 00000000fed10000 = 2 RESERVED 14: 00000000fed1c000 - 00000000fed1d000 = 2 RESERVED 15: 00000000fee00000 - 00000000fee01000 = 2 RESERVED 16: 00000000fef00000 - 00000000ff000000 = 2 RESERVED 17: 00000000ff800000 - 0000000100000000 = 2 RESERVED enter handle_19: NULL Booting from Hard Disk... Booting from 0000:7c00 I would be grateful if you guide me . I should set a special config or no? Best , Zahra On Sun, Aug 5, 2018 at 4:35 PM David Hendricks <david.hendricks(a)gmail.com> wrote: > Hi Zahra, > Yes, I used the 6-pin serial port header. Also, make sure the microcode > header(s) you include correspond to the CPUID of your processor. The E3825 > and E3826 use different microcode headers, so M0130679901.h will not work > for you. > > Please keep the coreboot mailing list CC'd. I haven't done anything with > Minnowboard in several months and others may be able to help. > > On Thu, Aug 2, 2018 at 5:01 PM, zahra rahimkhani < > zrahimkhani2014(a)gmail.com> wrote: > >> Hi David >> >> Thank you for your help. >> I extract your file and got M0130679901.h as Microcode but my board does >> not work it did not show anything. >> I use E3825. >> In previous notes, you told "My guess is that you don't have >> CONFIG_ENABLE_BUILTIN_COM1 selected >> (under "Chipset"), which is an option you have to set in addition to >> the stuff under "Console." >> but in your config, you had not enabled this option. >> Could you help me with this and Did you use 6 pins that are separated >> on board for console port? >> I do not know what is my problem .it did not show anything log. >> >> >> >> Thank you for your time. >> Zahra >> >> >> >> On Wed, Aug 1, 2018 at 2:04 AM David Hendricks <david.hendricks(a)gmail.com> >> wrote: >> >>> Hi Zahra, >>> That header may be out of date >>> (https://mail.coreboot.org/pipermail/coreboot/2017-August/084800.html). >>> >>> I had to manually download the microcode file corresponding to my >>> processor SKU from Intel. Use the link I sent you earlier to download >>> Baytrail_FSP_Gold4.tgz and see if the microcode headers included in >>> that tarball match your processor. The Atom on my Minnowboard Turbot >>> has a CPUID of 30679, so I needed to use M0130679901.h. >>> >>> (note that the Minnowboard Max uses an Atom E3825, while the Turbot >>> uses an E3826 dual-core SoC or E3845 quad-core SoC) >>> >>> On Mon, Jul 30, 2018 at 2:36 AM, zahra rahimkhani >>> <zrahimkhani2014(a)gmail.com> wrote: >>> > >>> > Dear David >>> > >>> > for Microcode file I just it from coreboot source from this path >>> > coreboot/3rdparty/blobs/soc/intel/baytrail/microcode_blob.h >>> > >>> > Is that good ? >>> > >>> > Thanks , >>> > >>> > >>> > On Sun, Jul 29, 2018 at 1:18 PM zahra rahimkhani < >>> zrahimkhani2014(a)gmail.com> >>> > wrote: >>> >> >>> >> Hi David, >>> >> >>> >> Thank you very much for your guide. >>> >> >>> >> I got this comments on my config and changes it based on your config. >>> >> But I can not see any thing on output. >>> >> Could you tell me which Uart pins do you use on Minnowboard max >>> >> >>> >> I used it 6 pin that are separately on board . >>> >> >>> >> I would be grateful if you guide me . >>> >> I got my new config here . >>> >> https://paste.flashrom.org/view.php?id=3097 >>> >> >>> >> Also , Could you tell me what is this parameter >>> >> CONFIG_UART_FOR_CONSOLE=0 >>> >> and >>> >> CONFIG_DRIVERS_UART_8250IO >>> >> >>> >> Cheers! >>> >> Zahra >>> >> >>> >> >>> >> >>> >> On Fri, Jul 27, 2018 at 11:06 AM David Hendricks >>> >> <david.hendricks(a)gmail.com> wrote: >>> >>> >>> >>> Hi Zahra, >>> >>> >>> >>>> I got my config file here >>> >>>> https://paste.flashrom.org/view.php?id=3096 >>> >>> >>> >>> >>> >>> Thanks, that helps a lot! >>> >>> >>> >>> The last config that I tested is >>> >>> >>> https://review.coreboot.org/cgit/board-status.git/plain/intel/minnowmax/4.6… >>> >>> >>> >>> If you diff my config and yours, it seems you have several options >>> >>> disabled which I think you should try enabling: >>> >>> CONFIG_HAVE_IFD_BIN >>> >>> CONFIG_HAVE_ME_BIN >>> >>> CONFIG_TTYS0_LCS >>> >>> CONFIG_DRIVERS_UART_8250IO >>> >>> CONFIG_IFD_BIN_PATH >>> >>> CONFIG_ME_BIN_PATH >>> >>> CONFIG_LOCK_MANAGEMENT_ENGINE >>> >>> CONFIG_DRIVERS_UART >>> >>> CONFIG_CONSOLE_SERIAL >>> >>> CONFIG_CONSOLE_SERIAL_115200 >>> >>> >>> >>> You can find these by using the search function in `make menuconfig`. >>> >>> Press '/' and type a Kconfig option. >>> >>> >>> >>>> I would be grateful if you check my config and tell me what is >>> ifdtool >>> >>>> in Coreboot and how >>> >>>> I use it. >>> >>>> and How I find Intel ME file for my board and GBE for a network on >>> my >>> >>>> board. >>> >>> >>> >>> >>> >>> ifdtool is a tool for viewing and manipulating an Intel Flash >>> Descriptor >>> >>> binary. The flash descriptor is a 4KB data structure at the start of >>> the >>> >>> ROM's address space (offset 0x000000-0x000fff). >>> >>> >>> >>> To build it: `make -C util/ifdtool` >>> >>> To run it: `util/ifdtool/ifdtool` >>> >>> >>> >>> You'll probably want to use the '-x' option to extract the individual >>> >>> modules from an existing Minnowboard Max firmware image (e.g. the >>> UEFI image >>> >>> that comes with the board). That will give you the ME and GBE files. >>> >>> >>> > >>> >> >

1 0

Re: [coreboot] T450S + Coreboot
by Nico Huber 29 Aug '18

29 Aug '18

*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-disti… > . '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

2 1

OSFC Tickets
by Zaolin 29 Aug '18

29 Aug '18

Friendly reminder. 2 days until the ticket sale is closed. Buy your tickets now https://osfc.io/tickets

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot August 2018