Merge pull request #54 from dsprenkels/master

Harden stable implementation of black_box

Author: hdevalence

README.md

@@ -19,11 +19,6 @@ To prevent the latter possibility, when using the `nightly` feature
 from the optimizer, by passing it through an inline assembly block.  For more
 information, see the _About_ section below.
 
-When not using the `nightly` feature, there is no protection against b).  This
-is unfortunate, but is at least no worse than C code, and has the advantange
-that if a suitable black box is stabilized, we will be able to transparently
-enable it with no changes to the external interface).
-
 ```toml
 [dependencies.subtle]
 version = "2.1"

src/lib.rs

@@ -155,10 +155,23 @@ fn black_box(mut input: u8) -> u8 {
 #[inline(never)]
 fn black_box(input: u8) -> u8 {
     debug_assert!((input == 0u8) | (input == 1u8));
-    // We don't have access to inline assembly or test::black_box or ...
+    // We don't have access to inline assembly or test::black_box, so we use the fact that
+    // volatile values will never be elided to register values.
     //
-    // Bailing out, hopefully the compiler doesn't use the fact that `input` is 0 or 1.
-    input
+    // Note: Rust's notion of "volatile" is subject to change over time. While this code may break
+    // in a non-destructive way in the future, it is better than doing nothing.
+
+    unsafe {
+        // Optimization barrier
+        //
+        // Unsafe is ok, because:
+        //   - &input is not NULL;
+        //   - size of input is not zero;
+        //   - u8 is neither Sync, nor Send;
+        //   - u8 is Copy, so input is always live;
+        //   - u8 type is always properly aligned.
+        core::ptr::read_volatile(&input as *const u8)
+    }
 }
 
 impl From<u8> for Choice {