From 7b055bd29e824dd4326ede6e99b568208aa297f7 Mon Sep 17 00:00:00 2001 From: gjbauer Date: Fri, 31 Oct 2025 20:21:27 -0400 Subject: [PATCH 1/2] removed extra and from security.md Signed-off-by: gjbauer --- docs/platform/security.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/platform/security.md b/docs/platform/security.md index 89ed224b..2dc5d15f 100644 --- a/docs/platform/security.md +++ b/docs/platform/security.md @@ -141,7 +141,7 @@ has powered on and the SEP is satisfied with the state of iBoot and the system f When FileVault is enabled for an APFS volume, the VEK and xART are wrapped with a Key Encryption Key (KEK), which is backed by user credentials from the macOS container in question. The machine will be unable to read the user data volume of the protected container until these credentials are provided at startup. Enabling this is instantaneous on Apple Silicon machines, since -the only required operation is generating the KEK and and a recovery key. The system snapshot, Preboot, and +the only required operation is generating the KEK and a recovery key. The system snapshot, Preboot, and recovery volumes are not protected by FileVault. These partitions are immutable, backed by the SEP, and contain no user data and therefore do not particularly benefit from FileVault. All encryption keys are destroyed by the SEP when the Machine Owner requests the machine to be wiped, guaranteeing that any residual data is indecipherable even to data recovery From 75f0c831c1e17c9692d3b9b44f945cbb2d1d2c94 Mon Sep 17 00:00:00 2001 From: gjbauer Date: Fri, 31 Oct 2025 20:22:57 -0400 Subject: [PATCH 2/2] Useally -> Usually in agx.md Signed-off-by: gjbauer --- docs/hw/soc/agx.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/hw/soc/agx.md b/docs/hw/soc/agx.md index be78ff00..7f8036b8 100644 --- a/docs/hw/soc/agx.md +++ b/docs/hw/soc/agx.md @@ -615,9 +615,9 @@ These registers are read once, during initialization: These status registers are continually checked by *something* on the CPU 0x11008 : u32 - Always counts up whenever work is done - 0x1100c : u32 - Useally 0 + 0x1100c : u32 - Usually 0 0x11010 : u32 - Another work counter? counts up slower - 0x11014 : u32 - Useally 0 + 0x11014 : u32 - Usually 0 There doesn't seem to be a good relationship of when these status registers are read, relative to the ASC Pong and Kicks.