box64 icon indicating copy to clipboard operation
box64 copied to clipboard

Security Warning: RISC-V CPUs from T-HEAD May Have Vulnerabilities on Several Extensions

Open Coekjan opened this issue 1 year ago • 6 comments

See https://ghostwriteattack.com/ for more details.

As reported in the paper, this vulnerability allows unprivileged attackers, even those with limited access, to read and write any part of the computer’s memory and to control peripheral devices like network cards.

Box64 is using these extensions, so it might generate harmful target code in cases.

Coekjan avatar Aug 10 '24 05:08 Coekjan

We use these extensions in a good way, not an evil way. I don't see any issues in box64 side by just using thead extensions.

ksco avatar Aug 10 '24 05:08 ksco

We use these extensions in a good way, not an evil way. I don't see any issues in box64 side by just using thead extensions.

I am not familiar with how we use these extensions in box64, so report this as a "warning".

If we are currently using them in good way, I would still suggest that code changes in the future related with these extensions should be carefully checked.

Coekjan avatar Aug 10 '24 05:08 Coekjan

If you read the paper, you'll see that it uses some reserved vector instruction that accidentally implemented by thead CPUs to access physical memory directly. We would never use reserved encoding, and we do not support xtheadvector.

ksco avatar Aug 10 '24 05:08 ksco

we do not support xtheadvector.

I wish you would 😔 there's a lot of performance left on the table with my SG2042 not having the thead custom extensions supported.

archanox avatar Aug 19 '24 16:08 archanox

we do not support xtheadvector.

I wish you would 😔 there's a lot of performance left on the table with my SG2042 not having the thead custom extensions supported.

We will. But after the v1p0 support. I think the code can be largely shared with v0p7.

ksco avatar Aug 19 '24 17:08 ksco

@archanox FYI we've added a preliminary XTheadVector support: https://github.com/ptitSeb/box64/pull/1892.

We implemented most of the SSE opcodes used by dav1d, which happens using SSE a lot, and below is a simple benchmark result:

BOX64_DYNAREC_RV64NOEXT=vector box64 ./bin/dav1d -i ./Chimera-AV1-8bit-480x270-552kbps.ivf --muxer null --threads 8
dav1d 1.4.3 - by VideoLAN
Decoded 8929/8929 frames (100.0%) - 38.96/23.98 fps (1.62x)

box64 ./bin/dav1d -i ./Chimera-AV1-8bit-480x270-552kbps.ivf --muxer null --threads 8
dav1d 1.4.3 - by VideoLAN
Decoded 8929/8929 frames (100.0%) - 139.90/23.98 fps (5.84x)

The result looks good, isn't it? But please note that there are still many unimplemented opcodes that fall back to the scalar version with context switching, so it may even slow things down if there are too many switching.

ksco avatar Oct 02 '24 08:10 ksco

Can this be closed? It sounds like everything has been addressed.

LukeShortCloud avatar Oct 24 '25 22:10 LukeShortCloud