coreboot May 2017

coreboot@coreboot.org

70 participants
202 discussions

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

11 May '17

> The text on those pages does say that the BIOS is "not yet freed" and that it depends on the FSP, and the comparison tables > do specifically say that the BIOS is not yet free (it says "almost" because Todd thought it was almost done, but due to the > issues with coreboot contributors I mentioned above, it didn't happen, and that's an unforeseen hurdle, since there apparently > was good progress on the port by that time). OK, Youness, let me put things in perspective. Regarding your statement above: All BIOSes released at least from last 5 years ago till now are UEFI compliant. With CSM (Compatibility Support Mode) ON, if anyone does NOT understand UEFI, (s)he can accomplish legacy. Todd is NOT a technical person, it is very obvious. He does not understand what all of these statements mean. FSP is essential part of BIOS, which covers SEC and most of PEI phases. Everything else is released as Tiano Core, Open Source project. The MOST important part of BIOS (no matter if the BIOS is UEFI compliant or not), is actually FSP part, which INTEL will NEVER release as Open Source. Unless some higher marketing/sales forces will push INTEL to start failing in profits... And I expect this to happen. Then you can expect unexpected! ;-) Zoran Stojsavljevic _______ On Thu, May 11, 2017 at 3:56 AM, Youness Alaoui < kakaroto(a)kakaroto.homelinux.net> wrote: > Thanks Peter, well said! I enjoyed that little graphic too :) > @Taiidan, I hadn't thought of PAVP, but the idea is to remove/neutralize > the ME entirely, not to intercept its messages. If we take control of the > ME, we'll probably just call 'halt' to make sure that core is disabled. I > don't see how that affects the DMCA. > Either way, the DMCA exception is still there for our purposes, even if > that wasn't what we were doing. > As for your FX-2 idea, I already explained my thoughts on that. > > @Nico, Thanks for a civil and interesting response, I'll reply inline to > your comments below, but a disclaimer, the things I'm saying below are my > own opinions and interpretations on things, and a lot of it is based on > things I've heard. The accuracy of what I heard, which is often a second > hand account of events, may not be 100%, so keep that in mind. > > On Wed, May 3, 2017 at 3:45 PM, Nico Huber <nico.h(a)gmx.de> wrote: > >> 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? >> > > Yes, there were reimbursements. How the reimbursements have taken place, I > don't know, but I know that some got refunds, some got upgrades, > downgrades, sidegrades, etc.. depending on what the customer wanted. I know > that Purism has been struggling for a bit (one of the reasons most of the > employees are volunteers) as it was lacking funds (hence the recent > kickfurther for the v2 stock). Customers who had the highest requirements > and expectations for the touchpad requested reimbursements and got them. > The original campaign promised a great touchpad experience, unfortunately > the touchpads of the first batches of laptops (before the one currently > being made) did have limitations. While those touchpads do work, they're > not the ultimate user experience, and Purism hasn't had the time and > resources to work on fixing that driver (I was originally going to > reverse engineer the BYD driver, but instead I was thrown into working on > coreboot). > I don't have any other details on how it happened, it it was an explicit > offer, if there are conditions, etc.. If you're curious, you can drop in > #purism and ask your questions, I'm sure there are people more > knowledgeable than me that can answer you. > > >> > 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 never said you started anything, and yes, using some FOSS project's > reputation to boost your own by association when there really wasn't any > contribution is cause for anger and disappointment, I never said otherwise > either. The only thing that I said is that there's a difference between > being naive and making unintentional mistakes versus being a scammer and > intentionally misleading people. Eventually people have to forgive past > mistakes, especially if they were unintentional and efforts are made to > move things in the right direction (which it is now afaik). I agree with > you though that past mistakes have to be owned up by those who made them, > and apologies should be made. You (and everyone else) doesn't owe Purism > anything, so you don't have to accept their excuses either, but it's just > better when everyone is on good terms I think. > Like I told you in my first email, you have every right to be disappointed > and mistrusting of Purism due to their past mistakes, that is not up for > debate. > > >> > 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? >> > > I don't know anything about that to be honest. If you're referring to the > royalty fee for AMI BIOS, then yeah, I'm pretty sure they did get their > royalty paid since it came preloaded with it (it's probably just cents > anyways), but if it was instead in reference to paying for a windows > license that you don't need, then I'm pretty sure that nobody paid for > that. Was it an explicit promise or an implied promise ? And was that > promise maybe misunderstood (a promise meant to the general population who > thinks about windows licenses, but you misinterpreted it as bios royalty, > since that's what you are more interested in) ? Sometimes it's easy to have > expectations tailored to your own thoughts/needs and end up disappointed > because the person on the other end didn't have the same expectations as > you. > I've been looking everywhere and I can't find a single reference to > anything like that, whether expressed or implied about any kind of money > flow. > https://www.crowdsupply.com/purism/librem-13 > https://www.crowdsupply.com/purism/librem-15 > > >> >> > - 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. >> > > Well, it's not just a linux machine, it's a linux machine that is focused > on security on privacy. I'll come to that later below, but to answer just > that, I think that the error here is that Todd was overoptimistic, > overenthusiastic, and he missed his deadlines. Again, it's a matter of > malice vs mistake. It wasn't advertised as a linux machine because it was > never meant to be just that. There was a lot of attempt at getting it > ported to coreboot from the start but things didn't go as well as > anticipated, so he had to either compromise, or go bankrupt and truly > scam/break his promise by not shipping anything to anyone. I'm sure it > would have been advertised differently if he could have anticipated how > things were going to happen. > > > >> > 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? >> > > I'll disagree with this one here. Todd actually asked for the coreboot > community for help in August 2014, before the crowdfunding campaign. Here's > the archive thread: https://mail.coreboot.org/pipermail/coreboot/2014-Au > gust/078511.html > The link to that was in the timeline page I linked before which explains a > lot of it : https://puri.sm/coreboot/timeline/ > You can read through it if you want, but a quick read through tells me > that Todd sought help, was then told that reverse engineering is possible > to get it blob free, and that it would just take time, and that both intel > and AMD were going to have the same kind of binary issues. Someone > suggested ARM but Todd said that it was too late to change the > architecture. I think that a lot of the statements he originally made were > also due to discussions with Intel which looked promising and he thought > that having an ME-less design was on the board. > > What happened after that is that he had hired a coreboot developer who > then went dark (stopped answering all emails, phone calls, disappeared off > the face of the earth, etc.. ), then (from what I heard, second-hand > account again) he hired one or two other coreboot contributors to do the > port, who ended up dropping the project and got hired by [some big > corportation]. Then Todd sat down with some other coreboot developers who > said they couldn't be contracted to work on this because of their > non-compete agreement with Google (or exclusivity clause or something), so > Todd donated a bunch of laptops to them to at least help kickstart things. > Duncan Laurie's initial Librem 13 port came out from that. At that point, > Todd had a lot of other issues to handle (production issues, had to change > factories, suppliers, original motherboard design was not shared by the > previous MB supplier, so he had to work on a new hardware, and negotiate > for a new MB to be designed), all while he had no stock, so no sales, no > income, and it takes a lot of money to pay for the MB design, for > prototypes, and to be back on track again, so the entire coreboot side of > things had to be put on ice for the time being. > > When I was asked to work on coreboot, I was told that I was the perfect > person for the job (even though I had no prior experience in this) because > I was independent from the coreboot community, I'm a contractor with no > one-contract exclusivity plans and no plans of getting a job anywhere, and > because there was this odd phenomenon where Google was hiring anyone that > Todd has his sights on (the community is rather small after all). I think > that was also one of the reasons why I believe he had stopped reaching out > to the coreboot community for help. > > > > >> >> > - 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. >> > > Yes, I know! :) > You seem to have extreme disappointment or distrust in Purism, but you've > been nothing but helpful since the start, and I appreciate it. Thanks :) > > >> >> > - 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. >> > > Honestly, I don't know, but that was the impression I got. Purism had done > a petition for an ME-less design (https://puri.sm/posts/intel-m > e-less-petition-goal-met-early/) and it was apparently quite successful, > so there is definitely interest in getting rid of the ME. > > I think though that this issue of "ME or FSP first" is completely > pointless because that's not an issue of empty promises or dishonesty, it > is an issue of diverging opinion. While you believe that getting rid of the > FSP is more important, I think that Todd believes the ME is the most > dangerous item to get rid of first, maybe you can have a chat about this > subject (we'll both be at the coreboot conference, so we might meet you > there if you are attending), and maybe one of you will convince the other > (or not, and that's ok too). > The way I see it though is that the ME is more dangerous because it runs > in parallel to you, it's constantly running, even when the PC is powered > off and it seems to exist mainly for allowing remote attackers (Intel) to > control the machine, but we really have no idea at all what it does. The > FSP (from what I understand of it) however, only runs once, it is not > persistent and we know what it does (initialize specific hardware > components). Even if the FSP puts some hidden hooks that keep it > persistent, it would only put it on the same threat level as the ME, not > above. Even the coreboot wiki puts the ME at a higher panic level than the > MRC (which I assume the FSP is equivalent to, but I guess it does a bit > more than the MRC): https://www.coreboot.org/Binary_situation > > > >> > - 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.) >> >> > I think they admit the past mistakes, I don't think that's an issue, you > just don't see articles written about that. As for how long it took to > change the website, I would attribute it to "trying to put down the flames > in the kitchen is more important than answering the phone right now". There > might also have been some remaining hope maybe that it could still be done. > Also, I don't think anyone was in charge of that until Jeff Fortin was > hired to take care of the website, and fix/update the content, etc... So I > think that it wasn't "making promises knowing they weren't true" but rather > "there is no one to take care of taking down the old promises that we > realized were overoptimistic". > > >> > - 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? >> > > I said above that I would talk 'later' about why it's not just a Linux > machine, but it's a Linux machine with security/privacy in mind, and I > think this is the perfect place to answer that. > > I think the issue here is that you come with a lot of technical background > tinting your vision, forgetting that not everybody thinks and sees things > the same way as you. What I mean by that, is that the text that you've read > was not written specifically for the "hardcore coreboot/hardware > developer", it's rather meant for the average Linux enthusiast and > journalists or users interested in security and privacy. That sentence that > irritated you so much is absolutely true when you put yourself into the > shoes of the audience it was imagined for: > >> "Only by selecting each and every chip in our Librem laptops can we >> guarantee your privacy, security and freedom are protected." > > > That sentence is true, it's not a lie: Purism *does* have control over the > choice of every chip in the laptop, it is not a simple reseller of > white-label laptops like so many others. Purism can decide exactly what > features and components to put in, like for example, a TPM (making Trammel > Hudson/Heads happy), or a different ethernet adapter (even though the SoC > comes with one already, but disabling the integrated Intel ethernet/wifi is > one of the puzzle pieces allowing to disable AMT). They also decided to use > the "ene KB3930QF-A1" as EC, which is a well documented one (is it one of > the only ECs with a full public datasheet?). The Atheros wifi module also > doesn't require a binary firmware (we are lacking the firmware to make > Bluetooth work though, which is why Bluetooth was never advertised as a > feature... there's an open position for someone to reverse/implement the BT > firmware), etc. There are probably plenty of chips and controllers that > require a blob to work with Linux, and that sentence is meant to say "We > make sure to select a good combination of chips that are well supported in > Linux and do not require a binary firmware to function". I think the > touchpad controller was a complete miss (it works for basic usecases but > it's not very well supported in Linux), but the new laptop models come with > Elantech touchpads that are very well supported in Linux and were chosen > specifically for that. > > Anyways, all that to say: the sentence holds true, you only consider it a > lie because you focus on the one chip (the CPU) where there is not that > much choice available, you see the modern Intel CPU and instantly think > "You're fooling people by telling them that there are no binary blobs in > the CPU" when the sentence only means, essentially, "we control the chips > used in the motherboard and choose the best options available". Best option > does not necessarily mean utopian option. > > Someone else might see it as "We control the motherboard and trust this > particular company, so we're confident there isn't a spy chip in the > motherboard handing control of your machine over to the nation state" > (which might be what the original intent of that sentence actually is, > especially considering there's a warrant canary in place: > https://puri.sm/warrant-canary/). > > I once saw a discussion about how the CIA was planting spy chips on > motherboards, and Snowden saying that when a laptop/smart TV/whatever is > being shipped to a "region of interest", the CIA would open the packages > and install hardware spyware on the motherboards of all the laptops/tvs in > destination to that region, and there was internal discussion in Purism on > how to prevent that, such as tamper-evident packaging, providing signed > pictures of the motherboard before shipment, stuff like that. > > I believe that's what makes Purism a "security and privacy focused" > company. No "Linux-compatible laptop" reseller goes (and can go) to such > lengths to ensure the security and privacy of their users with brand new > hardware. If the supplier of <insert random Linux laptop reseller company> > decided to add a spy chip in their motherboards, they wouldn't know and > they would have no power over it. > > Now, is the current situation perfect? Obviously not, since we still have > the FSP and ME binaries to get rid of, and who knows what else, but it a > *lot* more than anyone else is doing as far as I know. And I am talking of > course of brand new and modern/powerful computers, I am not talking about > older refurbished laptops or obscure or underpowered hardware. I think the > advantage of Purism is that it's trying hard to give users what they want > (so they don't have to compromise on the hardware) and work towards > achieving the long-term goal, rather than having to take whatever scraps > are available and compromise on everything else and then just stagnate, > cross their fingers and hope that Intel/AMD suddenly have a change of heart > and quickly release a new CPU variant without the recent restrictions > (ME/FSP/etc.) > > So yeah, basically, all I wanted to say is that, the contents that > irritated you probably only felt irritating because you interpret > differently from how it was intended to be read. And I also think that you > (and many others) unfortunately had some high expectations that were not > actually ever promised. So when those expectations were not met, you were > disappointed, but you couldn't have realized that those expectations were > yours only, and never were mentioned or promised by the original campaign. > > > > I took a while to write this response to you because I wanted to do > research on the original crowdfunding campaign (which I had never seen > until this week) and search for any of these "broken promises" that seem to > get so many people riled up. I realized that the only broken promise was > that it would ship with coreboot from day one, obviously that objective was > not met (but coreboot work was never dropped, just delayed), due to the > various reasons I explained above. Every other criticism I heard however > (that Purism promised zero binary blobs, no ME and no FSP, or a promise > that "nowhere at any point in time anybody in the supply chain would get a > cent related to proprietary software, not even American Megatrends or > Intel", etc.) was not accurate criticism, I didn't find any such promises > being made anywhere in those campaigns: > > https://www.crowdsupply.com/purism/librem-15 > https://www.crowdsupply.com/purism/librem-13 > > Personally, as I read the texts and listened to the video of those > campaigns, I heard two things that made me initially cringe: > - "meticulously designed chip by chip to work with free and open source > software" > - "no binary blob" > > But then realized the "chip by chip" thing does not apply to the CPU > because that was not the point of the Librem, it's not meant to be an ARM > laptop or an old laptop, it's meant to be a high end laptop and Intel is > the only choice for that (or was, back in 2014... not sure if it changed > since). If you search for "chip by chip" in that page though, you'll see > the explanation for that sentence from the video, and the chips that are > mentioned are: Audio, Camera, Hubs, Video, Graphics, USB, Network, > Wireless. The CPU is not shown in that graphic. The text there also > explains what it means, and it is referring to chips that send information > without your knowledge. > > As for the second sentence where criticism occurs, "no binary blob": I had > to listen to the video twice before I realized that the whole sentence is > actually "no binary blob GNU/Linux based operating system". The whole > "binary blob free" promise of the original campaign was always about the > kernel not requiring any binary blobs tainting it. Pretty much every other > recent laptop would use a tainted kernel otherwise the laptop wouldn't work > correctly, but the Librem doesn't need any binary blobs in the kernel for > it to function fully. That's what the whole "no binary blobs" deal meant, > and it goes along with the "every chip is selected to be privacy-respecting > and firmware-free". > > Of course, since I've been so caught up on coreboot and ME-reversing and > all that, the first two times I listened to the video and heard "no binary > blobs", I immediately associated it with the ME and FSP, and I missed the > rest of the sentence. I suspect this tinted interpretation occurred to most > members of the coreboot community. > > Now the question that remains is about the BIOS and coreboot. The text on > those pages does say that the BIOS is "not yet freed" and that it depends > on the FSP, and the comparison tables do specifically say that the BIOS is > not yet free (it says "almost" because Todd thought it was almost done, but > due to the issues with coreboot contributors I mentioned above, it didn't > happen, and that's an unforeseen hurdle, since there apparently was good > progress on the port by that time). > > If you read the FAQ however, it states that the librem will come with > coreboot and that's the delayed (but not broken) promise, but again it also > specifically says: > >> "While the BIOS is not yet free, the Librem 15 will be the first laptop >> ever manufactured to ship a modern Intel CPU fused to run unsigned BIOS >> code, allowing for a future where free software can replace the >> proprietary, digitally signed BIOS binaries. This marks one of the largest >> hurdles to a laptop that runs 100% free software and firmware". > > > That's all true and it does say that the advantage here is the unfused > CPU, and that the BIOS not being free yet is "one of" the largest hurdles > for 100% free software and firmware. > > It also says : > >> "In addition to enabling as above the development of free BIOS firmware, >> we are also working with Intel to allow us to scrub, release, and maintain >> the source for the FSP, but haven’t finalized that yet. We are devoted to >> freeing this binary." > > > ...which also indicates that there was work in progress to free the binary > through a deal with Intel, which didn't pan out so far, but to be fair it > was specifically saying that this was not a done deal. > > Also note that "coreboot" is actually mentioned by name only once in the > campaign and that was in the FAQ. So it's not like "it comes with coreboot" > was a big selling point or the project's name was used/abused to boost > sales or reputation. It was used legitimately because work was ongoing on > the coreboot port and that was mostly in the technical news updates. > > I even found in one of the crowdfunding updates, one of the update states > at the end: > >> "We will be intensifying our product & service development pace, and we >> are still working on everything else part of our mission (including the >> Intel ME issue, achieving FSF endorsement of our software and working >> toward FSF RYF certification of our hardware in the long term)" > > > So it does say that RYF is a long term goal towards which we're working, > not an immediate pre-shipping goal. > > As for the thing about funds not going to any proprietary software (ie > ensuring that no royalties would be paid to anything non-free anywhere in > the hardware supply chain), I couldn't find anything that even hints at it, > so I'm not sure how or why you thought that was a promise, so if you can > find something about that, let me know! > > Whew, this was a long email. I hope it helped put things in perspective, > thanks for reading. > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot >

1 0

Platform / Chip removals after upcoming releases
by Martin Roth 11 May '17

11 May '17

Along with the latest coreboot release, coreboot announced some standards for removing platforms after upcoming releases. Summary: * After the 4.7 release platforms that do not support cbmem in romstage will be removed. Please see the list of platforms to be removed if no work is done to update them at the end of this email. * After the 4.8 release, and with every release after that, platforms that have not been updated in the board-status repository within the previous year will be removed. Code removal after the 4.7 release ---------------------------------------------- One of the things that the coreboot project has struggled with is how to maintain the older platforms while still moving the rest of the platforms forward. Currently there are numerous platforms in the codebase which have not been well maintained. Starting with the 4.7 release in October, the coreboot leadership is going to set standards that platforms are expected to meet to remain in the active codebase. These will generally be announced 3 to 6 months in advance to give time to get changes in. The expectation is not necessarily even that all work to meet the goal will be completed, but it is expected that a reasonable effort has started to meet the goal at the time of the release. Regardless of the work that's been done, platforms which have not met the goal by the following release will be removed. The next expectation that will need to be met for all platforms is cbmem in romstage. This currently affects numerous platforms, including most, if not all of AMD's platforms. Work to update many of these platforms has started, but there are others that have not made any progress towards this goal. A list of the platforms that are affected by this is included at the end of this email. Please know that this is not a new idea, there is precedent for this in the coreboot project with the removal of platforms that did not support Cache-as-RAM. Two platforms were exempted from that cleanup effort, and exceptions might be made for platforms going forward. Honestly, the hope is that this will spur work to bring the older platforms up to current standards. Note that work for removed platforms CAN continue on the release branch, just not on the master branch. Additionally, if the work is done to bring the platform up to the current standards, it can definitely be brought back into the master branch. Code removal after the 4.8 release ---------------------------------------------- To further clean things up, starting with the 4.8 release, any platform that does not have a successful boot logged in the board_status repo in the previous year (that is, within the previous two releases) will be removed from the maintained coreboot codebase. Chips that do not have any associated boards will also be removed. These platforms will be announced before the release so that there is time for people to test if desired. This is not meant to be a high bar, but as a measure to clean up the codebase and eliminate boards and chips that are actually no longer being used. The cleanup will happen just after the release, so the removed platforms will still be available in the release branch if desired. If there is still interest, developers can bring back old chips and boards by porting them to the new tree (and bringing them to current standards). This gives everyone until April 2018 to get any boards that they care about tested before the first removal. Additional instructions and improvements to the board_status script are expected within the next few months to facilitate testing. 146 Platforms currently scheduled for removal after 4.7 if no work is done to update them ---------------------------------------------------------------------------------------------------------------------- AAEON_PFM_540I_REVB ABIT_BE6_II_V2_0 AMD_BETTONG AMD_DB800 AMD_DB_FT3B_LC AMD_DBM690T AMD_DINAR AMD_F2950 AMD_GARDENIA AMD_INAGUA AMD_LAMAR AMD_MAHOGANY AMD_NORWICH AMD_OLIVEHILL AMD_OLIVEHILLPLUS AMD_PARMER AMD_PERSIMMON AMD_PISTACHIO AMD_RUMBA AMD_SERENGETI_CHEETAH AMD_SOUTHSTATION AMD_THATCHER AMD_TORPEDO AMD_UNIONSTATION AOPEN_DXPLPLUSU ARTECGROUP_DBE61 ASROCK_939A785GMH ASROCK_E350M1 ASROCK_IMB_A180 ASUS_A8N_E ASUS_A8N_SLI ASUS_A8V_E_DELUXE ASUS_A8V_E_SE ASUS_DSBF ASUS_F2A85_M ASUS_F2A85_M_LE ASUS_F2A85_M_PRO ASUS_K8V_X ASUS_KFSN4_DRE_K8 ASUS_M2N_E ASUS_M2V ASUS_M2V_MX_SE ASUS_MEW_AM ASUS_MEW_VM ASUS_P2B ASUS_P2B_D ASUS_P2B_DS ASUS_P2B_F ASUS_P2B_LS ASUS_P3B_F A_TREND_ATC_6220 A_TREND_ATC_6240 AZZA_PT_6IBD BACHMANN_OT200 BCOM_WINNETP680 BIFFEROS_BIFFERBOARD BIOSTAR_AM1ML BIOSTAR_M6TBA BROADCOM_BLAST COMPAQ_DESKPRO_EN_SFF_P600 DIGITALLOGIC_MSM800SEV DMP_EX ECS_P6IWP_FE ELMEX_PCM205400 ELMEX_PCM205401 GIGABYTE_GA_2761GXDK GIGABYTE_GA_6BXC GIGABYTE_GA_6BXE GIGABYTE_M57SLI GIZMOSPHERE_GIZMO GIZMOSPHERE_GIZMO2 HP_ABM HP_DL145_G1 HP_DL145_G3 HP_E_VECTRA_P2706T HP_PAVILION_M6_1035DX IEI_PCISA_LX_800_R10 IEI_PM_LX2_800_R10 IEI_PM_LX_800_R11 INTEL_D810E2CB INTEL_EAGLEHEIGHTS INTEL_MTARVON INTEL_TRUXTON IWAVE_RAINBOW_G6 IWILL_DK8_HTX JETWAY_J7F2 JETWAY_J7F4K1G2E JETWAY_J7F4K1G5D JETWAY_NF81_T56N_LF KONTRON_KT690 LANNER_EM8510 LENOVO_G505S LINUTOP_LINUTOP1 LIPPERT_FRONTRUNNER LIPPERT_FRONTRUNNER_AF LIPPERT_HURRICANE_LX LIPPERT_LITERUNNER_LX LIPPERT_ROADRUNNER_LX LIPPERT_SPACERUNNER_LX LIPPERT_TOUCAN_AF MITAC_6513WU MSI_MS_6119 MSI_MS_6147 MSI_MS_6156 MSI_MS_6178 MSI_MS7135 MSI_MS7260 MSI_MS7721 MSI_MS9185 MSI_MS9282 NEC_POWERMATE_2000 NOKIA_IP530 NVIDIA_L1_2PVV ODE_E20XX ODE_E21XX PCENGINES_ALIX1C PCENGINES_ALIX2C PCENGINES_ALIX2D PCENGINES_ALIX6 PCENGINES_APU1 PCENGINES_APU2 RCA_RM4100 SIEMENS_SITEMP_G1P1 SOYO_SY_6BA_PLUS_III SUNW_ULTRA40 SUNW_ULTRA40M2 SUPERMICRO_H8DME SUPERMICRO_H8DMR SUPERMICRO_H8QGI SUPERMICRO_H8SCM SUPERMICRO_X7DB8 TECHNEXION_TIM5690 TECHNEXION_TIM8690 THOMSON_IP1000 TRAVERSE_GEOS TYAN_S1846 TYAN_S2912 TYAN_S8226 VIA_EPIA_CN VIA_EPIA_M700 VIA_EPIA_M850 VIA_PC2500E VIA_VT8454C WINENT_MB6047 WINENT_PL6064 WYSE_S50

1 0

Re: [coreboot] : AMT bug
by Allen Krell 11 May '17

11 May '17

On Thu, May 11, 2017 at 9:56 AM, Trammell Hudson <hudson(a)trmm.net> wrote: > On Thu, May 11, 2017 at 07:01:47AM -0500, Allen Krell wrote: > > One thing I am still confused about is the relationship between Intel > Boot > > Guard and the regions of flash. My understanding is that Boot Guard only > > applies to the legacy BIOS region of flash, not the ME/AMT region. > > It seems to be even more restricted than that -- the "hardware" part of > Bootguard only applies to the startup ACM region in the FIT table > of the BIOS region of the flash. That ACM is what is responsible for > implementing whatever policy for the rest of the flash. > > > [...] So, if that is true, then is it possible to flash the ME/AMT > > region of flash with any ME code module that has been signed with the > Intel > > signature? > > I think so, although I haven't looked at enough to determine if > the different chipsets or CPU models are signed with different keys. > > Unlike the few startup ACM images that I've looked at have the same > public key for their signature, despite being on very different > CPU models and from different IBV. > > -- > Trammell > You are confirming how I "think" it works based off various lists and documents I have found. There are multiple keys BIOS_ACM - public/private key pair - Fused in by Intel and checked by Intel silicon. May be common across all models. ME - public/private key pair - Fused in by Intel and checked by Intel silicon - Probably different across models Boot Guard public/private key pair - Fused by OEM (e.g., Dell, HP, Lenovo), checked by BIOS_ACM. Only checks Initial Boot Block (IBB) of legacy BIOS region of flash. IBB is responsible for extending policy from there. So, back to AMT bug. I believe Boot Guard (by itself) doesn't help. An exploiter "may" be able to reflash only the ME region and enable AMT even if the OEM has disabled AMT and implemented Boot Guard. Not confirmed, just a educated hunch. Allen

1 0

Re: [coreboot] coreboot Digest, Vol 147, Issue 17
by Trammell Hudson 11 May '17

11 May '17

On Thu, May 11, 2017 at 07:01:47AM -0500, Allen Krell wrote: > One thing I am still confused about is the relationship between Intel Boot > Guard and the regions of flash. My understanding is that Boot Guard only > applies to the legacy BIOS region of flash, not the ME/AMT region. It seems to be even more restricted than that -- the "hardware" part of Bootguard only applies to the startup ACM region in the FIT table of the BIOS region of the flash. That ACM is what is responsible for implementing whatever policy for the rest of the flash. > [...] So, if that is true, then is it possible to flash the ME/AMT > region of flash with any ME code module that has been signed with the Intel > signature? I think so, although I haven't looked at enough to determine if the different chipsets or CPU models are signed with different keys. Unlike the few startup ACM images that I've looked at have the same public key for their signature, despite being on very different CPU models and from different IBV. -- Trammell

1 0

Re: [coreboot] coreboot Digest, Vol 147, Issue 17
by Allen Krell 11 May '17

11 May '17

On Thu, May 11, 2017 at 5:00 AM, <coreboot-request(a)coreboot.org> wrote: > > > Message: 2 > Date: Tue, 9 May 2017 17:26:18 -0400 > From: "Taiidan(a)gmx.com" <Taiidan(a)gmx.com> > To: ron minnich <rminnich(a)gmail.com>, coreboot <coreboot(a)coreboot.org> > Subject: Re: [coreboot] AMT bug > Message-ID: <278e53ae-1788-4205-e51b-7f632faa6927(a)gmx.com> > Content-Type: text/plain; charset=windows-1252; format=flowed > > On 05/08/2017 12:40 AM, ron minnich wrote: > > > I thought the whole reflash path of AMT was to ask it to reflash itself. > Is > > that incorrect? If correct, and the AMT has been exploited via this path, > > can we really trust any reflash operation? Any thoughts on this from > anyone > > who knows? > Yeah its a request, that can be denied or stealth-denied so it can't be > trusted. > I had a BIOS update on an older intel board go wrong as I had set in the > ME OPROM "Firmware Update" to "Deny" it would be very simple to mess > with the ME region re-writer programmer to re-add a backdoor to every > internal flashed image, and how many corps actually flash externally? > (none I assume) > One thing I am still confused about is the relationship between Intel Boot Guard and the regions of flash. My understanding is that Boot Guard only applies to the legacy BIOS region of flash, not the ME/AMT region. Is that correct? So, if that is true, then is it possible to flash the ME/AMT region of flash with any ME code module that has been signed with the Intel signature?

1 0

Request for reviewing Coreboot/VBT
by Zoran Stojsavljevic 11 May '17

11 May '17

Hello Community, Here is the request for reviewing the latest and greatest WIKI Coreboot/VBT: https://en.wikipedia.org/wiki/Coreboot/VBT I would like to thank you in advance! Zoran Stojsavljevic

1 0

[ANN] coreboot community meeting today, Thursday, May 11th, 2017
by Paul Menzel 10 May '17

10 May '17

Dear coreboot folks, Please don’t miss the coreboot community meeting [1] today on Thursday, May 11th, 2017. Please add your topics to the pad [2]. To the corporate developers subscribed to the list, it’d be great if you forwarded this to your colleagues. Thanks, Paul PS: I won’t be able to attend to today. Have fun! Regarding the bug tracker discussion, there has only been one response on the list. [1] https://www.coreboot.org/Coreboot_community_meeting [2] https://coreboot-meeting.pads.ccc.de/CommunityMeetingTopics?

1 0

Re: [coreboot] Remote security exploit in all 2008+ Intel platforms
by Peter Stuge 10 May '17

10 May '17

First, thanks to everyone who is working hard to maintain a good tone on the list. I certainly appreciate that. While the ME and that it may have issues ;) is not so big news for many in this community, this is an important news story for IT in general, as it furthers the goal of platform and firmware openness. Sometimes I disagree strongly with Ron, but I think he makes a good point here: ron minnich wrote: > I realize feelings are strong about these issues, but calling > people and projects "corrupt" is unacceptable and, in my view > anyway, I'd like people who say such things to find another > project. I watched the Plan 9 mailling list get destroyed by a few > bad actors and I don't want to see that happen here. I don't think saying "corrupt" is neccessarily taboo, but the word needs to be used carefully, or you may just end up poisoning the community - *that* is unacceptable. I would like to take this opportunity to ask a favor of everyone in this community: Don't allow words to poison you too easily. Stay strong. I found this graphic very helpful: http://www.netbooknews.com/wp-content/2011/07/the-pyramid-of-debate-550x417… Don't fall down the pyramid, and don't let anyone else pull you down. It's easy to claim that someone else does the wrong<tm> thing even with good intentions, but you can extrapolate that someone is doing wrong<tm>, just because they seem to have good intentions. And keep in mind that while everyone in the coreboot community seeks open firmware more or less actively, some seek even more open platforms than others. As long as someone is investing in improving the firmware status quo, that is a good thing for all of us, even if the road becomes somewhat longer than we may like. It's not for me to say what someone else spends their time developing. I can disagree, and tell them, as they can with me, but I can't expect them to care. My personal attitude to Librem as far as an open laptop platform goes is that it's too little too late, but that that's not really through any fault of Puri.sm. Sure, I was disappointed by early communication with the company about the difficulties of the task they had set for themselves, and I agree that they have been underestimating the problem. I am guilty of that too at times. The question is what we do to better ourselves. Like Ron, I think it's great that Youness is joining the coreboot community! :) //Peter

3 2

Re: [coreboot] What is the KGPE-D16 PCI audio device for?
by Taiidan＠gmx.com 10 May '17

10 May '17

On 05/10/2017 02:40 AM, BogDan Vatra wrote: > Hi, > > I'm looking to buy a sound card, does anyone know if the Asus MIO-892 > sound card works on linux? > > Cheers, > BogDan. Yeah it does, but honestly you're wasting your money (its overpriced) if you buy that you might as well get a regular PCI-e card and stick it in the x4 as you'll be wasting an x16 PCI-e slot if you use asus's silly MIO stuff (you have to install it in slot 1 on the d8/d16) and no other boards have MIO so its stuck on one computer. Its a crappy realtek chip, so it will work but it won't work well. If I was you I'd get a used pci-e creative soundblaster x-fi, they have great linux support from the company and the sound is way better than the usual realtek or cmedia chips.

3 3

Re: [coreboot] kernel payload
by Trammell Hudson 10 May '17

10 May '17

On Mon, May 08, 2017 at 06:11:52PM -0400, Healer64 via coreboot wrote: > So the question still remains as to how big the initrd image will be > assuming it has to have the necessities to mount root on lvm encrypted > drive. Any idea? The Heads Linux runtime can mount lvm encrypted drives (along with lots of other features) and needs 7 MB for coreboot, the kernel and initrd. If you drop suport for gpg+yubikey, network drivers and a few other things it can fit into 4 MB. https://github.com/osresearch/heads -- Trammell

2 1

← Newer
1
...
8
9
10
11
12
13
14
...
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