Skip to content

Comments

head.S: move skl_info and bootloader_data fields back#25

Open
m-iwanicki wants to merge 1 commit intoskl-loader-amdsl-noblobfrom
skl-loader-amdsl-noblob-sl_header-fix
Open

head.S: move skl_info and bootloader_data fields back#25
m-iwanicki wants to merge 1 commit intoskl-loader-amdsl-noblobfrom
skl-loader-amdsl-noblob-sl_header-fix

Conversation

@m-iwanicki
Copy link

Fixes issue:

loader/slaunch/skl.c:117:slaunch: Possible SKL module measures bootloader data:
16424 (measured prefix) > 170 (data offset)
error: SKL module isn't correct.

Tested with tb-dev GRUB (meta-trenchboot)

Fixes issue:

```
loader/slaunch/skl.c:117:slaunch: Possible SKL module measures bootloader data:
16424 (measured prefix) > 170 (data offset)
error: SKL module isn't correct.
```

Signed-off-by: Michał Iwanicki <michal.iwanicki@3mdeb.com>
@krystian-hebel
Copy link
Member

I think this should be changed on GRUB side instead. The size of soc_flag field is out of our control, and may change without notice. By having skl_info and bootloader_data under known offsets, GRUB won't have to be aware of any changes made by AMD.

@SergiiDmytruk
Copy link
Member

I agree that updating this in GRUB a better place in the long run. Can use this modification for testing though since commits are WIP anyway and it should be easier than bumping GRUB.

@krystian-hebel
Copy link
Member

By the way, it may be useful to try to change those (presumed) CPUIDs to match the CPU used for testing. I didn't find any documentation as to what those are used by, it may be possible that PSP validates those somehow, but maybe they were meant for whatever loads the binary (GRUB in our case).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants