Fix support on CHERI RISC-V architecture#10272
Fix support on CHERI RISC-V architecture#10272wbeasley-thegoodpenguin wants to merge 3 commits intowolfSSL:masterfrom
Conversation
This caused problems on CHERI with bounds violations. The code assumes WC_CACHE_LINE_SZ == 64 and perhaps this is not the case. Signed-off-by: William Beasley (The Capable Hub) <wbeasley@thegoodpenguin.co.uk>
|
Can one of the admins verify this patch? |
|
@wbeasley-thegoodpenguin see https://github.com/The-Capable-Hub/meta-cheri/blob/pz/refactoring-2/kas/riscv64-multilib.yml#L42 for python on CHERI (but in integer mode) |
|
LinuxJedi
left a comment
LinuxJedi
left a comment
There was a problem hiding this comment.
Many thanks for this contribution. I've added some initial review comments based on the CI output. In the mean time, can you please email support@wolfssl.com so that we can file a CLA for you?
@SparkiDev can you please look at commit 2 here? I suspect there has to be a way to keep constant time here for the CHERI platform, but this is beyond me.
wbeasley-thegoodpenguin
force-pushed
the
wbeasley/meta-cheri-fixes
branch
from
b8bad90 to
bf099bd
Compare
The branchless code in casts sp_int pointers to size_t for bitmask arithmetic, then casts the result back to sp_int*. On CHERI, pointer-to-integer casts strip the hardware capability tag. The reconstructed pointer is tagless and cannot be dereferenced, causing a tag-violation fault. Swap this for SP_CT_ADDR(t, idx) which on CHERI will do a basic array index for now. On non-CHERI targets the behaviour is the same. Signed-off-by: William Beasley (The Capable Hub) <wbeasley@thegoodpenguin.co.uk>
CHERI pointers are capabilities and are larger than other platforms. They also require 16-byte alignment. Signed-off-by: William Beasley (The Capable Hub) <wbeasley@thegoodpenguin.co.uk>
wbeasley-thegoodpenguin
force-pushed
the
wbeasley/meta-cheri-fixes
branch
from
bf099bd to
5e51e7a
Compare
|
Many thanks for resolving these issues. I think we should keep I've pinged Sean internally just to check over the constant time things. But in general I'm happy. |
| }; | ||
| /* Constant time access here will not work on CHERI so fallback to basic for now */ | ||
| #ifdef __CHERI_PURE_CAPABILITY__ | ||
| #define SP_CT_ADDR(t, idx) ((t)[(idx)]) |
There was a problem hiding this comment.
The purpose of the code you had to disable is to make sure both address are loaded into cache even though only one is accessed.
Is there a way to preload t[0] and t[1] with CHERI and then use only one of the addresses?
5 participants
Description
Whilst integrating wolfssl into the meta-cheri yocto layer I encountered issues during compilation and at runtime.
This PR is made up of 3 commits:
Commit 1:
At runtime this was causing a CHERI bounds exception. It seem
XorTable_Multiwas using hardcoded masks0xf0/0x0fwhich assume 64-bit cache lines. This meant that it was attempting to stride beyond the 256-entry table.Commit 2:
I was get a CHERI tag violation fault. On CHERI when you cast a pointer to a
size_tthis removes the hardware validity tag. When it is cast back to a pointer its tag is no longer valid, and leads to a violation fault. My fix here needs input, as it invalidates constant-time, but I left it as is in the interest of getting it working on CHERI.Commit 3:
I tripped a static_assert
WOLFSSL_ASSERT_SIZEOF_GE(ssl->async->args, *args);. On CHERI pointers are capabilities and are larger (16-bytes in this case). I made the buffer larger here to accommodate that. Also CHERI pointers need to be 16-byte aligned so swapped it from aword32to amax_align_t.Testing
Ran the wolfcrypttest and was able to use wolfssh to connect to ssh server running on the target.
python has not been adapted for RISC-V CHERI yet, so I dont think its possible to run other tests
Checklist