Migrate to cheriintrin.h macro names to access compiler builtins #2502
Conversation
|
I think we might want a separate PR for requiring RISC-V v9 first? That would be the CBuildCap revert commit, but also flipping the |
brooksdavis
force-pushed
the
cheriintrin
branch
2 times, most recently
from
fb37fef to
185ebf7
Compare
| * Programmer-friendly macros for CHERI-aware C code. Mirrors | ||
| * cheriintrin.h from Clang. | ||
| */ | ||
| #define cheri_flags_get(x) __builtin_cheri_flags_get(x) |
There was a problem hiding this comment.
It's a bit unfortunate that we can't include the header here, I thought I did all the necessary build system hacks a while ago to ensure that we can use cheri_init_globals.h in the kernel but I could be misremembering.
There was a problem hiding this comment.
It's possible to include them in some places, but I believe not universally. Fortunately it seems unlikely to change.
arichardson
left a comment
arichardson
left a comment
There was a problem hiding this comment.
Thanks this is great. I meant to do this a long time ago but never got around to it...
|
Once this change lands we should look at the leftovers in cheric.h and see if we should be adding them to the compiler versions. I think cheri_top_get is a likely candidate. Less sure about others, but it would be good to settle on a set in the next couple months to support FreeBSD upstreaming. |
Added in #2503 |
brooksdavis
force-pushed
the
cheriintrin
branch
from
185ebf7 to
9b29a36
Compare
We used object capabilities composed of code and data pairs in our early compartmentaization work. We're not doing this now so GC the remaining bit.
We once had different alignemnt requirements for sealed and unsealed things. That realisically came to an end when we adopted sentries so GC the unused remains. Also GC CHERI_REPRESENTABLE_BASE which was no-unused backwards compat.
GC a number of unused things. Relocate some hybrid support bits used only in cheribsdtest to cheribsdtest.h.
It's only used in a single file in the kernel so move it there. We don't anticipate the need for this functionality in userspace.
In userspace, include cheriintrin.h and in the kernel define the same macros (we can't rely on cheriintrin.h in the kernel because the build system disables access to compiler headers in some cases). Gate the old macros behind a (presently defined) __WANT_OLD_CHERI_MACROS macro to provide an escape valve during the transition. In machine/cherireg.h, define permissions missing (or differently named in the case of some ARM_CAP_* values) when needed as well as always defining them in the kernel.
These still depend on some definitions in cheri/cheric.h so get the intrinsics via an include there.
Remove all includes of cheri/cheri.h, it's mostly a kernel head at this point. Remove most includes of cheri/cheric.h in favor of cheri/cherireg.h and cheriintrin.h. The main reason for the former is CHERI_PERM_SW_VMEM. We sometimes need cheri/cheric.h from macros cheri_top_get and CHERI_REPRESENTABLE_*.
Switch to using macros defined in cheriintrin.h to access CHERI builtins. This improves portability and avoids having two divergent sets of macros.
Where possible use cheriintrin.h to access CHERI intrinsics. Add cheri/cherireg.h as needed and only then use cheri/cheric.h in place of both. This improves the portability of more code. While here, eliminate cheri/cheri.h includes as it's essentially a kernel-only header at this point.
Sort the macro names with the bit manipulation macros broken out. Defer sorting the body text for the time being.
brooksdavis
force-pushed
the
cheriintrin
branch
from
9b29a36 to
3f5668a
Compare
This is annoyingly disruptive to large downstream patches, but we're approaching the point of no return and need to do this sooner rather than later if we're going to.