coreboot May 2017

coreboot@coreboot.org

70 participants
202 discussions

Re: [coreboot] Remote security exploit in all 2008+ Intel platforms
by Nico Huber 04 May '17

04 May '17

On 03.05.2017 09:28, Zoran Stojsavljevic wrote: >> The reason we want to prioritize the ME vs. the FSP, is because a lot > more people were interested in getting rid of the ME, >> so it is a higher priority, *but the FSP is also going to be reversed > eventually and coreboot deblobbed entirely*. > > This is very serious claim, Youness. In FSP you do have much more than ONLY > MRC (actually, several MRC algorithms, a bunch tied/bundled together, > depending upon what the initial DRAM SPD discovery mechanism is, my best > guess). You do have BSP CPU init, then APP CPU(s) init(s), and then PCH > init as well, on the system registry level. There is also platform init > phase in there, the very minimal one. Also I throw-in PCIe discovery > algorithm. Serious stuff. Serious stuff, sure. But it has been done before (without anyone being payed for it, FWIW). And compared to the ME firmware we know what it has to do _and_ don't have to hack into anything to get our code run- ning. > > If you ask me, I would keep up with disabling ME on application level > (since ME FW booting is A MUST, as my best understanding of ME FW stands > for now). In other words, if I guessed correctly, to make newest ME 11.x > engine, based on x86 HW (quark most likely), to run idler process all the > time, if Dmitry is correct, and we have MINIX3 micro-kernel running on the > top of quark there. > > Divide and Conquer, the evergreen idiom: first to take ME, FSP should come > after (they can be well divided)... ;-) Why ME first? What is a free ME good for if you don't control the main (um, how to call it if both are x86?) processor? Nico

2 1

PCIe Role-based error reporting
by Youness Alaoui 03 May '17

03 May '17

Hi, I'm looking at the src/device/pciexp_device.c file trying to understand what it does and I've noticed this in pciexp_enable_aspm : /* Enable ASPM role based error reporting. */ devcap = pci_read_config32(endp, endp_cap + PCI_EXP_DEVCAP); devcap |= PCI_EXP_DEVCAP_RBER; pci_write_config32(endp, endp_cap + PCI_EXP_DEVCAP, devcap); This looks like it tries to write a bit to 1 to enable Role-based error-reporting in the DEVCAP (offset 0x04) in the PCIe capability, but according to the spec (looking at page 612 of the spec version 3.0 that I found here : http://composter.com.ua/documents/PCI_Express_Base_Specification_Revision_3…), that structure is read-only (it's the device capabilities register, not the device control register). Is that an error ? I tracked that code (moved, then moved again) all the way to this change from 2011 : https://review.coreboot.org/#/c/735/ but for some reason git blame can't find the file in commits before that. That code is probably harmless since it's a Read-only field anyways, but I'm wondering if the code that should be there shouldn't instead be enabling the bits 0:3 in the device control register to enable the error reporting. Also, I don't see how this actually relates to ASPM (it only gets called if ASPM is enabled). Does anyone know if I'm on the right track in my interpretation or if I misunderstood the spec or what that code is meant to do ? Thanks, Youness.

1 0

ASUS KGPE-D16 Automated Test Failure [master]
by Raptor Engineering Automated Coreboot Test Stand 03 May '17

03 May '17

The ASUS KGPE-D16 fails verification for branch master as of commit 21b08522c27f2e70a081f4634dc0404c7eeb94f9 The following tests failed: BOOT_FAILURE Commits since last successful test: 21b0852 google/gru: skip usbphy1 setup for Scarlet See attached log for details This message was automatically generated from Raptor Engineering's ASUS KGPE-D16 test stand Want to test on your own equipment? Check out https://www.raptorengineering.com/content/REACTS/intro.html Raptor Engineering also offers coreboot consulting services! Please visit https://www.raptorengineering.com for more information Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineering.com> regarding any issues stemming from this notification

1 0

Re: [coreboot] Remote security exploit in all 2008+ Intel platforms
by Nico Huber 03 May '17

03 May '17

On 03.05.2017 01:39, Youness Alaoui wrote: > to answer Nico's other post: > I'm quite surprised and disappointed by your answer. You have every right > to say that you are disappointed or distrusting Purism due to past actions, > but I find it harsh for you to be repeatedly saying "fraud" and "scammed" > when that is not the case at all. I think Ron has responded quite well to > that and said exactly what I wanted to say, there is a difference between > being naive and underestimating the task, vs actively "trying to scam > people". If they were scamming people, they wouldn't have shipped any > product and they wouldn't have reimbursed those who changed their mind or > were unsatisfied with what they got, and actually, I wouldn't even have > been contracted in the first place. Finally! I was hoping for some statement like this. I didn't know about any reimbursement taking place. See, what was publicly visible was some drawing of customers away from free firmware supporting vendors. Amend- ments were not publicly visible, FWIW. OTOH, the way you wrote it im- plies that only those who complained got a refund, or was the reimburse- ment an explicit offer? > Attributing to malice what was the result of honest mistakes, while you > know how complex this is both on the software and hardware side, is why > your tone was disappointing. Careless name-calling leads to people getting > hurt and flame wars and all that. Carelessly promising free software (that is impossible to deliver) with the name of free projects on it... I think that was a huge offense to many developers. Don't you think that hurt people too? So don't tell me I started this. > I would just like to answer you with a few more items that I believe are > true (I may be mistaken myself as I'm still quite new to Purism): > > - Everything that was promised is still on the roadmap and a > work-in-progress (as far as I know), so it's more of an issue of missing > the deadlines/estimates rather than not wanting to deliver anything that > was promised. The "Vision" of the company in an initial crowdfunding > campaign does not mean "this is an immediately attainable milestone". We all knew it wasn't attainable in the first place. Also the original promises implied that no money would flow into proprietary software. How can that still be on the roadmap for machines sold years ago? > - The priority was to actually have a working product before working on > its coreboot port (wouldn't you agree that makes more sense?) There were a That makes a lot sense and I guess nobody would complain if it had been advertised as selling a Linux machine to get things started. > ton of issues to solve with production/delivery to begin with, and Purism > is understaffed (most are volunteers as far as I know, and people with the > skills to do a coreboot port are quite rare, as you know... and some that > Purism hired before went dark). It would have been useless to focus all > efforts on coreboot for a hardware product in the making. Purism brought me > on and I had no knowledge of coreboot... let that sink in for a minute: > people able and willing to do that work are so rare that they had to train > one from scratch! They never asked publicly in the coreboot community for help. Let that sink. Who says I wouldn't have taken the job? > - The reason there is no coreboot port for the original Broadwell-based > Librem 15 yet is because the most logical approach was to finalize the > initial work that had been done on the Librem 13 as per Ron's suggestion > (making the learning curve a bit less steep by not having to start from > scratch), and then to prioritize work towards the upcoming hardware so > Purism can attempt to have it ready in time for it to be factory-preloaded > instead of causing additional trouble for future users. The original Librem > 15 is still going to be ported, but I can't do everything at the same time, > so things have to be prioritized. After the initial learning curve, I am > now jumping into the deep end of the coreboot pool by porting a new board > from scratch, so that's definitely an interesting challenge. I'd be glad to help you with that. > - The reason we want to prioritize the ME vs. the FSP, is because a lot > more people were interested in getting rid of the ME, so it is a higher > priority, but the FSP is also going to be reversed eventually and coreboot > deblobbed entirely. Who are these "lot more people"? Customers? Why not tell them (what I believe is true): Trimming the ME firmware is pointless as long as you don't control the host firmware. I really think you should focus on the x86 processor first. It's obvious that it can run with completely free software (in its ISA) and it's clear what the firmware has to do. Also there are people in the community that have experience with it and can help if you get stuck. > - Purism is trying to do the right thing and trying to defend privacy > and security the best way it can (it even became a Social Purpose > Corporation to protect that goal)... but instead of saying "You are > mistaken on this and that, let me enlighten you and help you", you are > instead bashing and trying to drive it into the ground because, for some > reason unknown to me, you feel personally slighted by Purism's legitimate > mistakes? How is that going to help protect people as a whole? It takes > time to do things right, and being stuck in the past does not help things > move forward. Give it a chance! I give it a chance. But I really don't understand how people can down- play what Purism did. It would have been legitimate mistakes if they'd stopped making empty promises after they were told that they scam people. But it took way over a year (just looking at archive.org) to stop it. How can that have been a reputable business? (I don't say they aren't now; just want them to admit their past.) > - What did you see on the website making wrong claims? Let me know and I > will pass on the message to get it fixed. The info on it is a *lot* more > accurate than it was a few months ago, and pretty much any coreboot/ME > claim has clear "work-in-progress" disclaimers along with it (without > writing a huge wall of text on every page). Give me specifics and I'll > forward the information to be corrected. I know there is a best effort to > rectify mistakes and make things clear and unambiguous, if something > remains unclear it's certainly just an oversight, not malice. Yes, the parts about coreboot really changed. I guess it wasn't easy to write about coreboot without words like "open" or "free" :-/ What irritated me the most yesterday was the talking about freedom and chips. The Product page says "Only by selecting each and every chip in our Librem laptops can we guarantee your privacy, security and freedom are protected." Given the choice of SoC Purism made, I think it should read more like By selecting an Intel SoC we trade your privacy, security and freedom for overall performance. I know there are worth chips but the Intel SoCs are not even a com- promise between privacy/security/freedom and performance they are just the opposite of what the page promises. So why talk about chip selection at all if you have to fool people about it? Nico

1 0

Re: [coreboot] Anyone got an opinion, technical or otherwise, on this?
by Nico Huber 03 May '17

03 May '17

On 03.05.2017 16:31, Matt DeVillier wrote: > On Wed, May 3, 2017 at 4:17 AM, John Lewis <jlewis(a)johnlewis.ie> wrote: > >> I think I've answered my own questions by checking out the menuconfig >> options, it looks to me as though up to and including Skylake is possible, >> and flashing internally *should* be okay? >> > Since writing to the ME region is protected by the IFD configuration, the > possibility of internal flashing would be dependent on the current > configuration of the board's IFD. I suspect most non-ChromeOS hardware will > have it unlocked (default config) as their initial flash was likely with an > external programmer. ChromeOS hardware will have a locked IFD and require > external flashing to clean the ME (unless previously externally flashed > with a ROM w/unlocked IFD). > Actually internal flashing is always possible as long as you control the firmware. The ME's flash region should be locked (Intel doesn't support anything else) but there is ofc an update path for the ME firmware. Some BIOSes have an option for this that temporarily disables the ME on the next boot to give the host firmware (BIOS, coreboot) full access and make ME firmware updates reliable (what could possibly go wrong if you flash it while the ME is fully running). AFAICT, coreboot hasn't such an option implemented (yet). But as long as you control the machine, you can implement it, update coreboot, then up- date the ME firmware. Nico

1 0

Re: [coreboot] BIOSBits ...
by Nico Huber 03 May '17

03 May '17

Hi Kashif, On 02.05.2017 23:04, Kashif Ali wrote: > Hi all, > > We modified coreboot for the OpenCellular project and looking to have test > suite for BIOS, specially during manufacturing. The OpenCellular is based > on Intel Atom E3845, similar to minnowboard. I came across biosbits.org, > have anyone tried this?. Is this the right approach or there is better > approach to this?. I've used BIOS bits years ago. Though stopped using it at some point in time, maybe because it needs a BIOS? There is also the firwmare test- suite [1] that I used a lot. IIRC, it's available as a package in Ubuntu (fwts). As you are working with an Intel SoC, you might also want to run CHIPSEC [2]. Hope that helps, Nico [1] https://wiki.ubuntu.com/FirmwareTestSuite/ [2] https://github.com/chipsec/chipsec

1 0

Re: [coreboot] Anyone got an opinion, technical or otherwise, on this?
by John Lewis 03 May '17

03 May '17

Thanks everyone for the responses. The thing that bothers me, is if you take a possibly extreme interpretation of "There is also a chance of attacks performed on Intel systems without Intel AMT support." from the people who reported the vuln @ https://www.embedi.com/news/mythbusters-cve-2017-5689 it sounds like it could be every board since 2010. I understand that Intel have a vested interest in this being (or at least appearing to be) as small as possible, whereas the reporter's interest is for it to be as big as possible. I suspect the truth might end up to be somewhere in between, e.g. that there is technically something which may apply to all boards under certain circumstances, but may not be considered realistically practicable on a large/significant scale. Still, I think this does make a case for using ME cleaning of some description, regardless of where this ends up, but presumably that might not be entirely successful unless flashing externally? Is there some form of ME cleaning available for all the chipsets up to Kabylake? John. On 03/05/17 05:37, Zoran Stojsavljevic wrote: > I also read in details some of the emails from the previous threads. I > downloaded SCSDiscovery tool: > https://downloadcenter.intel.com/download/26691/Intel-SCS-System-Discovery-… > and ran it on my notebook. > > I got as response a bunch of nonsense info (basically, it failed > everywhere) : > > C:\Program Files\Intel_SCS_Discovery_11.1.0.75>type > SCSDiscoverylog_DESKTOP-@@@@@@@_2017-05-03-06-15-18.Log > 2017-05-03 06:15:19:(INFO) : ACU Configurator , Category: > HandleOutPut: Starting log 2017-05-03 06:15:19 > 2017-05-03 06:15:19:(INFO) : SCSDiscovery, Category: > -SystemDiscovery-: DESKTOP-@@@@@@@: Discovering the System information... > 2017-05-03 06:15:33:(WARN) : SCSDiscovery.exe, Category: System > Discovery: System Discovery finished with warnings: System Discovery > failed to get data from some of the interfaces on this system. > (0xc00027ff). Failed to get data from the OS Registry interface. > (0xc0002840). Failed to read the registry value (Primary DNS suffix). > (0xc0001f52). Failed to open the registry Key > (SYSTEM\CurrentControlSet\Services\LMS). The system cannot find the > file specified. (0xc0001f50). The registry key not > found.(SYSTEM\CurrentControlSet\Services\LMS) (0xc0001f58). Failed to > get data from the GetDNSLookupName interface. (0xc0002842). Failed > to retrieve the host onboard IPv4 IP (please check the LAN settings). > (0xc0002836). > 2017-05-03 06:15:33:(INFO) : SCSDiscovery, Category: Exit: > ***********Exit with code 32 - Intel(R) AMT operation completed with > warnings: Details: Success. System Discovery finished with warnings: > System Discovery failed to get data from some of the interfaces on > this system. (0xc00027ff). Failed to get data from the OS Registry > interface. (0xc0002840). Failed to read the registry value (Primary > DNS suffix). (0xc0001f52). Failed to open the registry Key > (SYSTEM\CurrentControlSet\Services\LMS). The system cannot find the > file specified. (0xc0001f50). The registry key not > found.(SYSTEM\CurrentControlSet\Services\LMS) (0xc0001f58). Failed to > get data from the GetDNSLookupName interface. (0xc0002842). Failed > to retrieve the host onboard IPv4 IP (please check the LAN settings). > (0xc0002836). > > C:\Program Files\Intel_SCS_Discovery_11.1.0.75> > > Not surprised, since I do NOT have AMT capabilities (I have 1.5MB ME > series 9). > > Zoran > > On Tue, May 2, 2017 at 11:56 PM, Vadim Bendebury <vbendeb(a)chromium.org > <mailto:vbendeb@chromium.org>> wrote: > > I wonder if anyone ever completely trusted AMT - maybe some naive > excessive cool-aid drinkers :) > > -vb > > On Tue, May 2, 2017 at 11:27 AM, ron minnich <rminnich(a)gmail.com > <mailto:rminnich@gmail.com>> wrote: > > I wonder if anyone is going to completely trust AMT after this > problem. It goes back almost 10 years. So for all those users > who had it on for almost 10 years, the question becomes, how > much did we lose and when did we lose it? The answer? We'll > never know. Are we still owned? We don't know. Can we actually > trust any reflash procedure, if the ME is owned while we try > to reflash? Well, I hope so, but how can we know? > > It's a worrisome situation. > > ron > > On Tue, May 2, 2017 at 11:01 AM Patrick Georgi via coreboot > <coreboot(a)coreboot.org <mailto:coreboot@coreboot.org>> wrote: > > Semi-Accurate only claims accuracy according to what's on > the box. The > official documentation of the issue can be found at > https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00075 > <https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00075> > > It looks like a software bug in the AMT firmware. Therefore: > - No AMT (eg on non-business consumer devices) -> no (bug > | exploit). > - Present but disabled AMT (eg. on business devices > without AMT > enrollment) -> no (bug | exploit). (although there's > apparently a way > to enable AMT unsupervised under some circumstances with > some level of > local access. or something.) > > > Patrick > > 2017-05-02 19:31 GMT+02:00 John Lewis <jlewis(a)johnlewis.ie > <mailto:jlewis@johnlewis.ie>>: > > > https://semiaccurate.com/2017/05/01/remote-security-exploit-2008-intel-plat… > <https://semiaccurate.com/2017/05/01/remote-security-exploit-2008-intel-plat…> > > > > The article says "all" Intel boards since 2008 are > locally vulnerable > > (ME exploit), but the Intel advisory (linked within) > says consumer > > devices are okay. > > > > What the article says about even low end devices still > having the > > features albeit turned "off" rings true to me, based on > stuff I've read > > here and elsewhere. What's your take (bearing in mind > the technical > > details aren't available, yet)? > > > > > > -- > > coreboot mailing list: coreboot(a)coreboot.org > <mailto:coreboot@coreboot.org> > > https://mail.coreboot.org/mailman/listinfo/coreboot > <https://mail.coreboot.org/mailman/listinfo/coreboot> > > > > -- > Google Germany GmbH, ABC-Str. 19, 20354 Hamburg > Registergericht und -nummer: Hamburg, HRB 86891, Sitz der > Gesellschaft: Hamburg > Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle > > -- > coreboot mailing list: coreboot(a)coreboot.org > <mailto:coreboot@coreboot.org> > https://mail.coreboot.org/mailman/listinfo/coreboot > <https://mail.coreboot.org/mailman/listinfo/coreboot> > > > -- > coreboot mailing list: coreboot(a)coreboot.org > <mailto:coreboot@coreboot.org> > https://mail.coreboot.org/mailman/listinfo/coreboot > <https://mail.coreboot.org/mailman/listinfo/coreboot> > > > > -- > coreboot mailing list: coreboot(a)coreboot.org > <mailto:coreboot@coreboot.org> > https://mail.coreboot.org/mailman/listinfo/coreboot > <https://mail.coreboot.org/mailman/listinfo/coreboot> > > > >

2 2

Re: [coreboot] Remote security exploit in all 2008+ Intel platforms
by Zoran Stojsavljevic 03 May '17

03 May '17

> The reason we want to prioritize the ME vs. the FSP, is because a lot more people were interested in getting rid of the ME, > so it is a higher priority, *but the FSP is also going to be reversed eventually and coreboot deblobbed entirely*. This is very serious claim, Youness. In FSP you do have much more than ONLY MRC (actually, several MRC algorithms, a bunch tied/bundled together, depending upon what the initial DRAM SPD discovery mechanism is, my best guess). You do have BSP CPU init, then APP CPU(s) init(s), and then PCH init as well, on the system registry level. There is also platform init phase in there, the very minimal one. Also I throw-in PCIe discovery algorithm. Serious stuff. If you ask me, I would keep up with disabling ME on application level (since ME FW booting is A MUST, as my best understanding of ME FW stands for now). In other words, if I guessed correctly, to make newest ME 11.x engine, based on x86 HW (quark most likely), to run idler process all the time, if Dmitry is correct, and we have MINIX3 micro-kernel running on the top of quark there. Divide and Conquer, the evergreen idiom: first to take ME, FSP should come after (they can be well divided)... ;-) My two cent thoughts, Zoran On Wed, May 3, 2017 at 1:39 AM, Youness Alaoui < kakaroto(a)kakaroto.homelinux.net> wrote: > Looks like I failed at answering Taiidan without generating a flame war. > Sorry if anyone got offended, that wasn't my aim. > To answer the various questions that were thrown, here's what I think : > > Taiidan, you ask why Purism doesn't just create laptops using FX2 or ARM > or whatever... Well, because that's not what most people want, out there. > If you want a RYF laptop using old or underpowered hardware or non-x86 > architectures, that's a problem that has already been solved, there are > various resellers of such devices. The idea here is not to "Use what we can > find to make RYF" but rather "Bring RYF to the hardware that people want". > What I believe Purism is trying to do is to create a modern laptop for > *everyone* with the extra value of security and privacy, and in the process > make FLOSS appealing to mainstream instead of letting it be confined in a > niche. I think everyone will be better off with tools to protect their > privacy/security without asking them to throw the baby with the bathwater > by requiring them to use hardware that does not interest them (otherwise, > if old or non-x86 architectures were so appealing, you would have seen that > become the norm rather than the exception). > > As for the ME and DMCA, I believe this exempts us from it : > https://www.ftc.gov/news-events/blogs/techftc/2016/10/dmca > -security-research-exemption-consumer-devices > ...Considering that the research is done in order to protect users. Also, > an exploit to run a custom firmware on the ME isn't something that gives > access to copyrighted material, so I'm not sure why the DMCA would even > apply here. > As for your argument of an arms race and Intel "fixing" the weaknesses > allowing us to neutralize the ME, I don't see how that would matter either, > because you will be able to control the image on your own machine > *today*... if you neutralize it today, even if Intel wanted to take over > the ME in your system to patch it, well... they can't get in, because you > already neutralized it. And if they want to change it for future models, > they will have to change it in the silicon of future models, which is way > out in the future. > > To answer Sam: > Thanks for the kudos! The reason C is used is because I didn't think to > use anything else. I love C and that's what I like to use. But beyond that > answer, there are many reasons for using C. It's because this is an > assembly to C translation, if the code is 'prone to errors' it's only > because the original ME binary instructions had those errors in it, which > is good for us, since we're looking for exploits. Also, the long term goal > is to be able to generate binary-compatible images (imagine, you compile > the ME source and get a binary with the same hash as the one intel is > providing, so you can be 100% sure that it's the same code that you're > auditing as the one that is running). If we were to use any high level > language, we would never have enough fine control over the resulting binary > to be able to get binary compatibility. > > Zoran: Thanks for your comments and encouragement! :) the talks with Intel > as far as I know are not for open-sourcing the ME (which is a much harder > thing to ask for), but rather for a ME-less design. Basically, for Intel to > release a chip with the ME core simply disabled and with no firmware > running on it. That's a much easier goal to attain, but then again, we're > talking about Intel, so it's still a difficult goal to attain, but Todd has > been bugging them for a while and is constantly in talks with Intel to try > and achieve that. > > > to answer Nico's other post: > I'm quite surprised and disappointed by your answer. You have every right > to say that you are disappointed or distrusting Purism due to past actions, > but I find it harsh for you to be repeatedly saying "fraud" and "scammed" > when that is not the case at all. I think Ron has responded quite well to > that and said exactly what I wanted to say, there is a difference between > being naive and underestimating the task, vs actively "trying to scam > people". If they were scamming people, they wouldn't have shipped any > product and they wouldn't have reimbursed those who changed their mind or > were unsatisfied with what they got, and actually, I wouldn't even have > been contracted in the first place. > > Attributing to malice what was the result of honest mistakes, while you > know how complex this is both on the software and hardware side, is why > your tone was disappointing. Careless name-calling leads to people getting > hurt and flame wars and all that. > > I would just like to answer you with a few more items that I believe are > true (I may be mistaken myself as I'm still quite new to Purism): > > - Everything that was promised is still on the roadmap and a > work-in-progress (as far as I know), so it's more of an issue of missing > the deadlines/estimates rather than not wanting to deliver anything that > was promised. The "Vision" of the company in an initial crowdfunding > campaign does not mean "this is an immediately attainable milestone". > - The priority was to actually have a working product before working > on its coreboot port (wouldn't you agree that makes more sense?) There were > a ton of issues to solve with production/delivery to begin with, and Purism > is understaffed (most are volunteers as far as I know, and people with the > skills to do a coreboot port are quite rare, as you know... and some that > Purism hired before went dark). It would have been useless to focus all > efforts on coreboot for a hardware product in the making. Purism brought me > on and I had no knowledge of coreboot... let that sink in for a minute: > people able and willing to do that work are so rare that they had to train > one from scratch! > - The reason there is no coreboot port for the original > Broadwell-based Librem 15 yet is because the most logical approach was to > finalize the initial work that had been done on the Librem 13 as per Ron's > suggestion (making the learning curve a bit less steep by not having to > start from scratch), and then to prioritize work towards the upcoming > hardware so Purism can attempt to have it ready in time for it to be > factory-preloaded instead of causing additional trouble for future users. > The original Librem 15 is still going to be ported, but I can't do > everything at the same time, so things have to be prioritized. After the > initial learning curve, I am now jumping into the deep end of the coreboot > pool by porting a new board from scratch, so that's definitely an > interesting challenge. > - The reason we want to prioritize the ME vs. the FSP, is because a > lot more people were interested in getting rid of the ME, so it is a higher > priority, but the FSP is also going to be reversed eventually and coreboot > deblobbed entirely. > - Purism is trying to do the right thing and trying to defend privacy > and security the best way it can (it even became a Social Purpose > Corporation to protect that goal)... but instead of saying "You are > mistaken on this and that, let me enlighten you and help you", you are > instead bashing and trying to drive it into the ground because, for some > reason unknown to me, you feel personally slighted by Purism's legitimate > mistakes? How is that going to help protect people as a whole? It takes > time to do things right, and being stuck in the past does not help things > move forward. Give it a chance! > - What did you see on the website making wrong claims? Let me know and > I will pass on the message to get it fixed. The info on it is a *lot* more > accurate than it was a few months ago, and pretty much any coreboot/ME > claim has clear "work-in-progress" disclaimers along with it (without > writing a huge wall of text on every page). Give me specifics and I'll > forward the information to be corrected. I know there is a best effort to > rectify mistakes and make things clear and unambiguous, if something > remains unclear it's certainly just an oversight, not malice. > > > Thanks for reading, > Youness. > > >

1 0

Re: [coreboot] Anyone got an opinion, technical or otherwise, on this?
by Zoran Stojsavljevic 02 May '17

02 May '17

I also read in details some of the emails from the previous threads. I downloaded SCSDiscovery tool: https://downloadcenter.intel.com/download/26691/Intel-SCS-System-Discovery-… and ran it on my notebook. I got as response a bunch of nonsense info (basically, it failed everywhere) : C:\Program Files\Intel_SCS_Discovery_11.1.0.75>type SCSDiscoverylog_DESKTOP-@@@@@@@_2017-05-03-06-15-18.Log 2017-05-03 06:15:19:(INFO) : ACU Configurator , Category: HandleOutPut: Starting log 2017-05-03 06:15:19 2017-05-03 06:15:19:(INFO) : SCSDiscovery, Category: -SystemDiscovery-: DESKTOP-@@@@@@@: Discovering the System information... 2017-05-03 06:15:33:(WARN) : SCSDiscovery.exe, Category: System Discovery: System Discovery finished with warnings: System Discovery failed to get data from some of the interfaces on this system. (0xc00027ff). Failed to get data from the OS Registry interface. (0xc0002840). Failed to read the registry value (Primary DNS suffix). (0xc0001f52). Failed to open the registry Key (SYSTEM\CurrentControlSet\Services\LMS). The system cannot find the file specified. (0xc0001f50). The registry key not found.(SYSTEM\CurrentControlSet\Services\LMS) (0xc0001f58). Failed to get data from the GetDNSLookupName interface. (0xc0002842). Failed to retrieve the host onboard IPv4 IP (please check the LAN settings). (0xc0002836). 2017-05-03 06:15:33:(INFO) : SCSDiscovery, Category: Exit: ***********Exit with code 32 - Intel(R) AMT operation completed with warnings: Details: Success. System Discovery finished with warnings: System Discovery failed to get data from some of the interfaces on this system. (0xc00027ff). Failed to get data from the OS Registry interface. (0xc0002840). Failed to read the registry value (Primary DNS suffix). (0xc0001f52). Failed to open the registry Key (SYSTEM\CurrentControlSet\Services\LMS). The system cannot find the file specified. (0xc0001f50). The registry key not found.(SYSTEM\CurrentControlSet\Services\LMS) (0xc0001f58). Failed to get data from the GetDNSLookupName interface. (0xc0002842). Failed to retrieve the host onboard IPv4 IP (please check the LAN settings). (0xc0002836). C:\Program Files\Intel_SCS_Discovery_11.1.0.75> Not surprised, since I do NOT have AMT capabilities (I have 1.5MB ME series 9). Zoran On Tue, May 2, 2017 at 11:56 PM, Vadim Bendebury <vbendeb(a)chromium.org> wrote: > I wonder if anyone ever completely trusted AMT - maybe some naive > excessive cool-aid drinkers :) > > -vb > > On Tue, May 2, 2017 at 11:27 AM, ron minnich <rminnich(a)gmail.com> wrote: > >> I wonder if anyone is going to completely trust AMT after this problem. >> It goes back almost 10 years. So for all those users who had it on for >> almost 10 years, the question becomes, how much did we lose and when did we >> lose it? The answer? We'll never know. Are we still owned? We don't know. >> Can we actually trust any reflash procedure, if the ME is owned while we >> try to reflash? Well, I hope so, but how can we know? >> >> It's a worrisome situation. >> >> ron >> >> On Tue, May 2, 2017 at 11:01 AM Patrick Georgi via coreboot < >> coreboot(a)coreboot.org> wrote: >> >>> Semi-Accurate only claims accuracy according to what's on the box. The >>> official documentation of the issue can be found at >>> https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00075 >>> >>> It looks like a software bug in the AMT firmware. Therefore: >>> - No AMT (eg on non-business consumer devices) -> no (bug | exploit). >>> - Present but disabled AMT (eg. on business devices without AMT >>> enrollment) -> no (bug | exploit). (although there's apparently a way >>> to enable AMT unsupervised under some circumstances with some level of >>> local access. or something.) >>> >>> >>> Patrick >>> >>> 2017-05-02 19:31 GMT+02:00 John Lewis <jlewis(a)johnlewis.ie>: >>> > https://semiaccurate.com/2017/05/01/remote-security-exploit- >>> 2008-intel-platforms/ >>> > >>> > The article says "all" Intel boards since 2008 are locally vulnerable >>> > (ME exploit), but the Intel advisory (linked within) says consumer >>> > devices are okay. >>> > >>> > What the article says about even low end devices still having the >>> > features albeit turned "off" rings true to me, based on stuff I've read >>> > here and elsewhere. What's your take (bearing in mind the technical >>> > details aren't available, yet)? >>> > >>> > >>> > -- >>> > coreboot mailing list: coreboot(a)coreboot.org >>> > https://mail.coreboot.org/mailman/listinfo/coreboot >>> >>> >>> >>> -- >>> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg >>> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: >>> Hamburg >>> Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle >>> >>> -- >>> coreboot mailing list: coreboot(a)coreboot.org >>> https://mail.coreboot.org/mailman/listinfo/coreboot >> >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot >> > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] Remote security exploit in all 2008+ Intel platforms
by Youness Alaoui 02 May '17

02 May '17

Looks like I failed at answering Taiidan without generating a flame war. Sorry if anyone got offended, that wasn't my aim. To answer the various questions that were thrown, here's what I think : Taiidan, you ask why Purism doesn't just create laptops using FX2 or ARM or whatever... Well, because that's not what most people want, out there. If you want a RYF laptop using old or underpowered hardware or non-x86 architectures, that's a problem that has already been solved, there are various resellers of such devices. The idea here is not to "Use what we can find to make RYF" but rather "Bring RYF to the hardware that people want". What I believe Purism is trying to do is to create a modern laptop for *everyone* with the extra value of security and privacy, and in the process make FLOSS appealing to mainstream instead of letting it be confined in a niche. I think everyone will be better off with tools to protect their privacy/security without asking them to throw the baby with the bathwater by requiring them to use hardware that does not interest them (otherwise, if old or non-x86 architectures were so appealing, you would have seen that become the norm rather than the exception). As for the ME and DMCA, I believe this exempts us from it : https://www.ftc.gov/news-events/blogs/techftc/2016/10/ dmca-security-research-exemption-consumer-devices ...Considering that the research is done in order to protect users. Also, an exploit to run a custom firmware on the ME isn't something that gives access to copyrighted material, so I'm not sure why the DMCA would even apply here. As for your argument of an arms race and Intel "fixing" the weaknesses allowing us to neutralize the ME, I don't see how that would matter either, because you will be able to control the image on your own machine *today*... if you neutralize it today, even if Intel wanted to take over the ME in your system to patch it, well... they can't get in, because you already neutralized it. And if they want to change it for future models, they will have to change it in the silicon of future models, which is way out in the future. To answer Sam: Thanks for the kudos! The reason C is used is because I didn't think to use anything else. I love C and that's what I like to use. But beyond that answer, there are many reasons for using C. It's because this is an assembly to C translation, if the code is 'prone to errors' it's only because the original ME binary instructions had those errors in it, which is good for us, since we're looking for exploits. Also, the long term goal is to be able to generate binary-compatible images (imagine, you compile the ME source and get a binary with the same hash as the one intel is providing, so you can be 100% sure that it's the same code that you're auditing as the one that is running). If we were to use any high level language, we would never have enough fine control over the resulting binary to be able to get binary compatibility. Zoran: Thanks for your comments and encouragement! :) the talks with Intel as far as I know are not for open-sourcing the ME (which is a much harder thing to ask for), but rather for a ME-less design. Basically, for Intel to release a chip with the ME core simply disabled and with no firmware running on it. That's a much easier goal to attain, but then again, we're talking about Intel, so it's still a difficult goal to attain, but Todd has been bugging them for a while and is constantly in talks with Intel to try and achieve that. to answer Nico's other post: I'm quite surprised and disappointed by your answer. You have every right to say that you are disappointed or distrusting Purism due to past actions, but I find it harsh for you to be repeatedly saying "fraud" and "scammed" when that is not the case at all. I think Ron has responded quite well to that and said exactly what I wanted to say, there is a difference between being naive and underestimating the task, vs actively "trying to scam people". If they were scamming people, they wouldn't have shipped any product and they wouldn't have reimbursed those who changed their mind or were unsatisfied with what they got, and actually, I wouldn't even have been contracted in the first place. Attributing to malice what was the result of honest mistakes, while you know how complex this is both on the software and hardware side, is why your tone was disappointing. Careless name-calling leads to people getting hurt and flame wars and all that. I would just like to answer you with a few more items that I believe are true (I may be mistaken myself as I'm still quite new to Purism): - Everything that was promised is still on the roadmap and a work-in-progress (as far as I know), so it's more of an issue of missing the deadlines/estimates rather than not wanting to deliver anything that was promised. The "Vision" of the company in an initial crowdfunding campaign does not mean "this is an immediately attainable milestone". - The priority was to actually have a working product before working on its coreboot port (wouldn't you agree that makes more sense?) There were a ton of issues to solve with production/delivery to begin with, and Purism is understaffed (most are volunteers as far as I know, and people with the skills to do a coreboot port are quite rare, as you know... and some that Purism hired before went dark). It would have been useless to focus all efforts on coreboot for a hardware product in the making. Purism brought me on and I had no knowledge of coreboot... let that sink in for a minute: people able and willing to do that work are so rare that they had to train one from scratch! - The reason there is no coreboot port for the original Broadwell-based Librem 15 yet is because the most logical approach was to finalize the initial work that had been done on the Librem 13 as per Ron's suggestion (making the learning curve a bit less steep by not having to start from scratch), and then to prioritize work towards the upcoming hardware so Purism can attempt to have it ready in time for it to be factory-preloaded instead of causing additional trouble for future users. The original Librem 15 is still going to be ported, but I can't do everything at the same time, so things have to be prioritized. After the initial learning curve, I am now jumping into the deep end of the coreboot pool by porting a new board from scratch, so that's definitely an interesting challenge. - The reason we want to prioritize the ME vs. the FSP, is because a lot more people were interested in getting rid of the ME, so it is a higher priority, but the FSP is also going to be reversed eventually and coreboot deblobbed entirely. - Purism is trying to do the right thing and trying to defend privacy and security the best way it can (it even became a Social Purpose Corporation to protect that goal)... but instead of saying "You are mistaken on this and that, let me enlighten you and help you", you are instead bashing and trying to drive it into the ground because, for some reason unknown to me, you feel personally slighted by Purism's legitimate mistakes? How is that going to help protect people as a whole? It takes time to do things right, and being stuck in the past does not help things move forward. Give it a chance! - What did you see on the website making wrong claims? Let me know and I will pass on the message to get it fixed. The info on it is a *lot* more accurate than it was a few months ago, and pretty much any coreboot/ME claim has clear "work-in-progress" disclaimers along with it (without writing a huge wall of text on every page). Give me specifics and I'll forward the information to be corrected. I know there is a best effort to rectify mistakes and make things clear and unambiguous, if something remains unclear it's certainly just an oversight, not malice. Thanks for reading, Youness.

1 0

← Newer
1
...
13
14
15
16
17
18
19
20
21
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot May 2017