#1446 integrated valgrind requests to mark memory as Un-/Defined into libcrux-secrets for all classify and declassify operations.
As discovered in celabshq/libcrux-iot#149, the usage of classify_ref can lead to false positives when testing under valgrind.
To quote that PR:
The core issue is, that classify_ref() temporarily classifies memory via the secret types in libcrux-secrets (which is needed in some places for API compatibility), but permanently marks the memory as Undefined for valgrind.
This could be resolved with a changed API in libcrux-secrets:
- A closure based API such as
with_classify_ref<T, R>(self: &[T], f: impl Fn(&[Secret<T>]) -> R) -> R that automatically performs a ct_declassify after the closure executed
- A wrapper type with a drop impl
Open questions:
- How would such APIs interact with extraction?
- With the shared ref API, other code could perform branching on the plain slice while the closure is executing on the secret slice, this would also lead to a false positive
- Unclear whether this could be resolved by only having the
&mut variant, as the plain slice might necessarily be shared due to surrounding API constraints
#1446 integrated valgrind requests to mark memory as Un-/Defined into libcrux-secrets for all classify and declassify operations.
As discovered in celabshq/libcrux-iot#149, the usage of
classify_refcan lead to false positives when testing under valgrind.To quote that PR:
This could be resolved with a changed API in libcrux-secrets:
with_classify_ref<T, R>(self: &[T], f: impl Fn(&[Secret<T>]) -> R) -> Rthat automatically performs act_declassifyafter the closure executedOpen questions:
&mutvariant, as the plain slice might necessarily be shared due to surrounding API constraints