coreboot May 2017

coreboot@coreboot.org

70 participants
202 discussions

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

02 May '17

On 02.05.2017 16:20, ron minnich wrote: > On Tue, May 2, 2017 at 3:54 AM Nico Huber <nico.huber(a)secunet.com> wrote: > >> >> >> You sound much like their advertisement. >> >> > > OK, I'm done here. Have a nice project everyone. When people start making > statements like this and accusing the project of being corrupt, it's time > to stop reading a list. Sorry Ron, I didn't write it to offend you. I just read their product page before writing that stupid statement above. And that page seemed to smash again empty promises into my face. That's no excuse for what I wrote, just trying to explain how it happened. Please understand that talking about Purism may still reawake bad fee- lings. At the beginning they sold so much and shipped nothing. And people believe that they have drawn customers away from vendors who actually supported free firmware. By that, making people who wanted to pay for free firmware pay for proprietary firmware instead. At least this is how I remember the story. Obviously we have a very dif- ferent view on it. And also how far x86 can be freed from blobs. I still hope Purism will, in the end, accomplish more than you say is possible. Nico

2 1

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

02 May '17

The ASUS KGPE-D16 fails verification for branch master as of commit e70142c9c2e2b7b4fbf8883790df72b6d5536c19 The following tests failed: BOOT_FAILURE Commits since last successful test: e70142c soc/intel/apollolake: Clean up code by using common FAST_SPI module 7146445 soc/intel/skylake: Clean up code by using common FAST_SPI module 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] Why does src/soc/intel/ exist?
by Arthur Heymans 02 May '17

02 May '17

Ok thanks for clarifying. Aaron Durbin <adurbin(a)google.com> writes: > On Tue, May 2, 2017 at 5:24 AM, Arthur Heymans <arthur(a)aheymans.xyz> wrote: >> Hi >> >> I am wondering why newer intel code is being pushed to src/soc/intel/*/ >> instead of the traditional src/{cpu,southbridge,northbridge}/intel ? > > The era of mix and match ICs is pretty much gone. Even when there are > separate chips on a board there's only a single variant which actually > works in conjunction with the parts. Similarly to the socket > abstraction that closely coupled features to physical sockets it's not > really applicable any longer. It'd be forcing one to separate out > support where things are actually closely related. > Ok that explains a lot. Southbridges could often occur with 2-3 different memory controllers and a similar amount of different CPU. >> >> I know that physically things are now on one chip hence the soc but the >> code itself is often very similar to older cpu/southbridge/northbridge >> code. A good example is for instance smbus: >> https://review.coreboot.org/#/c/19372/ (unify src/soc/intel smbus code) >> https://review.coreboot.org/#/c/19258/ (unify src/southbridge/intel >> smbus code) >> with code that is almost identical so it would be beneficial to have >> this code in common for all intel targets, which is somewhat hindered or >> unpractical due to this dir separation. > > How is that unpractical? I think you are assuming a specific directory > layout? Regardless of where code resides it's certainly possible to > share code. I think what you've pointed out is the timeline when new > development cutover to use src/soc for all the parts as the parts > really are SoC with a close coupling of implementations. The logic > blocks inside the parts are definitely forks of one another just like > software so there is re-use at play. With your change and the other > one we'd have 2 parallel implementations that could be tested for > parity and combined. That said, one needs to be careful in the details > for determining where something can be truly common. In the smbus > stuff specifically I'm sure there has be no real modification in a > very long time, but that isn't true for all blocks. > My main thought was that is a bit sad that efforts to make more code common happens in src/soc/intel/ while there is a lot in src/southbridge/intel that can be set up with identical code (but maybe smbus is indeed the only thing that can cleanly be common without too much per platform guarding). > > The newer code is not separated. It's actually combined? Benefit is > one stop shopping for a given platform for code to reside instead of > laying down multiple directories in various places that doesn't > reflect the construction of the systems. That said, with the > introduction of the common modules the soc/intel directories will > become thinner with selecting the common modules. That reflects more > closely how hardware development is being done. > > Though the soc/ directory layout isn't the only way of making the > following work, it certainly helps. For the purposes of porting a > board based off of another board of a different platform it makes the > code maintenance easier solely based on #include files. There's really > not reason to have to #include a/specific/directory/header to make > something work. If the abstractions are done correctly one can > #include genericpath/header with a conforming API. That allows code > reuse and porting to go more smoothly. If you are having to #ifdef > CONFIG to figure out the include path in the c files that makes the > source ugly and a maintenance burden. This isn't the only the example, > but a good one where there's a ton of #ifdef for include paths: > src/cpu/x86/smm/smmrelocate.S. That's also ignoring the "common" > headers which do or don't expose certain functions that are found in > specific places as well. In short, I think the > southbridge/cpu/northbridge split in how it's been done in the past > actually creates more of a burden. Again, that doesn't mean things > can't be fixed by using consistent and namespaced include paths. > Ok thanks for the insight. Some things that were used by different IC combinations were indeed a mess with amd in particular (but that is probably because a lot of code was not linked) -- Arthur Heymans

2 1

Why does src/soc/intel/ exist?
by Arthur Heymans 02 May '17

02 May '17

Hi I am wondering why newer intel code is being pushed to src/soc/intel/*/ instead of the traditional src/{cpu,southbridge,northbridge}/intel ? I know that physically things are now on one chip hence the soc but the code itself is often very similar to older cpu/southbridge/northbridge code. A good example is for instance smbus: https://review.coreboot.org/#/c/19372/ (unify src/soc/intel smbus code) https://review.coreboot.org/#/c/19258/ (unify src/southbridge/intel smbus code) with code that is almost identical so it would be beneficial to have this code in common for all intel targets, which is somewhat hindered or unpractical due to this dir separation. The same could be said about a lot of LPC code, which has parts that are very similar across multiple generations, like pirq routing. Another thing to note is that dir names are often poorly named like amd where in src/northbridge/amd memory controller code resides, while in src/southbridge the code for both the northbridge and the southbridge resides. So my question is why does the newer codebase need to be separated like this and what is the benefit of doing so? Kind regards ------------ Arthur Heymans

2 1

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

02 May '17

On 02.05.2017 00:44, ron minnich wrote: > On Mon, May 1, 2017 at 1:17 PM Rene Shuster <rene.shuster(a)bcsemail.org> > wrote: > >> Yes Puri.sm has been debunked. >> > > I disagree. I've seen the systems. From what I can see, Puri.sm has made a > good faith effort to go as far possible *with modern x86 chipsets* toward > getting rid of the blobs. They can't get to 100%, but they're trying to get > as close as possible. You sound much like their advertisement. But that's just not true. They haven't made any effort, they just star- ted it. Even if this effort brings us a machine that ships with coreboot in the future, you seem to forget all the 1st generation machines that were promised an open coreboot + open ME firmware. These were a fraud. People paid for something they didn't get and still nobody is working on it (at least I don't know about any coreboot effort for the Librem 15 gen1, or any 15 or 11 at all). I guess things are moving towards the right direction. But denying that the first Purism customers were scammed won't help Purism's reputation in the community. (Not to mention that their advertisement still scams a lot.) Regarding the started effort: AFAIK, it's not (yet) about shipping with coreboot. The current port uses a blob that Purism can't license so the users only get a script to gather blobs and put it together into a blob- boot that they have to install themselves. And even the effort for the next gen doesn't come close to the possible for Intel's x86. Reversing FSP seems pretty easy compared to the ME stuff going on, yet they will ship a fully blobbed coreboot. Nico

2 1

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

02 May '17

On 02.05.2017 04:52, Youness Alaoui wrote: > Ron couldn't be more right when he says that you can't appreciate how much > work it is to go from a "it works" to a "it's tested/verified and made into > a *product* for actual users". It took me 6 months of work to finish the 4 > days of work that Duncan Laurie did (I believe it took him 4 days to do the > initial port, feel free to correct me if I'm mistaken, and yes of course, I > am totally new to the coreboot world, so a lot/most of that time was spent > on the learning curve). Well, I interpret Ron very differently... I think you are at the "it works" state. 6 months of coding are the easy part where you don't have to convince other entities to use your code. Let's wait until you have made it into a shipping product and reflect then. I guess the really tricky part comes when you ask your contractor not to license the UEFI they usually ship (i.e. don't let your coreboot customers pay for the other side). Nico

2 1

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

02 May '17

On 02/05/2017, Youness Alaoui <kakaroto(a)kakaroto.homelinux.net> wrote: > For actual ME-related work that wasn't done by someone else, I will point > you to this file : > https://github.com/kakaroto/purism-playground/blob/master/me_re/romp.c > That is a full C re-implementation of the ROMP module (the smallest of the > two modules that me_cleaner does not remove). > This is the RAPI header it uses : > https://github.com/kakaroto/purism-playground/blob/master/me_re/rapi.h > That code is a C reimplementation with every instruction accounted for. It > has not been compiled (it serves more as a proof of concept/pseudocode, > although it should probably compile), and it's not meant to generate a > binary-compatible file (that could be a long term goal to generate binary > compatible images from C source with official intel-provided images). > Note that I have done the entire Assembly->C conversion myself > > [...] > > Ultimately I hope we can get full unsigned code execution running, and full > auditable C code equivalent of any binary code that gets executed between > power-on and the exploit/custom code being executed. Kudos for this work. It would be great to have auditable code running there. Forgive my noob question, but: why C instead of a safer language or language subset (e.g. Coq, Agda, Idris, SPARK, Compcert (if you don't mind the non-free license), or even Go or Rust), especially given how small yet fundamental that code is to the system? Within and outside Coreboot, the desire to use safer techniques than C programming, and the actual shift to using them, is, thankfully, starting to happen. See: Nico Huber's use of SPARK for Coreboot graphics: - https://firmwaresecurity.com/2016/09/20/coreboot-now-supports-ada/ Trammell Hudson's wish for a formally-verifiable Coreboot payload such as sel4 or CertiKOS: - https://mail.coreboot.org/pipermail/coreboot/2016-December/082606.html Ron Minnich points out the advantage of using Go rather than C for u-root: - https://mail.coreboot.org/pipermail/coreboot/2017-April/083891.html Quinn Norton's epigram, "C is good for two things: being beautiful and creating catastrophic 0days in memory management." (N.B. I'm not sure about the first thing): - https://medium.com/message/everything-is-broken-81e5f33a24e1 Reasons why Xen should consider taking langsec seriously: - http://trevorjim.com/deconstructing-xen-snark/

1 0

Re: [coreboot] Remote security exploit in all 2008+ Intel platforms
by Taiidan＠gmx.com 02 May '17

02 May '17

On 05/01/2017 10:52 PM, Youness Alaoui wrote: > On Mon, May 1, 2017 at 7:22 PM, Taiidan(a)gmx.com <Taiidan(a)gmx.com> wrote: > >> On 05/01/2017 06:44 PM, ron minnich wrote: >> >> On Mon, May 1, 2017 at 1:17 PM Rene Shuster <rene.shuster(a)bcsemail.org> >>> wrote: >>> >>> Yes Puri.sm has been debunked. >>>> I disagree. I've seen the systems. From what I can see, Puri.sm has made >>> a >>> good faith effort to go as far possible *with modern x86 chipsets* toward >>> getting rid of the blobs. They can't get to 100%, but they're trying to >>> get >>> as close as possible. >>> >>> ron >>> >> Name one thing that they have done themselves? >> >> https://www.reddit.com/r/linux/comments/3anjgm/on_the_librem >> _laptop_purism_doesnt_believe_in/ (yeah its leah but shes right about the >> coreboot community being corrupted) >> >> Everything they "do" is someone elses code, and their "coreboot" has zero >> actual init code it is entirely blobbed. >> >> Their marketing is the only thing that is good. >> >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot >> > Without entering into a flamewar, you're asking "name one thing that they > have done themselves" and I will answer that. > Full disclaimer: I am working for Purism, and I have been a paid contractor > working since last December (part time initially, full time since March) on > bringing coreboot and the ME-disablement effort to the Librem line of > laptops (more precisely Librem 13 v1, and now working on the Librem 13 v2 > hardware which is set to be released/shipped next month). I don't wanna argue this as it never leads anywhere but one more thing why haven't you guys set realistic easily attainable goals such as: FM2 laptop. KCMA-D8 laptop, with an 35W EE CPU, custom case battery keyboard ETC. multi-core ARM laptop - see the Gigabyte MP30 for an example of a non-mobile, performance ARM system. Both can easily be brought up to an RYF standard, but as it stands your products still don't have even native init - making "coreboot" pointless as it is simply a wrapper layer. The only way a new intel/amd laptop is going to be "RYF" is if the standard is diluted. It doesn't matter if you eventually somehow figure out how to run unsigned ME code, that is illegal under the DMCA so it can't be sold. Anything is possible if you throw millions of reverse engineering dollars at it, but all that is good for is black hat stuff because the moment you release it to the world intel will patch the "security flaw" - which brings me back to the realistic goals.

1 0

Re: [coreboot] Remote security exploit in all 2008+ Intel platforms
by Taiidan＠gmx.com 02 May '17

02 May '17

On 05/01/2017 06:44 PM, ron minnich wrote: > On Mon, May 1, 2017 at 1:17 PM Rene Shuster <rene.shuster(a)bcsemail.org> > wrote: > >> Yes Puri.sm has been debunked. >> > I disagree. I've seen the systems. From what I can see, Puri.sm has made a > good faith effort to go as far possible *with modern x86 chipsets* toward > getting rid of the blobs. They can't get to 100%, but they're trying to get > as close as possible. > > ron Name one thing that they have done themselves? https://www.reddit.com/r/linux/comments/3anjgm/on_the_librem_laptop_purism_… (yeah its leah but shes right about the coreboot community being corrupted) Everything they "do" is someone elses code, and their "coreboot" has zero actual init code it is entirely blobbed. Their marketing is the only thing that is good.

3 2

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

02 May '17

On Mon, May 01, 2017 at 10:44:45PM +0000, ron minnich wrote: > On Mon, May 1, 2017 at 1:17 PM Rene Shuster <rene.shuster(a)bcsemail.org> > > Yes Puri.sm has been debunked. > > I disagree. I've seen the systems. From what I can see, Puri.sm has made a > good faith effort to go as far possible *with modern x86 chipsets* toward > getting rid of the blobs. They can't get to 100%, but they're trying to get > as close as possible. I've spoken with the puri.sm team about their coreboot plans and, beyond just my delight that they are working on using the Heads bootloader, I'm really pleased that they've committed to adding hardware features like a discrete TPM, supporting coreboot, testing with the ME cleaner scripts, and really significantly, ensuring that Bootguard can be implemented in a way that preserves user freedom while also protecting against many classes of physical attacks on the system. -- Trammell

1 0

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