[coreboot] Re: Placing coreboot in system memory

[Nico Huber]

Am 10.11.21 um 10:43 schrieb Nico Huber:

Hi Julian,

Am 10.11.21 um 10:02 schrieb Julian Stecklina:

CBFS: Found 'fallback/romstage' @0x80 size 0x3ba0 in mcache @0x00014e2c
WARN - MOVS to ROM at RIP ffffdc2f RCX ee8 ff200300->ff200300

The warning is from us. Improvising a stack trace at this point yields:

cbfs_prog_stage_load -> cbfs_load_and_decompress.isra.5 -> rdev_readat ->
mdev_readat -> mdev -> memcpy

In cbfs_prog_stage_load, I can see this code:


    size_t fsize = cbfs_load_and_decompress(&rdev, prog_start(pstage),
prog_size(pstage),
                        compression, file_hash);


it feels a bit like "works by accident".

Am I missing something?

And here prog_start() definitely returns the pointer 0xff20_0300, which points into ROM. Passing a pointer to ROM as a writable pointer feels wrong. Given that the code just does memcpy with src=dst in this buffer, this all is harmless, but

no, I think you are not. It really seems odd. In `src/lib/cbfs.c:553`
there is a comment:

/* Hacky way to not load programs over read only media. The stages
  * that would hit this path initialize themselves. */

AIUI, this "hacky way" should be taken, so cbfs_load_and_decompress()
would never be called. First, I'd check if the path is tried, i.e.
check the .config file if these are set to `y`:

* CONFIG_NO_XIP_EARLY_STAGES

Sorry, this one is inverted in the condition, it should be set to no /
unset, of course.

Nico

* CONFIG_BOOT_DEVICE_MEMORY_MAPPED

If they are, it's still possible that something fails and it falls back
to cbfs_load_and_decompress(). In that case, further debugging might be
needed.

Cheers,
Nico

OpenPGP_0xBD56B4A4138B3CE3.asc
Description: OpenPGP public key

OpenPGP_signature
Description: OpenPGP digital signature

_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org