OS-level access to CBMEM

[krystian-hebel]

The problem you're addressing (if any)
After fixing memory reservation in the device tree generation code, CBMEM is no longer accessible from operating system. Previously it was marked as usable, non-reserved RAM and could be read as long as nothing overwrote it.

Describe the solution you'd like
It is mainly required by cbmem util from coreboot. This utility should be able to access CBMEM region either by mmaping it directly or by accessing some file exposed by kernel.

Where is the value to a user, and who might that user be?
CBMEM holds various pieces of information about firmware, like console log or timestamps.

Describe alternatives you've considered

• it may be possible to mark this range as “reserved but mmapable” memory in device tree (note that skiboot, skiroot and final OS' kernel may modify it)
• Creating new kernel driver
• Enabling Google’s driver for other platforms, additional changes may be required

[sulewskiprzemyslaw]

@SergiiDmytruk I see, that CBMEM currently works on the platform flashed with v0.6.0 binary. I have one question: if the coreboot timestamps should be available?

When I execute the following command:

./git/coreboot/util/cbmem/cbmem -T

In the output I see:
No timestamps found in coreboot table

[SergiiDmytruk]

@sulewskiprzemyslaw No, timestamps aren't enabled. .config has this line:

# CONFIG_COLLECT_TIMESTAMPS is not set

[sulewskiprzemyslaw]

@SergiiDmytruk ok, thank you for the information.

[tlaurion]

CONFIG_COLLECT_TIMESTAMPS=y

Should be set otherwise speed comparison will not be possible.

[miczyg1]

Definition from Kconfig:

config COLLECT_TIMESTAMPS
	bool "Create a table of timestamps collected during boot"
	default y if ARCH_X86

So all x86 boards will have it. Is there a reason why POWER would not want to select it?

[krystian-hebel]

I don't know if QEMU would support timer in current state, this would need testing. Other than that, we can enable it.

[miczyg1]

We can either make it read-write and not reserve it or reserve it and do not let any access. Possible ideas

1. Adding some entry in DT
2. Modifying skiboot

[SergiiDmytruk]

Dasharo/coreboot#197 was fixing this (although not in .../develop), but it's still open.

[tlaurion]

I think a different approach was taken since then? Confused but I think its now correctly exposed in read only now

[SergiiDmytruk]

The commit that excludes cbmem from available memory is there, so it basically works the same. Endianness and DT stuff is done differently, but looks like the kernel can now see TPM log which used to cause issues.

[krystian-hebel]

Dasharo/coreboot#197 was fixing this (although not in .../develop), but it's still open.

@SergiiDmytruk you are correct. For some reason I think I saw it just added entries to FDT "memreserve" fields instead of creating DT "/reserved-memory/coreboot@%llx" nodes, in which case Skiboot wouldn't mark it as reserved and OS would be allowed to overwrite it. Maybe it was on develop 🤔

[SergiiDmytruk]

but looks like the kernel can now see TPM log which used to cause issues.

Nope, the necessary changes seem to be there, some commits just got squashed.

[miczyg1]

Awaiting for the automated tests to be ready to close the issue

[BeataZdunczyk]

This issue is fixed with linuxboot/heads#1313 and is part of the 0.7.0 release, which was published here: https://docs.dasharo.com/variants/talos_2/releases/#v070-2023-07-26