coreboot May 2017

coreboot@coreboot.org

70 participants
202 discussions

Re: [coreboot] Help with i915
by Joshua Pincus 12 May '17

12 May '17

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

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 12 May '17

12 May '17

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 1 new defect(s) introduced to coreboot found with Coverity Scan. 4 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 1375009: Uninitialized variables (UNINIT) /src/northbridge/intel/x4x/early_init.c: 73 in x4x_early_init() ________________________________________________________________________________________________________ *** CID 1375009: Uninitialized variables (UNINIT) /src/northbridge/intel/x4x/early_init.c: 73 in x4x_early_init() 67 pci_write_config16(d0f0, D0F0_GGC, 68 0x0100 | ((gfxsize + 1) << 4)); 69 } else { /* Does not feature internal graphics */ 70 pci_write_config32(d0f0, D0F0_DEVEN, D0EN | D1EN | PEG1EN); 71 pci_write_config16(d0f0, D0F0_GGC, (1 << 1)); 72 } >>> CID 1375009: Uninitialized variables (UNINIT) >>> Using uninitialized value "gfxsize". 73 pci_write_config16(d0f0, D0F0_GGC, 0x0100 | ((gfxsize + 1) << 4)); 74 } 75 76 static void init_egress(void) 77 { 78 u32 reg32; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0… To manage Coverity Scan email notifications for "coreboot(a)coreboot.org", click https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

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

12 May '17

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)? [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??? Any answer would be greatly appreciated. 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] Request for reviewing Coreboot/VBT
by Nico Huber 12 May '17

12 May '17

On 11.05.2017 11:29, Zoran Stojsavljevic wrote: > Hello Community, > > Here is the request for reviewing the latest and greatest WIKI Coreboot/VBT: > https://en.wikipedia.org/wiki/Coreboot/VBT Sigh, as you describe ongoing development details, some place like the coreboot wiki [1] might be a better place for this (though people try to abandon this particular wiki). Before the latest additions your page looked like 80% copyright infringement to me, being copy-pasted verba- tim from Linux kernel documentation and mails on this list (it's ok to quote people, but you should ask them). I'll try to give some constructive feedback too: The page title should be "Video BIOS Table" or "Intel Video BIOS Table". It's not directly related to coreboot and having an acronym as title is pretty odd. You should highlight in the introduction that it's an Intel driver spe- cific thing. What an VBIOS is or a GOP is OT. The "Proposal for VBT name change"... that was just an idea to better describe what the VBT is, pretty odd to see my words on Wikipedia. The relation to EDID doesn't look very clear. The VBT can contain mode- lines, yes. But that's just a minor part. Not using an EDID is not (only) a cost-cutting measure, IMHO, but rather to save the time / phy- sical connections to read it. In the "See also" section, I spot only one reference that really makes sense "Video BIOS". Nico [1] https://www.coreboot.org/Welcome_to_coreboot

2 1

coreboot community meeting minutes for May 11, 2017
by Martin Roth 11 May '17

11 May '17

These are the minutes from today's coreboot community meeting. Information about the next meeting is at the bottom. ####################################################################### Thursday, May 11, 2017 General coreboot news & discussions * The coreboot 4.6 release is done. - https://blogs.coreboot.org/blog/2017/05/08/announcing-coreboot-4-6/ - coreboot release page was updated to include release notes. - Documentation on the release process will be added to the coreboot repository shortly. - Look into having multiple people sign the tag and the .sig file. Add this to the documentation. - Add sha256sum.txt to the coreboot downloads page. It's present and up-to-date in the directory, it just wasn't linked on the downloads page. https://coreboot.org/releases/sha256sum.txt - Put release notes into documentation directory. * Work to join SFC is progressing. Should be complete by next CCM. * Announcement about removing platforms after 4.7 & 4.8 releases just went out. - After 4.7 - remove platforms that do not support cbmem in romstage. - After 4.8 - remove platforms that are not shown to be booting in the board-status repo. - Questions about testing - Add list of removed boards to release notes. - In other projects people have the practice of tagging each driver with WORKING/SKELETON/NON-WORKING flags. Whenever a new driver is promoted, it shows up in the release notes. Something similar for the deprecation of boards in coreboot would be useful. State it clearly on each release note. Then perhaps a good thing also would be to keep a log in the website/wiki-page, so that people could quickly find where the old board code is available in the git commit history (preferably with a git tag). * Martin is working to add board library that people can send images to for testing, but this hasn't been looked at in a while. Maybe we can work on this some while Philipp is in colorado for the coreboot conference. * We need to update board_status to handle variants and add more tests than just booting * Look at removing old board_status entries from the active branch. Start tagging board_status when releases are done. * We need to do more work to promote information about the board_status repository and how to test with the board_status script. Many people don't seem to be aware of this or how to add boards. * What is the preferred platform for 64-bit arm? - Discuss on the mailing list? - Samsung chromebook-plus may be the best board right now. - Might be interesting: https://cre-8.cmnty.com/blog/article/10/CRE-8-i.MX-8-Single-Board-Computer-… i.MX 6 was popular for many free hardware projects (Novena, IIRC etc.). Compared to all other ARM SoC vendors, NXP published documentation in the past, I hope they will keep doing so. * What is the current best effort on mitigating the risks related to the Management Engine and how coreboot is positioned relating this issue ? - ME Cleaner ( https://github.com/corna/me_cleaner ) may be the best solution * Cleaned ME takes a long time to start booting before jumping to the reset vector. Haswell & Broadwell are tested and show this issue. This doesn't show up in timestamps because it happens before coreboot starts. Conferences * Sign up - Denver conference is in under a month - https://coreboot.org/Denver2017 * System76 volunteered to host a mixer on Monday night. * ECC 2017 got secunet and bochumer wirtschaftsförderung as sponsors Infrastructure News * The main coreboot server got an OS upgrade on Saturday. * The main coreboot server rebooted yesterday (May 10), due to power issues in the facility. Not all of the services come back up correctly, leading to some downtime for various services. They expect to have downtime again tonight (May 11) to replace a failed load-break switch. https://twitter.com/sixtopia/status/862435443647950848/photo/1 * The jenkins upgrade went smoothly on Sunday - these are planned to happen on the first weekend of each month going forward. Development * Is anybody using baud_rate or debug_level CMOS options? They are a PITA to maintain... want to remove them. The options are used in console init which is done in multiple stages with ROMCC and GCC. Not build tested, breaks everytime somebody touches console init (at least feels like that). - We need to start build testing options like this. Anyone can add to the tested configurations by simply enabling the options you want tested and adding a mini-config file to the configs directory. To create the miniconfig, run 'make savedefconfig'. The output is in the file 'defconfig' by default. - It was pointed out that having these values in CMOS is useful on server boards with a BMC that can access CMOS to change the debug level. - On some boards no 'sane' default is provided which often ends up at silly baud rates like 9600 when cmos is cleared. - We should definitely look at adding defaults to all boards that are using CMOS. Looking for a volunteer to take care of this. Out of 182 boards with a cmos.layout file, only 39 have cmos.default files. - Would it help to migrate to using ROM as the backing store for some variables (likely involving fmap)? (not in this case) Interesting external News * Intel ME exploit ( https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00075 ; https://www.tenable.com/blog/rediscovering-the-intel-amt-vulnerability ) - Looking for someone to give a talk at one of the coreboot conferences about this. * SciFive announced 64-bit riscv core. ################################################################## Next meeting is Thursday, May 25, 2017 Check the coreboot calendar for the time in your timezone https://www.coreboot.org/calendar.html Join using the bluejeans web app or the phone bridge: https://bluejeans.com/616384323 Phone bridge call in numbers: https://www.bluejeans.com/numbers Meeting ID: 616384323 Current agenda & history: https://coreboot-meeting.pads.ccc.de/CommunityMeetingTopics

1 0

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

11 May '17

On 11.05.2017 22:43, Joshua Pincus 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. Generally, I'd check what Linux does. Since it's open source, it's much easier to spot the difference between running natively and running as a guest. If it doesn't work in a Linux guest you can try to find the first thing that goes wrong in the i915 driver (booting with drm.debug=0x6 could already give some hints in the kernel log). > > > > 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. Probably something in the VBT (Video BIOS Table). It's a configuration structure for Intel video drivers used to pass information from the firmware to the OS. In your case the hypervisor might have to pass the VBT (or not hide the original). Just a guess. Hope that helps, Nico

2 1

Re: [coreboot] : AMT bug
by Trammell Hudson 11 May '17

11 May '17

On Thu, May 11, 2017 at 10:30:48AM -0500, Allen Krell wrote: > [...] There are multiple keys > > ME - public/private key pair - Fused in by Intel and checked by Intel > silicon - Probably different across models > > BIOS_ACM - public/private key pair - Fused in by Intel and checked by Intel > silicon. May be common across all 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. That is my best guess as well. The key hierarchy is the ME, the ACM and then the bootguard key: If an attacker can sign an ME binary, they can provide invalid fuses to the CPU microcode so that it won't check the ACM key (or provide their own bootguard key so that the TPM locality will be set for the IBB measurement). If the attacker can sign the ACM, they can ignore the bootguard key on the IBB and provide invalid measurements to the CRTM. And if they can sign an IBB they can implement their own policy (but not avoid TPM measurement of the IBB by the ACM). > 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. That might be possible, although ideally the startup ACM or IBB can ensure that the ME region is included in its measurements and this would cause key unsealing or remote attestation to fail. That's one of the reasons that I recommend changing the flash descriptor to allow the host CPU to read the ME region. -- Trammell

3 3

Help with i915
by Joshua Pincus 11 May '17

11 May '17

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

1 0

Re: [coreboot] coreboot Digest, Vol 147, Issue 17
by Igor Skochinsky 11 May '17

11 May '17

Hi Allen, Thursday, May 11, 2017, 2:01:47 PM, you wrote: AK> One thing I am still confused about is the relationship between AK> Intel Boot Guard and the regions of flash. My understanding is AK> that Boot Guard only applies to the legacy BIOS region of flash, AK> not the ME/AMT region. Is that correct? So, if that is true, AK> then is it possible to flash the ME/AMT region of flash with any AK> ME code module that has been signed with the Intel signature? Well, in theory BootGuard indeed only protects the BIOS boot block (ME has its own protection via Intel-signed manifest), so changing ME region should not affect it but apparently in practice it does lead to problems at least on *some* platforms using BootGuard: https://github.com/corna/me_cleaner/issues/6 -- WBR, Igor mailto:roxfan@skynet.be

1 0

Re: [coreboot] AMT bug
by Taiidan＠gmx.com 11 May '17

11 May '17

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) > > I was involved in some USG issues around the time of Y2K and at least one > agency shredded every non-Y2K-compliant system they had. Would that make > sense for systems with this AMT vulnerability? Just assume the worst and > destroy them? I guess you can always re-flash externally, I don't think even a nation state has figured out the magic to get a regular flash EEPROM to stealth-deny writes (have they? :0) > > I am long past believing one can build secure platforms on any x86 chipset. > This mess only strengthens that conviction. But there are some great RISC-V > announcements this week! What about pre-PSP AMD? as 95% of the way there - with POWER as 100% if you get a fully open source, blob free machine like the palmetto or with a little work the firestone.

3 3

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