Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CSBNDSRDown in addition to CSBNDSR? #452

Open
nwf opened this issue Nov 25, 2024 · 0 comments
Open

CSBNDSRDown in addition to CSBNDSR? #452

nwf opened this issue Nov 25, 2024 · 0 comments

Comments

@nwf
Copy link
Collaborator

nwf commented Nov 25, 2024

CHERIoT software occasionally finds it useful to answer "what is the largest1 representable span with a fixed base and less than a given length". In particular, this lets us slice up a ring buffer's unused portion into exactly representable spans, which is quite useful for cross-trust-domain calls, as it free us from having to worry about exposing any part of the used portion as we might with CSBNDSR. See https://github.com/CHERIoT-Platform/network-stack/blob/2bf75ad2da4f586637270803ca94b4be2745c801/lib/tls/tls.cc#L214-L221 for how that's historically been done and CHERIoT-Platform/cheriot-sail#74 for the instruction we've just added to get knowledge of mantissa widths out of software. (That'd be especially important for encodings that use internal exponents, effectively changing mantissa width as a function of bounds length.)

This instruction is, in principle, also useful for things like subsetting representable suffixes of the stack. CHERIoT has no urgent use for it in that case at present, since our stacks are sufficiently tiny and aligned that we can just use CSBNDS (the exact form) in all cases.

I'd be happy to keep this as an Xcheriot addition, but on the off chance that it'd be useful to other Zcheripurecap users, I thought I'd mention it.

Footnotes

  1. CHERIoT simplifies its implementation of this instruction for its current somewhat quirky encoding such that any requested span larger than about 8 MiB is rounded down to about 8 MiB (specifically, ((1 << 9) - 1) << 14, which is (1 << 23) - (1 << 14)). In practice, this is unlikely to matter, and it remains usable for the "slice up a buffer" software use case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant