coreboot May 2017

coreboot@coreboot.org

70 participants
202 discussions

Start a nNew thread

New on blogs.coreboot.org: Announcing coreboot 4.6
by WordPress 10 May '17

10 May '17

5 4

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

10 May '17

Let me demystify this bug. It is so trivial, at the end of the day, I will ask some questions here, openly on the list!? It is, after all, most of 13K Front Line Managers in INTEL with reputations on stake for this bug, with really questionable (minimum required) qualities, as well as technical, as well as human/personal characteristics! It is just that some INTEL junior programmer was so thrilled about C lib recent acquired knowledge, that (s)he, by unconscious mistake, used f-n strncmp() instead much safer strcmp()??? What about INTEL testing teams? INTEL QA teams?! Zoran Stojsavljevic _______ - MemberBerry <https://arstechnica.com/civis/memberlist.php?mode=viewprofile&u=565983> Wise, Aged Ars Veteran - The article is a bit confusing regarding this, but no, you can't send an empty password. That's because when a browser does digest authentication it doesn't actually send the password, or even a password hash, to the web server. The browser sends instead a response MD5 hash computed on a string composed of various items, including a variable nonce sent by the server, in addition to the password, for example: response=MD5(MD5(username:realm:password):nonce:MD5(method:digestURI)) https://en.wikipedia.org/wiki/Digest_ac ... entication <https://en.wikipedia.org/wiki/Digest_access_authentication> This means a normal browser would never send an empty response, even when you enter an empty password. It would always send a 32 hex digit MD5 hash looking like this: response="6629fae49393a05397450978507c4ef1" The server would then compute the same hash, and compare them. If they are equal, it allows login, if they are different it denies login. The bug was in the code to compare the two strings. It used the strncmp function that compares the first N characters of two strings: strncmp(string1, string2, N) http://www.cplusplus.com/reference/cstring/strncmp/ And applied it to the computed hash and the hash response received from the browser, with N set to the length of the response received from the browser, so something like: strncmp(computed_hash, response, strlen(response)) So when it compared a real hash generated by a browser it would do something like: strncmp("6629fae49393a05397450978507c4ef1","d3d4914a43454b159a3fa6f5a91d801d", 32) This would work just fine for hashes sent by the browser, which are always 32 characters in length. Even if the password field is empty, it would compare the two strings, they wouldn't match, and it would reject the empty password or invalid password. So anyone testing this from a browser would find it works perfectly. The problem is what happens if you don't use a browser, but you generate an invalid request manually or using a proxy to alter the response, sending an empty string instead of the 32 character hash. Then the compare code does this: strncmp("6629fae49393a05397450978507c4ef1","",0) This means the function will compare the first 0 characters between the two strings. So it is equivalent to: strncmp("","",0) Of course, two 0 length strings are equal, so it wrongfully concludes the hashes are equal. What the programmer should have done is check if the hash coming from the browser has the correct length, 32 characters, before attempting to compare the two strings. Or even better, the programmer should have used the proper string comparing function, strcmp, that already does that for you and you don't need to supply a length parameter, like this: strcmp(string1, string2) http://www.cplusplus.com/reference/cstring/strcmp/ On Mon, May 8, 2017 at 8:32 PM, Rene Shuster <rene.shuster(a)bcsemail.org> wrote: > In case you missed it: https://www.tenable.com/blog/ > rediscovering-the-intel-amt-vulnerability > > On Fri, May 5, 2017 at 8:10 AM, Peter Stuge <peter(a)stuge.se> wrote: > >> 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.jpg >> >> 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 >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot >> > > > > -- > Tech III * AppControl * Endpoint Protection * Server Maintenance > Buncombe County Schools Technology Department Network Group > ComicSans Awareness Campaign <http://comicsanscriminal.com> > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot >

1 0

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

10 May '17

I notice the kgpe-d16 has an AMD PCI audio device, but I am curious as to what the purpose of that PCI device is - the weird MIO audio card that ASUS sells appears to have its own realtek chip so I don't think it is that. Is there some kind of header on the board that I am not noticing? does anyone know how to use the boards audio? or should I just remove it to save on MMIO space.

2 1

Re: [coreboot] Will we maintain Skylake/FSP1.1?
by Zoran Stojsavljevic 10 May '17

10 May '17

You do not know which solution is worse: FSP 1.1, or FSP 2.0?! FSP 1,1 is useless (since many problems in IOTG PED group), and FSP 2.0 is getting more complicated (due to INTEL internal job security protection). It is on your own peril, folks. I should say, at least FSP 2.0 is easier to crack (IMHO)! ;-) Zoran On Wed, May 10, 2017 at 12:36 AM, Leahy, Leroy P <leroy.p.leahy(a)intel.com> wrote: > Hi Nico, > > The Galileo board also supports both FSP 1.1 and FSP 2.0. > > Lee Leahy > (425) 881-4919 > Intel Corporation > Suite 125 > 2700 - 156th Ave NE > Bellevue, WA 98007-6554 > > -----Original Message----- > From: Nico Huber [mailto:nico.h@gmx.de] > Sent: Tuesday, May 9, 2017 3:27 PM > To: Youness Alaoui <kakaroto(a)kakaroto.homelinux.net>; Aaron Durbin < > adurbin(a)google.com> > Cc: Alexander Couzens <lynxis(a)fe80.eu>; Nico Huber <nico.huber(a)secunet.com>; > Leahy, Leroy P <leroy.p.leahy(a)intel.com>; Duncan Laurie < > dlaurie(a)chromium.org>; coreboot(a)coreboot.org > Subject: Re: [coreboot] Will we maintain Skylake/FSP1.1? > > On 09.05.2017 18:47, Youness Alaoui wrote: > > I thought FSP 1.1 was for skylake and FSP 2.0 for Kabylake, I didn't > > realize 2.0 would be compatible with skylake too. Does this mean a > > skylake port could use fsp 1.1 or 2.0 ? In that case, is the 2.0 > > version better maintained, more stable, easier to integrate, etc.. or > > are both 1.1 and 2.0 implementations equivalent at this point? > > Yes, the Kaby Lake release should be compatible with Skylake too. I'd > expect the resulting coreboot to be feature equivalent. The Kconfig option > MAINBOARD_USES_FSP2_0 is not tied to SOC_INTEL_KABYLAKE and there is one > board (intel/kunimitsu) that implements both interfaces. > > Generally, the FSP 2.0 hook-up looks to be in a better shape, though. > > > I also don't see the 2.0 release in https://github.com/IntelFsp/FSP/ > > so I assume getting my hands on it would mean grabbing it from somewhere > else.... > > It's not released yet and I also struggle to find it. I had access to > pre-releases in the Intel Business Portal, but that is gone and I don't > know yet what to type into the search box on intel.com to find something > useful :-/ Would be great if anyone could give us a pointer. > > Nico > > > > > Thanks, > > Youness. > > > > On Tue, May 9, 2017 at 11:19 AM, Aaron Durbin <adurbin(a)google.com> > wrote: > > > >> On Tue, May 9, 2017 at 10:14 AM, Nico Huber <nico.huber(a)secunet.com> > >> wrote: > >>> Hi, > >>> > >>> I was walking through the Skylake FSP1.1 support in coreboot and > >>> asked myself if it is worth to clean it up and maintain the code? > >>> given that the upcoming release of Kabylake FSP should be able to > >>> supersede it (I presume it is?). Are there any plans yet to drop it > >>> once the next FSP is released? (when will that be anyway?) > >> > >> I wanted to get rid of it, but Intel claimed they had customers using > >> it still. > >> > >>> > >>> Btw. does anybody feel like a maintainer for soc/intel/skylake/? > >> > >> Personally feel? Or want? > >> > >>> > >>> In it's current state it's very hard to use from a mainboard > >>> porter's point of view. Many of the selectable Kconfig settings are > >>> useless (either don't compile or don't run) for FSP1.1, and there's > >>> a `struct pei_data` [1] that seems to be a remnant of compatibility > >>> for a dif- ferent blob ;) > >> > >> That's just an old remnant of passing data around. It could be > >> removed as you annotated isolating those pieces to different structs > >> and/or variables for passing data around. The name is obviously not > >> applicable w.r.t. its current use. > >> > >>> > >>> Best regards, > >>> Nico > >>> > >>> PS. Microcode updates are also missing in the upstream blobs repo. Is > >>> that a licensing problem? If I try to download them from Intel, it > >>> asks me to click to accept that I'll prevent further distribution. > >>> I could prepare a patch to add them but somebody else would have > >>> to sign it off. > >>> > >>> [1] https://review.coreboot.org/#/c/19638/ > >>> > >> > > > > > > > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] AMT bug
by Zoran Stojsavljevic 10 May '17

10 May '17

*A remote hijacking flaw that lurked in Intel chips for seven years was more severe than many people imagined, because it allowed hackers to remotely gain administrative control over huge fleets of computers without entering a password. This is according to technical analyses published Friday.* For *se7en* years. INTEL, please, keep up the good job! Zoran On Wed, May 10, 2017 at 1:14 AM, ron minnich <rminnich(a)gmail.com> wrote: > > > On Tue, May 9, 2017 at 3:25 PM Taiidan(a)gmx.com <Taiidan(a)gmx.com> wrote: > >> >> How come risv-v has no DMA security features? ala IOMMU? if you want to >> do virtualization that is also a must have due to the performance >> differential - you couldn't push 1gbps on a emulated NIC without serious >> processing power. >> >> > well, because they are in their very first years, and survival is job 1, > followed some time later by achieving high end performance. > > And, further, if you look at lowrisc, it's not even clear you want a dma > engine. maybe a core running one and only one kernel thread that moves data > is what you want. > > But we'll see. One thing at a time. Survival ahead of everything else. > > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot >

1 0

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

09 May '17

The ASUS KGPE-D16 fails verification for branch master as of commit 293445ae1f93d38b86b1c1a3c9ee40ec96a36fac The following tests failed: BOOT_FAILURE Commits since last successful test: 293445a nb/intel/x4x: Add support for second PEG slot 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] Will we maintain Skylake/FSP1.1?
by Nico Huber 09 May '17

09 May '17

On 09.05.2017 18:47, Youness Alaoui wrote: > I thought FSP 1.1 was for skylake and FSP 2.0 for Kabylake, I didn't > realize 2.0 would be compatible with skylake too. Does this mean a skylake > port could use fsp 1.1 or 2.0 ? In that case, is the 2.0 version better > maintained, more stable, easier to integrate, etc.. or are both 1.1 and 2.0 > implementations equivalent at this point? Yes, the Kaby Lake release should be compatible with Skylake too. I'd expect the resulting coreboot to be feature equivalent. The Kconfig option MAINBOARD_USES_FSP2_0 is not tied to SOC_INTEL_KABYLAKE and there is one board (intel/kunimitsu) that implements both interfaces. Generally, the FSP 2.0 hook-up looks to be in a better shape, though. > I also don't see the 2.0 release in https://github.com/IntelFsp/FSP/ so I > assume getting my hands on it would mean grabbing it from somewhere else.... It's not released yet and I also struggle to find it. I had access to pre-releases in the Intel Business Portal, but that is gone and I don't know yet what to type into the search box on intel.com to find something useful :-/ Would be great if anyone could give us a pointer. Nico > > Thanks, > Youness. > > On Tue, May 9, 2017 at 11:19 AM, Aaron Durbin <adurbin(a)google.com> wrote: > >> On Tue, May 9, 2017 at 10:14 AM, Nico Huber <nico.huber(a)secunet.com> >> wrote: >>> Hi, >>> >>> I was walking through the Skylake FSP1.1 support in coreboot and asked >>> myself if it is worth to clean it up and maintain the code? given that >>> the upcoming release of Kabylake FSP should be able to supersede it (I >>> presume it is?). Are there any plans yet to drop it once the next FSP >>> is released? (when will that be anyway?) >> >> I wanted to get rid of it, but Intel claimed they had customers using it >> still. >> >>> >>> Btw. does anybody feel like a maintainer for soc/intel/skylake/? >> >> Personally feel? Or want? >> >>> >>> In it's current state it's very hard to use from a mainboard porter's >>> point of view. Many of the selectable Kconfig settings are useless >>> (either don't compile or don't run) for FSP1.1, and there's a `struct >>> pei_data` [1] that seems to be a remnant of compatibility for a dif- >>> ferent blob ;) >> >> That's just an old remnant of passing data around. It could be removed >> as you annotated isolating those pieces to different structs and/or >> variables for passing data around. The name is obviously not >> applicable w.r.t. its current use. >> >>> >>> Best regards, >>> Nico >>> >>> PS. Microcode updates are also missing in the upstream blobs repo. Is >>> that a licensing problem? If I try to download them from Intel, it >>> asks me to click to accept that I'll prevent further distribution. >>> I could prepare a patch to add them but somebody else would have >>> to sign it off. >>> >>> [1] https://review.coreboot.org/#/c/19638/ >>> >> > > >

2 1

Re: [coreboot] Will we maintain Skylake/FSP1.1?
by Nico Huber 09 May '17

09 May '17

On 09.05.2017 17:19, Aaron Durbin via coreboot wrote: > On Tue, May 9, 2017 at 10:14 AM, Nico Huber <nico.huber(a)secunet.com> wrote: >> Hi, >> >> I was walking through the Skylake FSP1.1 support in coreboot and asked >> myself if it is worth to clean it up and maintain the code? given that >> the upcoming release of Kabylake FSP should be able to supersede it (I >> presume it is?). Are there any plans yet to drop it once the next FSP >> is released? (when will that be anyway?) > > I wanted to get rid of it, but Intel claimed they had customers using it > still. Hmmm, if we touch the interface of the FSP driver, any downstream board port that wants to keep track of upstream would have to be updated any- way. Would be nice to know what these customers expect, and when and why they synchronize with upstream. > >> >> Btw. does anybody feel like a maintainer for soc/intel/skylake/? > > Personally feel? Or want? You mean if I'm interested? No, not atm. Would also depend on what this discussion will lead to. I was actually asking more if I missed to CC somebody. Nico > >> >> In it's current state it's very hard to use from a mainboard porter's >> point of view. Many of the selectable Kconfig settings are useless >> (either don't compile or don't run) for FSP1.1, and there's a `struct >> pei_data` [1] that seems to be a remnant of compatibility for a dif- >> ferent blob ;) > > That's just an old remnant of passing data around. It could be removed > as you annotated isolating those pieces to different structs and/or > variables for passing data around. The name is obviously not > applicable w.r.t. its current use. > >> >> Best regards, >> Nico >> >> PS. Microcode updates are also missing in the upstream blobs repo. Is >> that a licensing problem? If I try to download them from Intel, it >> asks me to click to accept that I'll prevent further distribution. >> I could prepare a patch to add them but somebody else would have >> to sign it off. >> >> [1] https://review.coreboot.org/#/c/19638/ >> >

1 0

Re: [coreboot] Intel ME The Way of the Static Analysis
by Denis 'GNUtoo' Carikli 09 May '17

09 May '17

On Tue, 25 Apr 2017 22:38:15 +0800 Shawn <citypw(a)gmail.com> wrote: > slide: > https://www.troopers.de/downloads/troopers17/TR17_ME11_Static.pdf > > video: > https://www.youtube.com/watch?v=2_aokrfcoUk > Thanks a lot! This is very interesting. I probably missed something about the ROM bypass: Since you have flash images with ROM Bypass in use, what would prevent someone from: - Finding and buying hardware with ROM bypass enabled. Are there any business or consumers laptops/desktops/workstation with such feature? - Writing your own code in the ROM ME partition and executing it. Denis.

4 3

Re: [coreboot] How can improve coreboot and become developer?
by ron minnich 09 May '17

09 May '17

the very small group of us doing riscv would certainly be delighted were you to join us :-) On Tue, May 9, 2017 at 12:31 PM serdar tunc <serdarot5(a)gmail.com> wrote: > Hello, > > I am interested in coreboot project. I compiled coreboot, made my own > rom for my x200 and installed via external flasher. And i read a book > named "Embedded Firmware Solutions" for understanding coreboots > working logic. And im in deadend now. Because i accomplish to have > fully operational x200 and i think i might know all the installing > stages. > But i dont want to be only user. I want to improve coreboot project > and become developer. So i searched your wiki but i couldnt find for > that. What should i do first? Do you have groups and mentors for that? > thank all of you for your attention. > > Have a nice day, with my best regards. > > Serdar Oktay TUNÇ > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

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