+mm list
Hi Kamil,
Le 21/08/2025 à 14:13, Kamil Aronowski a écrit :
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-
d9c9de394a54@xxxxxxxxx/),
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-
d9c9de394a54@xxxxxxxxx/).
This topic seems to be a memory management topic, not a modules topic.
As I mentionned already in this thread, Linux memory management topics
should be addressed to linux-mm@xxxxxxxxx
Christophe
