coreboot November 2018

coreboot@coreboot.org

71 participants
149 discussions

HEADS UP: Gerrit now uses the MAINTAINERS file to determine reviewers for new uploads
by Patrick Georgi 21 Nov '18

21 Nov '18

Hi everybody, Gerrit will now automatically add reviewers to changes based on the MAINTAINERS file we have in the repository. If there's a part of the tree that you're particularly interested in, consider adding yourself as maintainer (M:) or reviewer (R:) in MAINTAINERS for that particular area. If you get lots of review requests and you don't know why, it might be because of this. Maybe there's an entry in MAINTAINERS that's broader than you thought? Feel free to remove yourself in that case. Regards, Patrick -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

1 0

uefi_nvs.bin in coreboot
by galla rao 21 Nov '18

21 Nov '18

Hi All, am trying to save NVRAM variables which are modifed in Uefi Payload, but i could not save it. what is the role of uefi_nvs.bin file? coreboot/intel/mainboard/intel/bayleybay_fsp/uefi_nvs.bin Even the boot order does not save into NVRAM variables Can some one help me on this, Base address is given below gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase | 0xFFF60000 gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase | 0xFFF7E000 gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase | 0xFFF80000 In coreboot, i have given the same address [image: image.png] Thanks & Regards Ranga

1 0

Re: [coreboot] uefi rootkit (lojax)
by ron minnich 20 Nov '18

20 Nov '18

On Tue, Nov 20, 2018 at 8:31 AM Ivan Ivanov <qmastery16(a)gmail.com> wrote: > It is nice to hear there are possible alternatives ; to be honest I > don't know about their "marketshare" amoung the coreboot users. From > my point of view as a user (reading mailing lists etc.) it seemed like > the majority of coreboot users are using SeaBIOS and the majority of > libreboot users are using GRUB. The majority of coreboot users are using chromeos verified boot :-) > P.S. sorry it seems I bumped an old thread and now I feel guilty not a problem! ron

1 0

Re: [coreboot] uefi rootkit (lojax)
by Ivan Ivanov 20 Nov '18

20 Nov '18

> that's a pretty myopic view of coreboot and its users; coreboot > supports 2 different UEFI payloads, which are used by both individual > and commercial entities. It is nice to hear there are possible alternatives ; to be honest I don't know about their "marketshare" amoung the coreboot users. From my point of view as a user (reading mailing lists etc.) it seemed like the majority of coreboot users are using SeaBIOS and the majority of libreboot users are using GRUB. Although, its' quite likely that at the same time the majority of ChromeBook+coreboot users are really running UEFI payload, thanks to your customized coreboot builds where you are using it (learned about your work after a quick search) P.S. sorry it seems I bumped an old thread and now I feel guilty Ivan вт, 20 нояб. 2018 г. в 18:07, Matt DeVillier <matt.devillier(a)gmail.com>: > > On Tue, Nov 20, 2018 at 8:20 AM Ivan Ivanov <qmastery16(a)gmail.com> wrote: > > > > Thank you for the info! However we are not affected thanks to > > coreboot's default payload being SeaBIOS. If anything, these "uefi > > rootkit" news could be used to promote the coreboot(+SeaBIOS) project > > to wider audiences > > that's a pretty myopic view of coreboot and its users; coreboot > supports 2 different UEFI payloads, which are used by both individual > and commercial entities. > > > > > Ivan > > > > > > > > hi all! :) > > > > > > ive just found this, and thought that it can be valuable info for the > > > people around: > > > > > > https://www.welivesecurity.com/2018/09/27/lojax-first-uefi-rootkit-found-wi… > > > > > > (i hope it wont disturb anyone here, as its near to be offtopic) > > > > > > all the bests for all of you! :) > > > > > > -- > > > coreboot mailing list: coreboot(a)coreboot.org > > > https://mail.coreboot.org/mailman/listinfo/coreboot > > > > -- > > coreboot mailing list: coreboot(a)coreboot.org > > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] uefi rootkit (lojax)
by Matt DeVillier 20 Nov '18

20 Nov '18

On Tue, Nov 20, 2018 at 8:20 AM Ivan Ivanov <qmastery16(a)gmail.com> wrote: > > Thank you for the info! However we are not affected thanks to > coreboot's default payload being SeaBIOS. If anything, these "uefi > rootkit" news could be used to promote the coreboot(+SeaBIOS) project > to wider audiences that's a pretty myopic view of coreboot and its users; coreboot supports 2 different UEFI payloads, which are used by both individual and commercial entities. > > Ivan > > > > > hi all! :) > > > > ive just found this, and thought that it can be valuable info for the > > people around: > > > > https://www.welivesecurity.com/2018/09/27/lojax-first-uefi-rootkit-found-wi… > > > > (i hope it wont disturb anyone here, as its near to be offtopic) > > > > all the bests for all of you! :) > > > > -- > > coreboot mailing list: coreboot(a)coreboot.org > > https://mail.coreboot.org/mailman/listinfo/coreboot > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] uefi rootkit (lojax)
by Ivan Ivanov 20 Nov '18

20 Nov '18

Thank you for the info! However we are not affected thanks to coreboot's default payload being SeaBIOS. If anything, these "uefi rootkit" news could be used to promote the coreboot(+SeaBIOS) project to wider audiences Ivan > > hi all! :) > > ive just found this, and thought that it can be valuable info for the > people around: > > https://www.welivesecurity.com/2018/09/27/lojax-first-uefi-rootkit-found-wi… > > (i hope it wont disturb anyone here, as its near to be offtopic) > > all the bests for all of you! :) > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] Kabylake H: SPI Transaction Error at Flash Offset d10000
by Zaolin 19 Nov '18

19 Nov '18

Hey folks, I guess this is an integration option. IMHO Chipset lockdown should be a kconfig option and not be defined as part of the device tree. Maybe we should do a follow up and fix this issue. BTW same goes for SPI flash protection which should be interfaced globally, platform independent. BR, Zaolin On 19.11.18 13:04, Jose Trujillo via coreboot wrote: > Thank you Christian, > > Works in my system too, Kabilake FSP2 issue? > The only small drawback is the disabled ability to upgrade coreboot from itself which correct me if I am wrong is great in terms of security. > Do you know if there is still the possibility to enable HECI to flash SPI in SMM mode even in CHIPSET_LOCKDOWN? > But now this system boots fast. > I owe you one bro. > > Jose Trujillo > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Monday, November 19, 2018 1:15 PM, Christian Gmeiner <christian.gmeiner(a)gmail.com> wrote: > >> Hi >> >> Am Fr., 16. Nov. 2018 um 15:57 Uhr schrieb Jose Trujillo via coreboot >> coreboot(a)coreboot.org: >> >>> Hello coreboot engineers: >>> My Kabylake H system "HM175" with coreboot "bsl6" and "kblrvp" platforms with properly configured I/O failed to save Memory training data to the SPI cache 'RW_MRC_CACHE'. >>> FMAP: Found "FLASH" version 1.1 at d00000. >>> FMAP: base = ff000000 size = 1000000 #areas = 4 >>> FMAP: area RW_MRC_CACHE found @ d10000 (65536 bytes) >>> MRC: Checking cached data update for 'RW_MRC_CACHE'. >>> SF: Detected FAST_SPI Hardware Sequencer with sector size 0x1000, total 0x100000 >>> MRC: no data in 'RW_MRC_CACHE' >>> MRC: cache data 'RW_MRC_CACHE' needs update. >>> SPI Transaction Error at Flash Offset d10000 HSFSTS = 0x01046003 >>> REGF metadata allocation failed: 392 data blocks 4096 total blocks >>> MRC: Could not find region 'UNIFIED_MRC_CACHE' >>> FMAP: area RW_MRC_CACHE found @ d10000 (65536 bytes) >>> MRC: NOT enabling PRR for 'RW_MRC_CACHE' >>> As a consequence fast boot never works. (fast boot works correctly on my coffeelake system). >>> Nico helped me to test the system ability to save data to the MRC_CACHE block from linux booting coreboot and I wrote random data to the 'RW_MRC_CACHE' block with the "flashrom" tool succesfully. >>> Maybe someone that had experience with this issue or have some idea how to fix it can give me advise on how to resolve this problem. >> I run into the same problem:https://review.coreboot.org/c/coreboot/+/29159 >> >> Make sure you have this block in your devicetree.cb >> >> # Lock Down >> register "common_soc_config" = "{ >> .chipset_lockdown = CHIPSET_LOCKDOWN_COREBOOT, >> }" >> >> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >> >> greets >> >> ------- >> >> Christian Gmeiner, MSc >> >> https://christian-gmeiner.info > >

2 1

Configuration for Apollo Lake FSP (Github/MR5)
by Nico Huber 19 Nov '18

19 Nov '18

Hi, has anyone made good or bad experience with the Apollo Lake FSP currently on Github (it's the MR5, afaict)? FSP-M never returns for me and I have no post-code display :-/ I tried both XIP and loading into CAR, same result. Maybe it's still something wrong with my configuration. If anybody had suc- cess with this binary, please share your `.config`. My FSP-M UPDs could be wrong as well. But can that result in a hanging FSP? Do we have to expect undefined behaviour because of bad memory parameters? Nico

1 1

Re: [coreboot] Kabylake H: SPI Transaction Error at Flash Offset d10000
by Jose Trujillo 19 Nov '18

19 Nov '18

Thank you Christian, Works in my system too, Kabilake FSP2 issue? The only small drawback is the disabled ability to upgrade coreboot from itself which correct me if I am wrong is great in terms of security. Do you know if there is still the possibility to enable HECI to flash SPI in SMM mode even in CHIPSET_LOCKDOWN? But now this system boots fast. I owe you one bro. Jose Trujillo ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Monday, November 19, 2018 1:15 PM, Christian Gmeiner <christian.gmeiner(a)gmail.com> wrote: > Hi > > Am Fr., 16. Nov. 2018 um 15:57 Uhr schrieb Jose Trujillo via coreboot > coreboot(a)coreboot.org: > > > Hello coreboot engineers: > > My Kabylake H system "HM175" with coreboot "bsl6" and "kblrvp" platforms with properly configured I/O failed to save Memory training data to the SPI cache 'RW_MRC_CACHE'. > > FMAP: Found "FLASH" version 1.1 at d00000. > > FMAP: base = ff000000 size = 1000000 #areas = 4 > > FMAP: area RW_MRC_CACHE found @ d10000 (65536 bytes) > > MRC: Checking cached data update for 'RW_MRC_CACHE'. > > SF: Detected FAST_SPI Hardware Sequencer with sector size 0x1000, total 0x100000 > > MRC: no data in 'RW_MRC_CACHE' > > MRC: cache data 'RW_MRC_CACHE' needs update. > > SPI Transaction Error at Flash Offset d10000 HSFSTS = 0x01046003 > > REGF metadata allocation failed: 392 data blocks 4096 total blocks > > MRC: Could not find region 'UNIFIED_MRC_CACHE' > > FMAP: area RW_MRC_CACHE found @ d10000 (65536 bytes) > > MRC: NOT enabling PRR for 'RW_MRC_CACHE' > > As a consequence fast boot never works. (fast boot works correctly on my coffeelake system). > > Nico helped me to test the system ability to save data to the MRC_CACHE block from linux booting coreboot and I wrote random data to the 'RW_MRC_CACHE' block with the "flashrom" tool succesfully. > > Maybe someone that had experience with this issue or have some idea how to fix it can give me advise on how to resolve this problem. > > I run into the same problem:https://review.coreboot.org/c/coreboot/+/29159 > > Make sure you have this block in your devicetree.cb > > # Lock Down > register "common_soc_config" = "{ > .chipset_lockdown = CHIPSET_LOCKDOWN_COREBOOT, > }" > > ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > greets > > ------- > > Christian Gmeiner, MSc > > https://christian-gmeiner.info

1 0

Re: [coreboot] Kabylake H: SPI Transaction Error at Flash Offset d10000
by Christian Gmeiner 19 Nov '18

19 Nov '18

Hi Am Fr., 16. Nov. 2018 um 15:57 Uhr schrieb Jose Trujillo via coreboot <coreboot(a)coreboot.org>: > > Hello coreboot engineers: > > My Kabylake H system "HM175" with coreboot "bsl6" and "kblrvp" platforms with properly configured I/O failed to save Memory training data to the SPI cache 'RW_MRC_CACHE'. > > FMAP: Found "FLASH" version 1.1 at d00000. > FMAP: base = ff000000 size = 1000000 #areas = 4 > FMAP: area RW_MRC_CACHE found @ d10000 (65536 bytes) > MRC: Checking cached data update for 'RW_MRC_CACHE'. > SF: Detected FAST_SPI Hardware Sequencer with sector size 0x1000, total 0x100000 > MRC: no data in 'RW_MRC_CACHE' > MRC: cache data 'RW_MRC_CACHE' needs update. > SPI Transaction Error at Flash Offset d10000 HSFSTS = 0x01046003 > REGF metadata allocation failed: 392 data blocks 4096 total blocks > MRC: Could not find region 'UNIFIED_MRC_CACHE' > FMAP: area RW_MRC_CACHE found @ d10000 (65536 bytes) > MRC: NOT enabling PRR for 'RW_MRC_CACHE' > > As a consequence fast boot never works. (fast boot works correctly on my coffeelake system). > > Nico helped me to test the system ability to save data to the MRC_CACHE block from linux booting coreboot and I wrote random data to the 'RW_MRC_CACHE' block with the "flashrom" tool succesfully. > > Maybe someone that had experience with this issue or have some idea how to fix it can give me advise on how to resolve this problem. > I run into the same problem: https://review.coreboot.org/c/coreboot/+/29159 Make sure you have this block in your devicetree.cb # Lock Down register "common_soc_config" = "{ .chipset_lockdown = CHIPSET_LOCKDOWN_COREBOOT, }" -- greets -- Christian Gmeiner, MSc https://christian-gmeiner.info

1 0

← Newer
1
2
3
4
5
6
7
8
9
...
15
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 November 2018