lets delegate to kernel

Any update?

This doesn't look like a regression in the kernel itself, as the tested kernel there was also SP5 5.14.x.

So, if any, it's a difference in the invocation or environment.

Joachin could you recheck the enviroment?

Adding Timo, as I'm not in QE Security now.

We don't have extra details at this and Joaquin indeed is no longer working in the topic area.

At a quick look however, we are running the same test daily in 15-SP5 with seemingly same environment (machine settings - 15-SP6 https://openqa.suse.de/tests/13004557#settings , 15-SP5 https://openqa.suse.de/tests/13075789#settings) without failures, where cat /sys/kernel/security/evm returns 1 in 15-SP5 after identical setting up and 15-SP6 returns 0.

The fact that 15-SP5 is being tested daily means that the test code being executed has not changed in a way that would explain the failure.

"Parsing perl" to say what's being tested is:
1. Using UEFI x86 qemu, but disabled secure boot
2. Use grub parameters rootflags=iversion evm=fix ima_appraise=fix ima_appraise_tcb
3. Run certain keyctl commands as shown here https://openqa.suse.de/tests/13004557/modules/evm_setup/steps/1/src
4. Check the value of /sys/kernel/security/evm

Currently the expectation is that with those steps the evm would be enabled.

If it matters, the secure boot is disabled only after the commands. Also, packages evmctl dracut-ima are installed.

The commands copy-pasted here for easier use:

keyctl add user kmk-user '`dd if=/dev/urandom bs=1 count=32 2>/dev/null`' @u
mkdir /etc/keys
keyctl pipe `/bin/keyctl search @u user kmk-user` > /etc/keys/kmk-user.blob
keyctl add encrypted evm-key 'new user:kmk-user 64' @u
keyctl pipe `/bin/keyctl search @u encrypted evm-key` > /etc/keys/evm.blob
echo -e "MASTERKEYTYPE='user'\nMASTERKEY='/etc/keys/kmk-user.blob'" > /etc/sysconfig/masterkey
echo -e "EVMKEY='/etc/keys/evm.blob'" > /etc/sysconfig/evm
sed -ie '/^GRUB_CMDLINE_LINUX_DEFAULT=/s/"$/ evm=fix ima_appraise=fix ima_appraise_tcb"/g' /etc/default/grub
grub2-mkconfig -o /boot/grub2/grub.cfg

Hm, when I run a local SLE15-SP5 VM with the scripts above, it still shows 0.

Hello,
I've just tried locally, and I was able to reproduce the issue:

localhost:~ # cat /etc/os-release
NAME="SLES"
VERSION="15-SP5"
VERSION_ID="15.5"
PRETTY_NAME="SUSE Linux Enterprise Server 15 SP5"
ID="sles"
ID_LIKE="suse"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:suse:sles:15:sp5"
DOCUMENTATION_URL="https://documentation.suse.com/"

localhost:~ # cat /sys/kernel/security/evm
1


# cat /etc/os-release
NAME="SLES"
VERSION="15-SP6"
VERSION_ID="15.6"
PRETTY_NAME="SUSE Linux Enterprise Server 15 SP6"
ID="sles"
ID_LIKE="suse"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:suse:sles:15:sp6"
DOCUMENTATION_URL="https://documentation.suse.com/"

localhost:~ # cat /sys/kernel/security/evm
0

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ISOs used to install the systems:
* SLE-15-SP5-Online-x86_64-GM-Media1.iso
* SLE-15-SP6-Online-x86_64-Build45.1-Media1.iso


How to reproduce:
1. create a VM with UEFI enabled and install sles 15-sp5
    > select ext4 as rootfs
2. https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/tests/security/mokutil_sign.pm
3. https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/tests/security/ima/ima_setup.pm
4. https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/tests/security/ima/evm_setup.pm
    > cat /sys/kernel/security/evm returns 1 on <=15-SP5, 0 on 15-SP6

Could you rather test just switching the kernel from SLE15-SP5 to SLE15-SP6 while keeping the rest as is?  Does it show the same problem?

Just to make sure that it's a pure kernel regression.

I've installed only the 15-SP6 kernel taken from https://download.suse.de/ibs/Devel:/Kernel:/SLE15-SP6/standard/ , rebooted the system (15-SP5) and:

cat /sys/kernel/security/evm

returns 1 on 15-SP5.

~~~~~~~~~~~~~~~~~
# uname -a
Linux localhost 6.4.0-150600.181.ge75469f-default #1 SMP PREEMPT_DYNAMIC Sun Jan  7 08:46:41 UTC 2024 (e75469f) x86_64 x86_64 x86_64 GNU/Linux

# cat /etc/os-release 
NAME="SLES"
VERSION="15-SP5"
VERSION_ID="15.5"
PRETTY_NAME="SUSE Linux Enterprise Server 15 SP5"
ID="sles"
ID_LIKE="suse"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:suse:sles:15:sp5"
DOCUMENTATION_URL="https://documentation.suse.com/"

# cat /sys/kernel/security/evm
1

Do I understand correctly that you got the value 1 even from SLE15-SP6 kernel if it's started from the good-working SLE15-SP5 environment?

If yes, it means that something else than kernel influences on the behavior.
Or, it might be that the latest SLE15-SP6 kernel already contains the fix.

You can try to upgrade the kernel to SP6 KOTD on the failing SLE15-SP6 environment, to see whether it makes difference, too.

> Do I understand correctly that you got the value 1 even from SLE15-SP6 kernel if it's started from the good-working SLE15-SP5 environment?

Yes, I confirm!

> You can try to upgrade the kernel to SP6 KOTD on the failing SLE15-SP6 environment, to see whether it makes difference, too.

Just tried, and I can confirm that the latest 15-SP6 KOTD fixes the issue:

# cat /etc/os-release 
NAME="SLES"
VERSION="15-SP6"
VERSION_ID="15.6"
PRETTY_NAME="SUSE Linux Enterprise Server 15 SP6"
ID="sles"
ID_LIKE="suse"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:suse:sles:15:sp6"
DOCUMENTATION_URL="https://documentation.suse.com/"

Before:
# uname -a
Linux localhost 6.4.0-150600.4-default #1 SMP PREEMPT_DYNAMIC Thu Nov 23 09:48:45 UTC 2023 (428d2af) x86_64 x86_64 x86_64 GNU/Linux

# cat /sys/kernel/security/evm
0

After:
# uname -a
Linux localhost 6.4.0-150600.181.ge75469f-default #1 SMP PREEMPT_DYNAMIC Sun Jan  7 08:46:41 UTC 2024 (e75469f) x86_64 x86_64 x86_64 GNU/Linux

# cat /sys/kernel/security/evm
1

OK, thanks for confirmation.  Then this must be fixed when the latest kernel is included.