coreboot May 2017

coreboot@coreboot.org

70 participants
202 discussions

Re: [coreboot] Bootguard signing keys
by Trammell Hudson 15 May '17

15 May '17

On Thu, May 11, 2017 at 9:56 AM, Trammell Hudson <hudson(a)trmm.net> wrote: > 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. On Thu, May 11, 2017 at 10:30:48AM -0500, Allen Krell wrote: > 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. As an update to this, I have found a different key in the bootguard startup ACM for a Lenovo X1 Carbon 4th gen: 00000080: c71ac1e2 a457e7fc aa585572 afe2baab .....W...XUr.... 00000090: fcfc17ba fbc5eed9 71e12883 a268f7ea ........q.(..h.. 000000a0: 6e2c9738 f493d7f5 97144b1a f3f18715 n,.8......K..... 000000b0: 6839783c 503392c9 2088f89c 75bdbc43 h9x<P3.. ...u..C 000000c0: 0e9ba63d e6890cac 5f221779 09d7c2cf ...=...._".y.... 000000d0: cda313f0 c7e29993 2558b740 3bd1d2df ........%X.@;... 000000e0: b4874f4f c7dce345 24d89640 4b64fa1e ..OO...E$..@Kd.. 000000f0: 88af6349 439827f1 39243f4b d63ae297 ..cIC.'.9$?K.:.. 00000100: e2353a58 37f0ed05 701f057e 39baf3bd .5:X7...p..~9... 00000110: 8007f1a1 ad52bae4 0964465e 1d04304b .....R...dF^..0K 00000120: 63221dc2 fb5fd2a6 2d2ae7db 2fd47f62 c"..._..-*../..b 00000130: c993f490 f5c7f43e abc6b45d b20ecc69 .......>...]...i 00000140: 863550d4 8bb390fd 5ebf45af c3a7af05 .5P.....^.E..... 00000150: 13961217 32caf132 8f79cbbd 0c96fcee ....2..2.y...... 00000160: 819cdeb2 e0e5b1e8 9a3b3bb7 9d7167dd .........;;..qg. 00000170: ef31f663 95956490 5edd6a7f a7f75aee .1.c..d.^.j...Z. 00000180: 11000000 The Dell r630 and Lenovo T550 use the same key, however: 00000080: 83078196 86ad3389 c5da1fc8 639e24e2 ......3.....c.$. 00000090: 55563072 6eb5c30b 8b7da228 5f4bcfc6 UV0rn....}.(_K.. 000000a0: 278092a1 9c9bc285 23181522 8291dbf0 '.......#..".... 000000b0: 9d61f68e 2a5d8670 50cc2ff7 537e6859 .a..*].pP./.S~hY 000000c0: 0eedd676 9d4c7906 bb52ec3c edbe9f03 ...v.Ly..R.<.... 000000d0: eecac913 03c46372 006f2cd6 8ba70379 ......cr.o,....y 000000e0: 4f43a334 40a0ec04 4928309e 12400496 OC.4@...I(0..@.. 000000f0: ec92e7e0 f8bd1afc 959b848f 52a31035 ............R..5 00000100: ef0d2939 b84b75ea fd016c2a 6b308a76 ..)9.Ku...l*k0.v 00000110: ce14b9ba f026c8a9 9bb75c4f 8f009963 .....&....\O...c 00000120: 26fd2b7e 12de4207 b647ee54 cddc228e &.+~..B..G.T..". 00000130: 0b58e6e2 0a0caa2f d88c8d93 0d300e0a .X...../.....0.. 00000140: 28300048 0cac01da 8255c85b 802b2f58 (0.H.....U.[.+/X 00000150: f407848e 49c222ad 33b9d0c0 5dec674b ....I.".3...].gK 00000160: db6f9150 cc55a5f2 0174858f c285a7ec .o.P.U...t...... 00000170: 4e40aabf 28eda44b 7faaba20 f33aa8d3 N@..(..K... .:.. 00000180: 11000000 -- Trammell

1 0

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

15 May '17

The ASUS KGPE-D16 fails verification for branch master as of commit bddf86a2594e809c32269508807fb4a4c50d573e The following tests failed: BOOT_FAILURE Commits since last successful test: bddf86a vexpress: change to write32 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

Has anyone had issues with coreboot's 32bit MMIO space?
by Taiidan＠gmx.com 15 May '17

15 May '17

I am curious, has anyone else had issues with coreboots 32bit MMIO space? This can result in a "Not enough MMIO resources for SR-IOV" error when you try to enable SR-IOV, and if you have more than 6 nics, or if you have a few GPU's you'll max the MMIO space limit. I noticed it is more pronounced with older gen non native pci-e multi-port nics such as a multi-port 82576L as the PCI-e switches consume extra resources - a quad port i350 uses less than a quad port 82576L so you can enable a few VF's on some of the ports before encountering trouble.

1 0

Reverse-engineering the Intel Management Engine’s ROMP module
by Shawn 14 May '17

14 May '17

URL: https://puri.sm/posts/reverse-engineering-the-intel-management-engine-romp-… C pseudo code of ROMP could make us better understand how it works: https://github.com/kakaroto/purism-playground/tree/master/me_re btw: We're collecting any info about ME. Feel free to edit the file: https://github.com/hardenedlinux/firmware-anatomy/blob/master/hack_ME/me_in… -- GNU powered it... GPL protect it... God blessing it... regards Shawn

1 0

KGPE-D16 - how to get PCI-e x16 on Slot 4?
by Taiidan＠gmx.com 14 May '17

14 May '17

According to the asus documentation it should be x16 if slot 2 is unoccupied, which it is. I currently only have x8, I have tried changing the gpp config in devicetree.cb based on the SR5690 documentation but that results in a coreboot bootloop. How many PCI-e slots can you use concurrently with PCI-e cards anyway? according to the manual it seems as though you can only do 4 although there are 5 physical slots. - Thanks!

1 0

[RFC] Removing RTC configurable baud rate
by Arthur Heymans 13 May '17

13 May '17

Hi In the latest CCM[1] the question was raised whether someone still uses the configuration option baud_rate from RTC nvram (CMOS) and if not maybe think about removing this. The issues raised with this code were: * they are an extra burden to maintain since console init is done over multiple stages and needs different code paths over ROMCC and GCC; * Its not buildtested so easy to miss breakages; * Many boards don't have an cmos.defaults so it often ends up at weird settings. Granted many of these issues need separate fixing anyway: we need cmos.default on each board that has cmos.layout, default Kconfig options could be changed to build test this. So the question is: is someone still using the possibility to configure uart baud rates from rtc nvram. (Keep in mind that is still possible to set the default baud rate from Kconfig options) I already created a RFC patch that removes it: https://review.coreboot.org/#/c/19682/ [1] https://mail.coreboot.org/pipermail/coreboot/2017-May/084266.html CCM report Kind regards ------------ Arthur

2 1

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

13 May '17

The ASUS KGPE-D16 fails verification for branch master as of commit cfd433b96daa2d2f7f4f99fff7608e110b64dca4 The following tests failed: BOOT_FAILURE Commits since last successful test: cfd433b nb/intel/x4x: Fix uninitialized variable issue 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] Platform / Chip removals after upcoming releases
by Peter Stuge 12 May '17

12 May '17

Martin Roth wrote: > 146 Platforms currently scheduled for removal after 4.7 if no work is done > to update them This is a long list. Is the requirement actually on the individual boards, or is it something that could be fixed in a single location and then apply more widely? //Peter

2 1

Re: [coreboot] Help with i915
by Zoran Stojsavljevic 12 May '17

12 May '17

Hello Joshua, Now, I am confused even more... Since you gave me the precise answers, which I (by experience) assumed. And [1] was a lacmus. I wanted to test and see, what the proper solution will be for [1]. And... After reading your answers, I had a vision (I am very proud of this, UN-mistakable 6th sense, and sometimes I see beyond Reality/see dead people, God's Gift). So, suddenly in my brain, the dead lock was created about this particular topic. So I engaged my personal intel(ligence) to find more about you, to unlock this virtual dead lock. I'll apologise in advance to reveal these data, but, in my defence, I should say that these all data about you are (after all) public. So I found the following about you: https://www.linkedin.com/in/joshua-pincus-077a07 It it very well done description of yourself. And, YES, it solves some mysteries, but creates some more (very deep problems inside business hierarchy). And here we are! ;-) [A] You are employed by Wind River. Good. Isn't it that INTEL (in Y2012, if I am not mistaken) purchased Wind River? Isn't it that Wind River is 100% owned by INTEL??? [B] If is it so, WHY you contacted this Open Source list, in the first place, about problem [1], since you are (by all means) INTEL insider??? You are using BDW INTEL Core 5 CPU, so you are (after all) INTEL, so you should internally submit ticket to INTEL VPG? [C] INTEL VPG (GFX) Group had this problem with HSW (do NOT ask how do I know, this is an aksioma at this point), exact the same, HYP 1 problem... So asking internally them, they'll reveal to you immediately the correct solution? What is going on here??? Some weird, completely out of control, beyond any logical reality stuff??? Are you, Wind River, at all cooperating with your mother company called INTEL?! Don't you??? :bang: Zoran On Fri, May 12, 2017 at 2:26 PM, Joshua Pincus <joshua.pincus(a)gmail.com> wrote: > Hi Zoran, > > Please see my inline response below. > > On May 12, 2017 8:13 AM, "Zoran Stojsavljevic" < > zoran.stojsavljevic(a)gmail.com> wrote: > > > > Hello Joshua, > > > > You managed to confuse me, on the very high level.Why, you'll ask? > > > > [1] I have no idea if you ever were able to solve the following issue: > https://www.mail-archive.com/coreboot@coreboot.org/msg48827.html And did > you, after all (and what was the solution, if not secret)? > > [JP] We did solve it. I am sorry I did not post the solution earlier. > The problem was that the video BIOS was not executing the initialization > routines on a guest VM reboot. Consequently, the guest would reboot > without any of the HD graphics registers being re-initialized as they would > on a cold boot. The solution was to extract the video BIOS from the boot > ROM and re-execute the image after the FLR. > > > [2] It seems that you in your original email imply that Linux GFX driver > i915 is used in WIN10 too? Or Linux is actually host, and WIN10 is a VM on > the top of some (which one?) HYP type 2? Or maybe, HYP is type 1? Really, > what is the true OS configuration stack in your case??? > > [JP] Sorry. Here is the stack: Win10 guest running Intel HD graphics Gen8 > driver for video and audio on top of type 1 Hypervisor. > > I am looking at the i915 drm driver for insipiration as well as the VBT > data. So far, I am not seeing anything in the VBT that describes the audio > capabilities of the DisplayPort connected monitor. This is all very > puzzling. > > > > > Any answer would be greatly appreciated. > > JP > > > > > > > Thanks, > > > > ZS > > > > > > On Thu, May 11, 2017 at 10:43 PM, Joshua Pincus <joshua.pincus(a)gmail.com> > wrote: > >> > >> Hey Folks, > >> > >> > >> I've been smacking my head against the wall for 2 weeks. I can't smack > it anymore. There's not much brain left at this point. Here's my issue: > >> > >> > >> I have a Broadwell system with HD Video/Audio support. When Windows 10 > runs native (without a Hypervisor), Windows correctly finds the DisplayPort > adapter and correctly probes whatever it is that it needs to probe to > determine that the adapter in question supports both audio and video > output. When Windows 10 is executed as a guest on top of a Hypervisor, it > correctly finds both the video device @ 0/2/0 and the audio device @ 0/3/0 > but it is unable to detect that the DisplayPort supports audio. > >> > >> > >> > >> I can confirm that both the Intel drivers for video and audio correctly > attach and seem to be running perfectly inside the guest VM. All of the > PCI BARs associated with both devices are correctly being mapped to the > Windows 10 guest. It is my guess that Windows is looking at something > other than the EDID extracted from the attached monitor or the MMIO BAR for > the PCI audio or video devices to determine that audio is supported by the > attached hardware. Indeed, if I probe the EDID information from the guest, > I see that the attached monitor supports audio. > >> > >> > >> > >> My question is this: Is there something else other than the PCI BARs > associated with the onboard HD graphics and HD audio devices that are > required for a Windows or a Linux guest to detect the physical presence of > audio hardware associated with an attached monitor via HDMI or DP? Is > there an MCH or PCH register? My guess is that I am not mapping ALL of the > BARs or IO ports into the guest to allow Windows to probe the hardware > properly. Something is missing. I can’t figure out what that something is. > >> > >> > >> > >> Any help would be greatly appreciated. > >> > >> > >> > >> Thanks, > >> > >> JP > >> > >> > >> -- > >> coreboot mailing list: coreboot(a)coreboot.org > >> https://mail.coreboot.org/mailman/listinfo/coreboot > > > > >

1 0

Re: [coreboot] Help with i915
by Nico Huber 12 May '17

12 May '17

On 12.05.2017 14:26, Joshua Pincus wrote: > Hi Zoran, > > Please see my inline response below. > > On May 12, 2017 8:13 AM, "Zoran Stojsavljevic" < > zoran.stojsavljevic(a)gmail.com> wrote: >> >> Hello Joshua, >> >> You managed to confuse me, on the very high level.Why, you'll ask? >> >> [1] I have no idea if you ever were able to solve the following issue: > https://www.mail-archive.com/coreboot@coreboot.org/msg48827.html And did > you, after all (and what was the solution, if not secret)? > > [JP] We did solve it. I am sorry I did not post the solution earlier. The > problem was that the video BIOS was not executing the initialization > routines on a guest VM reboot. Consequently, the guest would reboot > without any of the HD graphics registers being re-initialized as they would > on a cold boot. The solution was to extract the video BIOS from the boot > ROM and re-execute the image after the FLR. > >> [2] It seems that you in your original email imply that Linux GFX driver > i915 is used in WIN10 too? Or Linux is actually host, and WIN10 is a VM on > the top of some (which one?) HYP type 2? Or maybe, HYP is type 1? Really, > what is the true OS configuration stack in your case??? > > [JP] Sorry. Here is the stack: Win10 guest running Intel HD graphics Gen8 > driver for video and audio on top of type 1 Hypervisor. > > I am looking at the i915 drm driver for insipiration as well as the VBT > data. So far, I am not seeing anything in the VBT that describes the audio > capabilities of the DisplayPort connected monitor. This is all very > puzzling. VBT was just a random guess, I wouldn't know why Intel would put some- thing related there. But it's Intel, you never know. Now that I've looked at some VBT binary description files, I don't see anything ei- ther. So that might be a dead end. Nico > >> >> Any answer would be greatly appreciated. > > JP > >> >> >> Thanks, >> >> ZS >> >> >> On Thu, May 11, 2017 at 10:43 PM, Joshua Pincus <joshua.pincus(a)gmail.com> > wrote: >>> >>> Hey Folks, >>> >>> >>> I've been smacking my head against the wall for 2 weeks. I can't smack > it anymore. There's not much brain left at this point. Here's my issue: >>> >>> >>> I have a Broadwell system with HD Video/Audio support. When Windows 10 > runs native (without a Hypervisor), Windows correctly finds the DisplayPort > adapter and correctly probes whatever it is that it needs to probe to > determine that the adapter in question supports both audio and video > output. When Windows 10 is executed as a guest on top of a Hypervisor, it > correctly finds both the video device @ 0/2/0 and the audio device @ 0/3/0 > but it is unable to detect that the DisplayPort supports audio. >>> >>> >>> >>> I can confirm that both the Intel drivers for video and audio correctly > attach and seem to be running perfectly inside the guest VM. All of the > PCI BARs associated with both devices are correctly being mapped to the > Windows 10 guest. It is my guess that Windows is looking at something > other than the EDID extracted from the attached monitor or the MMIO BAR for > the PCI audio or video devices to determine that audio is supported by the > attached hardware. Indeed, if I probe the EDID information from the guest, > I see that the attached monitor supports audio. >>> >>> >>> >>> My question is this: Is there something else other than the PCI BARs > associated with the onboard HD graphics and HD audio devices that are > required for a Windows or a Linux guest to detect the physical presence of > audio hardware associated with an attached monitor via HDMI or DP? Is > there an MCH or PCH register? My guess is that I am not mapping ALL of the > BARs or IO ports into the guest to allow Windows to probe the hardware > properly. Something is missing. I can’t figure out what that something is. >>> >>> >>> >>> Any help would be greatly appreciated. >>> >>> >>> >>> Thanks, >>> >>> JP >>> >>> >>> -- >>> coreboot mailing list: coreboot(a)coreboot.org >>> https://mail.coreboot.org/mailman/listinfo/coreboot >> >> > > >

1 0

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