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
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
>
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 ??
ᐧ
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
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
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
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
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
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
