Recently, we evaluated the effectiveness of the `init_on_free` mechanism, particularly in the context of preserving privacy by clearing RAM for individuals with high operational security requirements.
As mentioned (https://lore.kernel.org/all/e71bd62c-5ba7-4363-9af1-d9c9de394...@3mdeb.com/), we'd like to ensure that our clients do not have their confidential data leaked after their session has ended with a shutdown/reboot/halt. In short, `init_on_free` appears to wipe the LUKS secret key successfully, but some non-kernel space snippets remain in memory. Some tests have been performed by dumping memory after booting Debian 13 (with `init_on_free` enabled) and then rebooting to our custom EFI memory dumping application. For instance, the mentions of `apparmor_parser`, XKB, udev, or systemd units have been found in the memory dump: ```audit: type=1400 audit(1755156467.556:2): apparmor="STATUS" operation="profile_load" profile="unconfined" name="Discord" pid=967 comm="apparmor_parser"r"
[...]
partial alphanumeric_keys
xkb_symbols "tib_asciinum" {
include "cn(tib)"
name[Group1]= "Tibetan (with ASCII numerals)";
key <AE01> { [ 1, 0x1000f21, 0x1000f04, 0x1000f76 ] }; # 1
[...]
I:10114000
E:ID_MM_CANDIDATE=1
S:disk/by-id/dm-uuid-CRYPT-LUKS2-00b4b79c209a4dcfadf37e310778f583-sda3_crypt
[...]
[Unit]
Description=Switch Root
AssertPathExists=/etc/initrd-release
DefaultDependencies=no
Wants=initrd-switch-root.service
Before=initrd-switch-root.service
AllowIsolate=yes
Wants=initrd-udevadm-cleanup-db.service initrd-root-fs.target
initrd-fs.target systemd-journald.service initrd-cleanup.service
After=initrd-udevadm-cleanup-db.service initrd-root-fs.target
initrd-fs.target emergency.service emergency.target initrd-cleanup.service
[...] ``` Is this the expected behavior, a bug, or a misconfiguration on our end? If it is indeed a bug, we'd be happy to cooperate on improving the `init_on_free` mechanism. If it is expected behavior than we will consider wiping userspace memory some other way, e.g. by implementing a separate Linux Kernel module as described in the previous email (https://lore.kernel.org/all/e71bd62c-5ba7-4363-9af1-d9c9de394...@3mdeb.com/). -- Kamil Aronowski Junior Embedded Firmware Engineer GPG: 3510148A5CD67908 https://3mdeb.com | @3mdeb_com
OpenPGP_0x3510148A5CD67908.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
