coreboot April 2016

coreboot@coreboot.org

49 participants
97 discussions

Re: [coreboot] coreboot specific ACPI table
by Aaron Durbin 19 Apr '16

19 Apr '16

On Mon, Apr 18, 2016 at 8:18 PM, ron minnich <rminnich(a)gmail.com> wrote: > So we would submit new ACPI table types to the standards guys? Could we get > names like > CORE > BOOT > CBFS We just need one table, and we can put whatever we want into it. It's the equivalent of an HPET table, e.g. > > ? > > ron > > On Mon, Apr 18, 2016 at 10:15 AM Patrick Georgi via coreboot > <coreboot(a)coreboot.org> wrote: >> >> 2016-04-18 19:09 GMT+02:00 Vadim Bendebury <vbendeb(a)chromium.org>: >> > It's been a while since I looked at it, but why not to pass all >> > information through the coreboot table? (so that just one pointer >> > needs to be shared through ACPI). >> One reason for registering these things in ACPI is so that Linux >> exports them properly via sysfs. /dev/mem is mostly non-functional in >> newer kernel versions. >> >> >> Patrick >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://www.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] coreboot specific ACPI table
by ron minnich 19 Apr '16

19 Apr '16

So we would submit new ACPI table types to the standards guys? Could we get names like CORE BOOT CBFS ? ron On Mon, Apr 18, 2016 at 10:15 AM Patrick Georgi via coreboot < coreboot(a)coreboot.org> wrote: > 2016-04-18 19:09 GMT+02:00 Vadim Bendebury <vbendeb(a)chromium.org>: > > It's been a while since I looked at it, but why not to pass all > > information through the coreboot table? (so that just one pointer > > needs to be shared through ACPI). > One reason for registering these things in ACPI is so that Linux > exports them properly via sysfs. /dev/mem is mostly non-functional in > newer kernel versions. > > > Patrick > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Coreboot on ARM
by daoud yessine 19 Apr '16

19 Apr '16

hi Is coreboot a replacement of x-oader (MLO) on arm systems ? So coreboot will be placed in the boot partition on the SD/card (e.g ) and it will be named MLO to be called by the rom code ?? ᐧ

1 0

F2A85-M: A10-6800k (Richland) supported?
by Daniel Kulesz 18 Apr '16

18 Apr '16

Hi, is or was someone able to run the A10-6800k on the F2A85-M successfully? If yes, are any extra patches required? Cheers, Daniel

1 0

Re: [coreboot] Flash ROM locking on S3 resume
by Carl-Daniel Hailfinger 18 Apr '16

18 Apr '16

On 18.04.2016 19:02, David Hendricks wrote: > On Mon, Apr 18, 2016 at 8:48 AM, Trammell Hudson <hudson(a)trmm.net> wrote: > >> I'm curious why this is an option, especially since it seems almost tailor >> made to re-create the Snorlax or Prince Harming vulnerabilities >> (VU#577140): >> >> Flash ROM locking on S3 resume >>> 1. Don't lock ROM sections on S3 resume (LOCK_SPI_ON_RESUME_NONE) (NEW) >> 2. Lock all flash ROM sections on S3 resume (LOCK_SPI_ON_RESUME_RO) (NEW) >> 3. Lock and disable reads all flash ROM sections on S3 resume >> (LOCK_SPI_ON_RESUME_NO_ACCESS) (NEW) >> > > Maybe the default just needs to be changed to LOCK_SPI_ON_RESUME_RO? > > LOCK_SPI_ON_RESUME_NONE is probably intended for developers who need to > re-flash their systems a lot and might not want to rely on external > programmers (especially for laptop development). >From a defense in depth perspective, LOCK_SPI_ON_RESUME_NO_ACCESS is more dangerous than LOCK_SPI_ON_RESUME_NONE. The former provides for perfect stealth from in-system monitoring, the latter at least gives in-system code a chance to perform a self-check even if a self-check of a compromised system is very hard to do correctly and sometimes not possible at all. That said, I do see value in LOCK_SPI_ON_RESUME_NONE because it enables use cases like automated coreboot test systems. Speaking with my flashrom hat on, if you want to use it to write to the main system flash, you have to make sure any written region is not marked readonly. Changing the default setting to LOCK_SPI_ON_RESUME_RO may be a good choice for quite a few use cases. Regards, Carl-Daniel

1 0

Re: [coreboot] coreboot specific ACPI table
by Patrick Georgi 18 Apr '16

18 Apr '16

2016-04-18 19:09 GMT+02:00 Vadim Bendebury <vbendeb(a)chromium.org>: > It's been a while since I looked at it, but why not to pass all > information through the coreboot table? (so that just one pointer > needs to be shared through ACPI). One reason for registering these things in ACPI is so that Linux exports them properly via sysfs. /dev/mem is mostly non-functional in newer kernel versions. Patrick

1 0

Re: [coreboot] coreboot specific ACPI table
by Aaron Durbin 18 Apr '16

18 Apr '16

On Mon, Apr 18, 2016 at 12:09 PM, Vadim Bendebury <vbendeb(a)chromium.org> wrote: > It's been a while since I looked at it, but why not to pass all > information through the coreboot table? (so that just one pointer > needs to be shared through ACPI). All information is already in the coreboot table as noted originally. You could just keep bounds in the ACPI table and subsequently parse the entries. That's the base case of "walked to identify those specific entries". > > --vb > > On Mon, Apr 18, 2016 at 8:45 AM, Aaron Durbin via coreboot > <coreboot(a)coreboot.org> wrote: >> Hi Folks, >> >> There was a CL going around internal to chromium >> (https://chromium-review.googlesource.com/#/c/339121) to expose the >> coreboot table address proper through ACPI. However, it was put in the >> GNVS of a few SoCs. There are different mechanisms for firmware >> console and ramoops (pstore for kernel dmesg storage to catch >> failures), but the kernel could probably use a generic coreboot driver >> which could utilize the coreboot tables proper. There's already >> semi-similar mechanisms (./drivers/firmware/google/coreboot_table.c in >> linux). It needs to handle both device tree and should handle ACPI, >> but it currently only handles device tree. >> >> Where things really get messy is that for memconsole (exporting >> firmware logs through sysfs) has both an x86 variant and a devicetree >> one. The x86 variant has a cbmem parser when it should be relying >> coreboot tables proper as that's the ABI. There's also a path for >> discovering the console by evaluating the \\CBMC object. The patch >> referenced above takes a similar route. As noted above there is a >> ramoops ACPI device that has been utilized for discovering the pstore >> buffer to use which is different than just a named ACPI object. >> >> All that said, I feel like we likely want to define a ACPI table which >> has the coreboot specific data we care about: >> 1. coreboot tables base address and size. >> 2. console base address and size. >> 3. ramoops info. >> >> The coreboot tables currently contain all the cbmem entries as well. >> So if something is not explicitly in the ACPI table proper the >> coreboot tables could be walked to identify those specific entries. >> >> Thoughts? I'm not sure what the ramifications are of making a coreboot >> ACPI table proper. On the surface it feels very much doable, but I >> might be missing some details where things break down. >> >> -Aaron >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://www.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] coreboot specific ACPI table
by Vadim Bendebury 18 Apr '16

18 Apr '16

It's been a while since I looked at it, but why not to pass all information through the coreboot table? (so that just one pointer needs to be shared through ACPI). --vb On Mon, Apr 18, 2016 at 8:45 AM, Aaron Durbin via coreboot <coreboot(a)coreboot.org> wrote: > Hi Folks, > > There was a CL going around internal to chromium > (https://chromium-review.googlesource.com/#/c/339121) to expose the > coreboot table address proper through ACPI. However, it was put in the > GNVS of a few SoCs. There are different mechanisms for firmware > console and ramoops (pstore for kernel dmesg storage to catch > failures), but the kernel could probably use a generic coreboot driver > which could utilize the coreboot tables proper. There's already > semi-similar mechanisms (./drivers/firmware/google/coreboot_table.c in > linux). It needs to handle both device tree and should handle ACPI, > but it currently only handles device tree. > > Where things really get messy is that for memconsole (exporting > firmware logs through sysfs) has both an x86 variant and a devicetree > one. The x86 variant has a cbmem parser when it should be relying > coreboot tables proper as that's the ABI. There's also a path for > discovering the console by evaluating the \\CBMC object. The patch > referenced above takes a similar route. As noted above there is a > ramoops ACPI device that has been utilized for discovering the pstore > buffer to use which is different than just a named ACPI object. > > All that said, I feel like we likely want to define a ACPI table which > has the coreboot specific data we care about: > 1. coreboot tables base address and size. > 2. console base address and size. > 3. ramoops info. > > The coreboot tables currently contain all the cbmem entries as well. > So if something is not explicitly in the ACPI table proper the > coreboot tables could be walked to identify those specific entries. > > Thoughts? I'm not sure what the ramifications are of making a coreboot > ACPI table proper. On the surface it feels very much doable, but I > might be missing some details where things break down. > > -Aaron > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot

1 0

Flash ROM locking on S3 resume
by Trammell Hudson 18 Apr '16

18 Apr '16

I'm curious why this is an option, especially since it seems almost tailor made to re-create the Snorlax or Prince Harming vulnerabilities (VU#577140): Flash ROM locking on S3 resume > 1. Don't lock ROM sections on S3 resume (LOCK_SPI_ON_RESUME_NONE) (NEW) 2. Lock all flash ROM sections on S3 resume (LOCK_SPI_ON_RESUME_RO) (NEW) 3. Lock and disable reads all flash ROM sections on S3 resume (LOCK_SPI_ON_RESUME_NO_ACCESS) (NEW) -- Trammell

2 1

coreboot specific ACPI table
by Aaron Durbin 18 Apr '16

18 Apr '16

Hi Folks, There was a CL going around internal to chromium (https://chromium-review.googlesource.com/#/c/339121) to expose the coreboot table address proper through ACPI. However, it was put in the GNVS of a few SoCs. There are different mechanisms for firmware console and ramoops (pstore for kernel dmesg storage to catch failures), but the kernel could probably use a generic coreboot driver which could utilize the coreboot tables proper. There's already semi-similar mechanisms (./drivers/firmware/google/coreboot_table.c in linux). It needs to handle both device tree and should handle ACPI, but it currently only handles device tree. Where things really get messy is that for memconsole (exporting firmware logs through sysfs) has both an x86 variant and a devicetree one. The x86 variant has a cbmem parser when it should be relying coreboot tables proper as that's the ABI. There's also a path for discovering the console by evaluating the \\CBMC object. The patch referenced above takes a similar route. As noted above there is a ramoops ACPI device that has been utilized for discovering the pstore buffer to use which is different than just a named ACPI object. All that said, I feel like we likely want to define a ACPI table which has the coreboot specific data we care about: 1. coreboot tables base address and size. 2. console base address and size. 3. ramoops info. The coreboot tables currently contain all the cbmem entries as well. So if something is not explicitly in the ACPI table proper the coreboot tables could be walked to identify those specific entries. Thoughts? I'm not sure what the ramifications are of making a coreboot ACPI table proper. On the surface it feels very much doable, but I might be missing some details where things break down. -Aaron

1 0

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot April 2016