Decouple slub_debug and no_hash_pointers
#368
Assignees
Labels
[Defense] information exposure
Provide a defense for an information exposure
enhancement
New feature or request
[PATCH] Accepted
A submitted patch has been accepted upstream
Comments
kees
added
[Defense] information exposure
|
Hi, I saw this issue and started to look into it. I have a patch cf76d5a, but before sending it for wider review I wanted to check-in and see if this is what you had in mind and looks ok. |
|
This is a good start, but I think it needs to pay much more careful attention to behavioral changes. Probably you'll need to split the bootparam parsing from the enablement (i.e. leave the init function in the kmem cache code). |
|
I updated the patch ac88027, back to using the runtime check. I thought of using a static_key similar to |
|
This is closer; thanks! I've tweaked your patch and sent this: |
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this issue
Apr 10, 2025
Some system owners use slab_debug=FPZ (or similar) as a hardening option, but do not want to be forced into having kernel addresses exposed due to the implicit "no_hash_pointers" boot param setting.[1] Introduce the "hash_pointers" boot param, which defaults to "auto" (the current behavior), but also includes "always" (forcing on hashing even when "slab_debug=..." is defined), and "never". The existing "no_hash_pointers" boot param becomes an alias for "hash_pointers=never". This makes it possible to boot with "slab_debug=FPZ hash_pointers=always". Link: KSPP#368 [1] Fixes: 7927029 ("slub: force on no_hash_pointers when slub_debug is enabled") Co-developed-by: Sergio Perez Gonzalez <[email protected]> Signed-off-by: Sergio Perez Gonzalez <[email protected]> Signed-off-by: Kees Cook <[email protected]>
|
Thanks! I learned a lot from this. |
kees
added
[PATCH] Accepted
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this issue
Apr 21, 2025
Some system owners use slab_debug=FPZ (or similar) as a hardening option, but do not want to be forced into having kernel addresses exposed due to the implicit "no_hash_pointers" boot param setting.[1] Introduce the "hash_pointers" boot param, which defaults to "auto" (the current behavior), but also includes "always" (forcing on hashing even when "slab_debug=..." is defined), and "never". The existing "no_hash_pointers" boot param becomes an alias for "hash_pointers=never". This makes it possible to boot with "slab_debug=FPZ hash_pointers=always". Link: KSPP#368 [1] Fixes: 7927029 ("slub: force on no_hash_pointers when slub_debug is enabled") Co-developed-by: Sergio Perez Gonzalez <[email protected]> Signed-off-by: Sergio Perez Gonzalez <[email protected]> Acked-by: Vlastimil Babka <[email protected]> Acked-by: David Rientjes <[email protected]> Reviewed-by: Bagas Sanjaya <[email protected]> Reviewed-by: Harry Yoo <[email protected]> Acked-by: Rafael Aquini <[email protected]> Tested-by: Petr Mladek <[email protected]> Reviewed-by: Petr Mladek <[email protected]> Signed-off-by: Kees Cook <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When booting with "slub_debug=FZ", hashed pointers are disabled.
The source of the problem is commit
7927029 ("slub: force on no_hash_pointers when slub_debug is enabled")
I objected at the time:
https://lore.kernel.org/all/202109200726.2EFEDC5@keescook/
But it was never reverted.
If someone could send a patch that would decouple these again, I'd appreciate it. I think it would be best to refactor the boot param "no_hash_pointers" into "hash_pointers={auto,always,never}", with the old setting meaning "hash_pointers=never", but the default being "=auto" that falls back to this case where slub debug turns it off. But that would allow for "slub_debug=FZ hash_pointers=always" and we could have the best of both worlds.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1098362
The text was updated successfully, but these errors were encountered: