efi: Opt-out EFI variable support

On current design, RuntimeServices.set_virtual_address_map overwrites
all function pointers in the RuntimeServices to not_available function
to avoid calling original functions on runtime phase. However, the
Windows Hardware Abstraction Layer (HAL) stores the original
RuntimeServices function addresses before the phase and uses the
functions afterwards. This behavior causes invalid memory access error
because this firmware does not do self-relocation. On Windows, it to use
EFI variables on runtime phase (See issue #115).

Signed-off-by: Akira Moroo <[email protected]>

Cargo.toml

@@ -23,6 +23,7 @@ log-serial = []
 log-panic = ["log-serial"]
 integration_tests = []
 coreboot = []
+efi-var = []
 
 [dependencies]
 bitflags = "1.2.1"

src/efi/mod.rs

@@ -291,9 +291,13 @@ pub extern "win64" fn get_variable(
     data_size: *mut usize,
     data: *mut c_void,
 ) -> Status {
-    VARIABLES
-        .borrow_mut()
-        .get(variable_name, vendor_guid, attributes, data_size, data)
+    if cfg!(feature = "efi-var") {
+        VARIABLES
+            .borrow_mut()
+            .get(variable_name, vendor_guid, attributes, data_size, data)
+    } else {
+        Status::NOT_FOUND
+    }
 }
 
 pub extern "win64" fn get_next_variable_name(
@@ -311,9 +315,13 @@ pub extern "win64" fn set_variable(
     data_size: usize,
     data: *mut c_void,
 ) -> Status {
-    VARIABLES
-        .borrow_mut()
-        .set(variable_name, vendor_guid, attributes, data_size, data)
+    if cfg!(feature = "efi-var") {
+        VARIABLES
+            .borrow_mut()
+            .set(variable_name, vendor_guid, attributes, data_size, data)
+    } else {
+        Status::UNSUPPORTED
+    }
 }
 
 pub extern "win64" fn get_next_high_mono_count(_: *mut u32) -> Status {