You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I just noticed a comment in token_key_new that the User0 permission is reserved for possible future use by the allocator so is cleared on SKeys at the moment. I only noticed because I'm using an SKey as a handy sealing type capability in the ISA test and it slightly reduces the coverage of the candperms test. It's not a big deal but just noting it here for future reference and to discuss possible uses.
The text was updated successfully, but these errors were encountered:
SObj allocation and sealing are combined at the moment. This makes sense because we have to know we're allocating a sealed object so we reserve space for the metadata. However, it means there's no token_seal function so it doesn't really make sense to have separate 'allocate' permission in the SKey.
If you can unseal an SObj then (I think) you can free it at current so a separate deallocate permission is only useful for delegating the ability to deallocate without the ability to unseal. This does sound potentially useful as it potentially avoids a call into the owning compartment for deallocation.
I just noticed a comment in
token_key_new
that the User0 permission is reserved for possible future use by the allocator so is cleared onSKey
s at the moment. I only noticed because I'm using anSKey
as a handy sealing type capability in the ISA test and it slightly reduces the coverage of thecandperms
test. It's not a big deal but just noting it here for future reference and to discuss possible uses.The text was updated successfully, but these errors were encountered: