kernel/cpu: add safety comments #584
Conversation
Both of these GHCB operations can cause physical memory to be remapped (one may cause the GHCB data to appear in a different place, and one may cause memory to be remapped with a different encryption attribute). Because both of these operations can cause mapped memory to change contents, they are technically unsafe. |
Thanks for your input on this Jon, and sorry for the massively delayed update. I entered a busy relocation mode and will start working on this again in a couple of weeks hopefully. |
stac and clac instructions don't break memory safety. Signed-off-by: Thomas Leroy <[email protected]>
p4zuu
force-pushed
the
cpu_unsafe
branch
2 times, most recently
from
fae85db to
fdcc08d
Compare
|
Thanks for the initial review @msft-jlange. I addressed the comments and this is open again for review |
Writing to some MSRs can break memory safety. Therefore, write_msr() should be unsafe. Signed-off-by: Thomas Leroy <[email protected]>
Missing safety comments were missing in GDT code. Adding a couple of checks to validate the safety requirements. Also, to ensure we call `ltr` instruction with a tss that has a valid lifetime, we can set `load_tss()` to take a static tss reference. Signed-off-by: Thomas Leroy <[email protected]>
msft-jlange
added
ready-to-merge
Safety comments for:
stacandclacinstructionswrite_msr()should be unsafe since it can break memory safety. This part is still missing two comments here and here in the GHCB MSR protocol where I have doubt if the MSR request is subject to breaking memory safety or not, specificallySNP_REG_GHCB_GPA_REQandSNP_STATE_CHANGE_REQGHCB requests. My guess is a garbage request parameter can break the platform, but does it still count as memory safety?