grsecurity forums

Has anyone run into problems with suspend-to-ram and grsec before?

It's working for me on:
- 2.6.23.16 with grsecurity
- 2.6.24.2 without grsecurity

But it fails (laptop won't resume) on 2.6.24.2 with the grsecurity patch.

Here are diffs between the config of each kernel:
Vanilla 2.6.24.2 to 2.6.24.2-grsec:
http://grsecurity.net/pipermail/grsecur ... t-0002.bin

2.6.23.16-grsec to 2.6.24.2-grsec:
http://grsecurity.net/pipermail/grsecur ... t-0003.bin

Before I start disabling every PAX/grsec config option in an exhaustive binary search fashion, can people suggest a few options which may be causing problems?

Francois

fmarier wrote:Has anyone run into problems with suspend-to-ram and grsec before?

to be honest, i never checked PaX against suspend/hibernation (it's one of the many items on the todo list), so even if it seemed to work before, it was due to luck, not design. with that said, try to disable SANITIZE at least and if you can, also post more information about the failure (i think recent kernels have some sort of ability to store some debug info in the CMOS area that can be decoded back into source code lines).

fmarier wrote:Has anyone run into problems with suspend-to-ram and grsec before?

It's working for me on:
- 2.6.23.16 with grsecurity
- 2.6.24.2 without grsecurity

But it fails (laptop won't resume) on 2.6.24.2 with the grsecurity patch.

Here are diffs between the config of each kernel:
Vanilla 2.6.24.2 to 2.6.24.2-grsec:
http://grsecurity.net/pipermail/grsecur ... t-0002.bin

2.6.23.16-grsec to 2.6.24.2-grsec:
http://grsecurity.net/pipermail/grsecur ... t-0003.bin

Before I start disabling every PAX/grsec config option in an exhaustive binary search fashion, can people suggest a few options which may be causing problems?

Francois

Suspend-to-ram doesn't work with KERNEXEC or UDEREF.

The machine doesn't power off with KERNEXEC. (ACPI S1 standby works, S3 doesn't work).

It doesn't resume with UDEREF. It does reboot. (ACPI S1 standby works too.)

But SANITIZE works for me with 2.1.9grsec+2.6.18 "debianised" kernel+extras (on X86 PC).

But ACPI codes and arch. codes in "stable vanilla" kernel are changed too much.

My "PaX_config". :

Code: Select all

#
# PaX
#
CONFIG_PAX=y

#
# PaX Control
#
# CONFIG_PAX_SOFTMODE is not set
CONFIG_PAX_EI_PAX=y
# CONFIG_PAX_PT_PAX_FLAGS is not set
# CONFIG_PAX_NO_ACL_FLAGS is not set
CONFIG_PAX_HAVE_ACL_FLAGS=y
# CONFIG_PAX_HOOK_ACL_FLAGS is not set

#
# Non-executable pages
#
CONFIG_PAX_NOEXEC=y
CONFIG_PAX_PAGEEXEC=y
CONFIG_PAX_SEGMEXEC=y
# CONFIG_PAX_DEFAULT_PAGEEXEC is not set
CONFIG_PAX_DEFAULT_SEGMEXEC=y
# CONFIG_PAX_EMUTRAMP is not set
CONFIG_PAX_MPROTECT=y
# CONFIG_PAX_NOELFRELOCS is not set

#
# Address Space Layout Randomization
#
CONFIG_PAX_ASLR=y
CONFIG_PAX_RANDKSTACK=y
CONFIG_PAX_RANDUSTACK=y
CONFIG_PAX_RANDMMAP=y

#
# Miscellaneous hardening features
#
CONFIG_PAX_MEMORY_SANITIZE=y


same problem here on a 2.6.22-4 (etch-backport) with current grsec2.1.11-vs2.2.0.6 patch. Haven't spend time (don't have a lot of spare one actually) finding which option is concerned, but might in the future if you want more informations.

Wondering if this is something interesting for a security tool, to spend time , seeing how badly secure suspend-on-ram is anyway.

bertagaz wrote:Wondering if this is something interesting for a security tool, to spend time , seeing how badly secure suspend-on-ram is anyway.

it's not interesting for security per se but it is useful for keeping PaX induced changes consistent across the whole tree. as i said, i'm aware of suspend (and other features) breaking due to PaX, it's just that i have better things to work on than fixing them. but any useful hint will make me look at the code and if it's easy to fix, i'll do it.

I did some more tests and it turns out that applying the grsec patch (grsecurity-2.1.11-2.6.24.2-200802192340.patch) over 2.6.24.3 breaks suspend-to-ram even if all of the grsec and PaX options are disabled in the config file.

My laptop won't resume from a suspend-to-ram with the grsec-patched kernel, but it will resume from the unpatched kernel.

Here is the diff (i.e. no differences) between the two kernel configs:
--- config-2.6.24.3 2008-03-03 20:59:41.000000000 +1300
+++ config-2.6.24.3-grsec 2008-03-04 14:01:54.000000000 +1300
@@ -548,6 +548,7 @@
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_MATCH_OWNER=m
CONFIG_IP_NF_MATCH_ADDRTYPE=m
+# CONFIG_IP_NF_MATCH_STEALTH is not set
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_LOG=m
@@ -2902,12 +2903,25 @@
CONFIG_EARLY_PRINTK=y
CONFIG_DEBUG_STACKOVERFLOW=y
# CONFIG_DEBUG_STACK_USAGE is not set
-# CONFIG_DEBUG_RODATA is not set
# CONFIG_IOMMU_DEBUG is not set

#
# Security options
#
+
+#
+# Grsecurity
+#
+# CONFIG_GRKERNSEC is not set
+
+#
+# PaX
+#
+
+#
+# Miscellaneous hardening features
+#
+# CONFIG_PAX_MEMORY_SANITIZE is not set
CONFIG_KEYS=y
# CONFIG_KEYS_DEBUG_PROC_KEYS is not set
CONFIG_SECURITY=y

I tried a 2.6.24 kernel with grsec and suspend to ram.

Kernel was this.

Grsec patch was this: grsecurity-2.1.11-2.6.24.3-200803101831.patch. / ~ the minor typo version /

Nvidia driver: 169.01 from here.

Suspend2ram worked without kernexec & uderef but with sanitize. Powersave log is here.I have got a bit workaround with the kernel modules because I have got an "retro" tuner card / 1998-1999 /. It doesn't know the ACPI.

For example lirc modules doesn't work more with this kernel but this will an other history.