Page MenuHomeFreeBSD

amd64: Add MD bits for KMSAN
ClosedPublic

Authored by markj on Aug 8 2021, 9:52 PM.
Tags
None
Referenced Files
Unknown Object (File)
Feb 21 2024, 5:34 AM
Unknown Object (File)
Dec 22 2023, 9:30 PM
Unknown Object (File)
Dec 21 2023, 4:04 PM
Unknown Object (File)
Dec 18 2023, 9:53 PM
Unknown Object (File)
Sep 4 2023, 6:40 AM
Unknown Object (File)
Aug 7 2023, 5:52 PM
Unknown Object (File)
Aug 7 2023, 5:52 PM
Unknown Object (File)
Aug 7 2023, 5:49 PM
Subscribers

Details

Summary


- Interrupt and exception handlers must call kmsan_intr_enter()
prior to calling any C code. This is because the KMSAN runtime
maintains some TLS in order to track initialization state of
function parameters and return values across function calls.
To ensure that this state is kept consistent, the runtime uses a stack
of TLS blocks, and kmsan_intr_enter() and kmsan_intr_leave() push and
pop that stack, respectively.
- C code called in interrupt/exception context has to mark trap frames
as initialized, since the assembly code which saves registers is not
instrumented (and of course the hardware trapframe needs to be marked
initialized as well).

Sponsored by: The FreeBSD Foundation

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

markj requested review of this revision.Aug 8 2021, 9:52 PM

Does this thing require assistance during context switch? Part of the ctx switch code is written in C and is called with weird state while half of the switch was done, I mean pmap_activate_sw().

sys/amd64/amd64/exception.S
359–360

Should this call be wrapped?

582

Do you need the wrap there?

593

mds handler is in C as well

617

What about ast?

748

This one as well

1054–1055

And this

1150

And another instance of ast call

markj marked 2 inline comments as done.Aug 9 2021, 1:25 AM
In D31467#709289, @kib wrote:

Does this thing require assistance during context switch? Part of the ctx switch code is written in C and is called with weird state while half of the switch was done, I mean pmap_activate_sw().

I believe not, I spent some time trying to verify this a while ago.

sys/amd64/amd64/exception.S
359–360

Yes, thanks. This should panic unconditionally (and KMSAN disables itself after a panic), but there is a window before that where KMSAN could otherwise generate false positives.

582

This one does not need it. It's really only needed for asynchronous trap handlers that may fire when the CPU is already in ring 0. After a user->kernel switch the KMSAN TLS block is already in a consistent state. For interrupt handlers it is simpler and harmless to unconditionally call kmsan_intr_enter() regardless of whether the CPU was already in kernel mode.

593

Hmm, all of the individual handlers appear to be in asm?

617

This should be the same case as amd64_syscall().

748

I don't see why, calltrap is an asm label.

1150

This one is ok since we are returning to user mode here.

markj marked an inline comment as done.

Handle dblfault and mchk

kib added inline comments.
sys/amd64/amd64/exception.S
582

Perhaps note this in a comment both there and near ast call. So that next time somebody rearranges this code, it would be more clear where to put KMSAN_ wrappers.

This revision is now accepted and ready to land.Aug 9 2021, 2:06 AM
sys/amd64/amd64/exception.S
582

How about I put it somewhere more central, before the KMSAN_ENTER definition?

sys/amd64/amd64/exception.S
582

Up to you, of course.

This revision now requires review to proceed.Aug 9 2021, 4:11 AM
This revision is now accepted and ready to land.Aug 9 2021, 4:23 AM
This revision was automatically updated to reflect the committed changes.