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);
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 it feels a bit like "works by accident".
Am I missing something?
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