Kdump does not support secure boot yet, so let's claim it is not supported at the begginning of service start function.
In this patch for checking secure boot status I'm checking the efivars per suggestion from pjones. see in code comments for the details.
Tested in Fedora 19 + qemu ovmf with secure boot enabled.
Signed-off-by: Dave Young dyoung@redhat.com --- kdumpctl | 36 ++++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+)
--- kexec-tools.orig/kdumpctl +++ kexec-tools/kdumpctl @@ -500,8 +500,44 @@ selinux_relabel() done }
+# Check if secure boot is being enforced. +# +# Per Peter Jones, we need check efivar SecureBoot-$(the UUID) and +# SetupMode-$(the UUID), they are both 5 bytes binary data. The first four +# bytes are the attributes associated with the variable and can safely be +# ignored, the last bytes are one-byte true-or-false variables. If SecureBoot +# is 1 and SetupMode is 0, then secure boot is being enforced. +# +# Assume efivars is mounted at /sys/firmware/efi/efivars. +function check_secure_boot() +{ + local secure_boot_file setup_mode_file + local secure_boot_byte setup_mode_byte + + secure_boot_file=$(find /sys/firmware/efi/efivars -name SecureBoot-* 2>/dev/null) + setup_mode_file=$(find /sys/firmware/efi/efivars -name SetupMode-* 2>/dev/null) + + if [ -f "$secure_boot_file" ] && [ -f "$setup_mode_file" ]; then + secure_boot_byte=$(hexdump -v -e '/1 "%d\ "' $secure_boot_file|cut -d' ' -f 5) + setup_mode_byte=$(hexdump -v -e '/1 "%d\ "' $setup_mode_file|cut -d' ' -f 5) + + if [ "$secure_boot_byte" = "1" ] && [ "$setup_mode_byte" = "0" ]; then + return 0 + fi + fi + + return 1 +} + function start() { + check_secure_boot + if [ $? -eq 0 ]; then + echo "Secure boot is not supported in kdump yet. Please disable secure boot and retry." + echo "Starting kdump: [FAILED]" + return 1 + fi + check_config if [ $? -ne 0 ]; then echo "Starting kdump: [FAILED]"
On 02/07/14 at 04:32pm, Dave Young wrote:
Kdump does not support secure boot yet, so let's claim it is not supported at the begginning of service start function.
In this patch for checking secure boot status I'm checking the efivars per suggestion from pjones. see in code comments for the details.
Tested in Fedora 19 + qemu ovmf with secure boot enabled.
Corrected the indentation, please ignore previous version. Sorry for the noise.
Signed-off-by: Dave Young dyoung@redhat.com
kdumpctl | 36 ++++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+)
--- kexec-tools.orig/kdumpctl +++ kexec-tools/kdumpctl @@ -500,8 +500,44 @@ selinux_relabel() done }
+# Check if secure boot is being enforced. +# +# Per Peter Jones, we need check efivar SecureBoot-$(the UUID) and +# SetupMode-$(the UUID), they are both 5 bytes binary data. The first four +# bytes are the attributes associated with the variable and can safely be +# ignored, the last bytes are one-byte true-or-false variables. If SecureBoot +# is 1 and SetupMode is 0, then secure boot is being enforced. +# +# Assume efivars is mounted at /sys/firmware/efi/efivars. +function check_secure_boot() +{
- local secure_boot_file setup_mode_file
- local secure_boot_byte setup_mode_byte
- secure_boot_file=$(find /sys/firmware/efi/efivars -name SecureBoot-* 2>/dev/null)
- setup_mode_file=$(find /sys/firmware/efi/efivars -name SetupMode-* 2>/dev/null)
- if [ -f "$secure_boot_file" ] && [ -f "$setup_mode_file" ]; then
secure_boot_byte=$(hexdump -v -e '/1 "%d\ "' $secure_boot_file|cut -d' ' -f 5)setup_mode_byte=$(hexdump -v -e '/1 "%d\ "' $setup_mode_file|cut -d' ' -f 5)if [ "$secure_boot_byte" = "1" ] && [ "$setup_mode_byte" = "0" ]; thenreturn 0fi- fi
- return 1
+}
function start() {
- check_secure_boot
- if [ $? -eq 0 ]; then
echo "Secure boot is not supported in kdump yet. Please disable secure boot and retry."echo "Starting kdump: [FAILED]"return 1- fi
- check_config if [ $? -ne 0 ]; then echo "Starting kdump: [FAILED]"
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/kexec
On 02/07/14 at 04:32pm, Dave Young wrote:
Kdump does not support secure boot yet, so let's claim it is not supported at the begginning of service start function.
In this patch for checking secure boot status I'm checking the efivars per suggestion from pjones. see in code comments for the details.
Why you didn't use /sys/kernel/security/securelevel interface?
From http://git.app.eng.bos.redhat.com/rhel7.git/tree/Documentation/security/secu..., it says:
Linux securelevel interface ---------------------------
The Linux securelevel interface (inspired by the BSD securelevel interface) is a runtime mechanism for configuring coarse-grained kernel-level security restrictions. It provides a runtime configuration variable at /sys/kernel/security/securelevel which can be written to by root. The following values are supported:
-1: Permanently insecure mode. This level is equivalent to level 0, but once set cannot be changed.
0: Insecure mode (default). This level imposes no additional kernel restrictions.
1: Secure mode. If set, userspace will be unable to perform direct access to PCI devices, port IO access, access system memory directly via /dev/mem and /dev/kmem, perform kexec_load(), use the userspace software suspend mechanism, insert new ACPI code at runtime via the custom_method interface or modify CPU MSRs (on x86). Certain drivers may also limit additional interfaces.
Once the securelevel value is increased, it may not be decreased.
Thanks WANG Chao
Tested in Fedora 19 + qemu ovmf with secure boot enabled.
Signed-off-by: Dave Young dyoung@redhat.com
kdumpctl | 36 ++++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+)
--- kexec-tools.orig/kdumpctl +++ kexec-tools/kdumpctl @@ -500,8 +500,44 @@ selinux_relabel() done }
+# Check if secure boot is being enforced. +# +# Per Peter Jones, we need check efivar SecureBoot-$(the UUID) and +# SetupMode-$(the UUID), they are both 5 bytes binary data. The first four +# bytes are the attributes associated with the variable and can safely be +# ignored, the last bytes are one-byte true-or-false variables. If SecureBoot +# is 1 and SetupMode is 0, then secure boot is being enforced. +# +# Assume efivars is mounted at /sys/firmware/efi/efivars. +function check_secure_boot() +{
- local secure_boot_file setup_mode_file
- local secure_boot_byte setup_mode_byte
- secure_boot_file=$(find /sys/firmware/efi/efivars -name SecureBoot-* 2>/dev/null)
- setup_mode_file=$(find /sys/firmware/efi/efivars -name SetupMode-* 2>/dev/null)
- if [ -f "$secure_boot_file" ] && [ -f "$setup_mode_file" ]; then
secure_boot_byte=$(hexdump -v -e '/1 "%d\ "' $secure_boot_file|cut -d' ' -f 5)setup_mode_byte=$(hexdump -v -e '/1 "%d\ "' $setup_mode_file|cut -d' ' -f 5)if [ "$secure_boot_byte" = "1" ] && [ "$setup_mode_byte" = "0" ]; thenreturn 0fi- fi
- return 1
+}
function start() {
- check_secure_boot
- if [ $? -eq 0 ]; then
echo "Secure boot is not supported in kdump yet. Please disable secure boot and retry."echo "Starting kdump: [FAILED]"return 1- fi
- check_config if [ $? -ne 0 ]; then echo "Starting kdump: [FAILED]"
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/kexec
On 02/07/14 at 05:06pm, WANG Chao wrote:
On 02/07/14 at 04:32pm, Dave Young wrote:
Kdump does not support secure boot yet, so let's claim it is not supported at the begginning of service start function.
In this patch for checking secure boot status I'm checking the efivars per suggestion from pjones. see in code comments for the details.
Why you didn't use /sys/kernel/security/securelevel interface?
From http://git.app.eng.bos.redhat.com/rhel7.git/tree/Documentation/security/secu..., it says:
Linux securelevel interface
The Linux securelevel interface (inspired by the BSD securelevel interface) is a runtime mechanism for configuring coarse-grained kernel-level security restrictions. It provides a runtime configuration variable at /sys/kernel/security/securelevel which can be written to by root. The following values are supported:
-1: Permanently insecure mode. This level is equivalent to level 0, but once set cannot be changed.
0: Insecure mode (default). This level imposes no additional kernel restrictions.
1: Secure mode. If set, userspace will be unable to perform direct access to PCI devices, port IO access, access system memory directly via /dev/mem and /dev/kmem, perform kexec_load(), use the userspace software suspend mechanism, insert new ACPI code at runtime via the custom_method interface or modify CPU MSRs (on x86). Certain drivers may also limit additional interfaces.
Once the securelevel value is increased, it may not be decreased.
I'm not sure the securelevel is equal to secore boot enforcing mode. I'd like to hear what Peter's opinion about this.
Also in my F19 virtual machine there's no such interface, probably it's RHEL7 only
Thanks Dave
On 02/07/14 at 05:19pm, Dave Young wrote:
On 02/07/14 at 05:06pm, WANG Chao wrote:
On 02/07/14 at 04:32pm, Dave Young wrote:
Kdump does not support secure boot yet, so let's claim it is not supported at the begginning of service start function.
In this patch for checking secure boot status I'm checking the efivars per suggestion from pjones. see in code comments for the details.
Why you didn't use /sys/kernel/security/securelevel interface?
From http://git.app.eng.bos.redhat.com/rhel7.git/tree/Documentation/security/secu..., it says:
Linux securelevel interface
The Linux securelevel interface (inspired by the BSD securelevel interface) is a runtime mechanism for configuring coarse-grained kernel-level security restrictions. It provides a runtime configuration variable at /sys/kernel/security/securelevel which can be written to by root. The following values are supported:
-1: Permanently insecure mode. This level is equivalent to level 0, but once set cannot be changed.
0: Insecure mode (default). This level imposes no additional kernel restrictions.
1: Secure mode. If set, userspace will be unable to perform direct access to PCI devices, port IO access, access system memory directly via /dev/mem and /dev/kmem, perform kexec_load(), use the userspace software suspend mechanism, insert new ACPI code at runtime via the custom_method interface or modify CPU MSRs (on x86). Certain drivers may also limit additional interfaces.
Once the securelevel value is increased, it may not be decreased.
I'm not sure the securelevel is equal to secore boot enforcing mode. I'd like to hear what Peter's opinion about this.
Sure. Peter, could you please explain your opinion a little bit?
Also in my F19 virtual machine there's no such interface, probably it's RHEL7 only
This secure boot patch is backported from Fedora. Maybe F20 has it and F19 doesn't because f19 is no longer under development...
On Fri, Feb 07, 2014 at 05:26:49PM +0800, WANG Chao wrote:
On 02/07/14 at 05:19pm, Dave Young wrote:
On 02/07/14 at 05:06pm, WANG Chao wrote:
On 02/07/14 at 04:32pm, Dave Young wrote:
Kdump does not support secure boot yet, so let's claim it is not supported at the begginning of service start function.
In this patch for checking secure boot status I'm checking the efivars per suggestion from pjones. see in code comments for the details.
Why you didn't use /sys/kernel/security/securelevel interface?
From http://git.app.eng.bos.redhat.com/rhel7.git/tree/Documentation/security/secu..., it says:
Linux securelevel interface
The Linux securelevel interface (inspired by the BSD securelevel interface) is a runtime mechanism for configuring coarse-grained kernel-level security restrictions. It provides a runtime configuration variable at /sys/kernel/security/securelevel which can be written to by root. The following values are supported:
-1: Permanently insecure mode. This level is equivalent to level 0, but once set cannot be changed.
0: Insecure mode (default). This level imposes no additional kernel restrictions.
1: Secure mode. If set, userspace will be unable to perform direct access to PCI devices, port IO access, access system memory directly via /dev/mem and /dev/kmem, perform kexec_load(), use the userspace software suspend mechanism, insert new ACPI code at runtime via the custom_method interface or modify CPU MSRs (on x86). Certain drivers may also limit additional interfaces.
Once the securelevel value is increased, it may not be decreased.
I'm not sure the securelevel is equal to secore boot enforcing mode. I'd like to hear what Peter's opinion about this.
Sure. Peter, could you please explain your opinion a little bit?
Well, it isn't upstream yet, and it doesn't appear to be what's finally going to go upstream. So at least for now, we probably shouldn't depend on it, since we know it's going to change.
The efivars method should continue to work even after this stabilizes.
On 02/07/14 at 10:21am, Peter Jones wrote:
On Fri, Feb 07, 2014 at 05:26:49PM +0800, WANG Chao wrote:
On 02/07/14 at 05:19pm, Dave Young wrote:
On 02/07/14 at 05:06pm, WANG Chao wrote:
On 02/07/14 at 04:32pm, Dave Young wrote:
Kdump does not support secure boot yet, so let's claim it is not supported at the begginning of service start function.
In this patch for checking secure boot status I'm checking the efivars per suggestion from pjones. see in code comments for the details.
Why you didn't use /sys/kernel/security/securelevel interface?
From http://git.app.eng.bos.redhat.com/rhel7.git/tree/Documentation/security/secu..., it says:
Linux securelevel interface
The Linux securelevel interface (inspired by the BSD securelevel interface) is a runtime mechanism for configuring coarse-grained kernel-level security restrictions. It provides a runtime configuration variable at /sys/kernel/security/securelevel which can be written to by root. The following values are supported:
-1: Permanently insecure mode. This level is equivalent to level 0, but once set cannot be changed.
0: Insecure mode (default). This level imposes no additional kernel restrictions.
1: Secure mode. If set, userspace will be unable to perform direct access to PCI devices, port IO access, access system memory directly via /dev/mem and /dev/kmem, perform kexec_load(), use the userspace software suspend mechanism, insert new ACPI code at runtime via the custom_method interface or modify CPU MSRs (on x86). Certain drivers may also limit additional interfaces.
Once the securelevel value is increased, it may not be decreased.
I'm not sure the securelevel is equal to secore boot enforcing mode. I'd like to hear what Peter's opinion about this.
Sure. Peter, could you please explain your opinion a little bit?
Well, it isn't upstream yet, and it doesn't appear to be what's finally going to go upstream. So at least for now, we probably shouldn't depend on it, since we know it's going to change.
The efivars method should continue to work even after this stabilizes.
Thanks for your clarification, if this method is some kind of kernel ABI, I agree that we use it.
On Fri, Feb 07, 2014 at 05:06:28PM +0800, WANG Chao wrote:
On 02/07/14 at 04:32pm, Dave Young wrote:
Kdump does not support secure boot yet, so let's claim it is not supported at the begginning of service start function.
In this patch for checking secure boot status I'm checking the efivars per suggestion from pjones. see in code comments for the details.
Why you didn't use /sys/kernel/security/securelevel interface?
In plumbers conference, Linus did not like the idea of securelevels either and it it is not upstream. So I would prefer not to rely on securelevel interface.
Secondly, a better place to check secureboot status might be status() function. There we are already making other checks.
Also I think status() probably broken in two functions. Say check_kdump_feasibility() and check_current_kdump_status().
First function will check whether it is possible to run kdump on this machine or not. There we could check for presence of /sys/kernel/kexec_crash_loaded as well as secureboot enabled check.
Second function could check the current status of kdump.
Thanks Vivek
Removing Peter from cc as for kdump only discussing.
On 02/07/14 at 10:24am, Vivek Goyal wrote:
On Fri, Feb 07, 2014 at 05:06:28PM +0800, WANG Chao wrote:
On 02/07/14 at 04:32pm, Dave Young wrote:
Kdump does not support secure boot yet, so let's claim it is not supported at the begginning of service start function.
In this patch for checking secure boot status I'm checking the efivars per suggestion from pjones. see in code comments for the details.
Why you didn't use /sys/kernel/security/securelevel interface?
In plumbers conference, Linus did not like the idea of securelevels either and it it is not upstream. So I would prefer not to rely on securelevel interface.
Secondly, a better place to check secureboot status might be status() function. There we are already making other checks.
Also I think status() probably broken in two functions. Say check_kdump_feasibility() and check_current_kdump_status().
First function will check whether it is possible to run kdump on this machine or not. There we could check for presence of /sys/kernel/kexec_crash_loaded as well as secureboot enabled check.
Second function could check the current status of kdump.
Vivek, Do you want kdump start() return success even if secure boot is on? I think kdump start should fail instead as what I do in the patch.
Thanks Dave
On Sat, Feb 08, 2014 at 08:02:01AM +0800, Dave Young wrote:
Removing Peter from cc as for kdump only discussing.
On 02/07/14 at 10:24am, Vivek Goyal wrote:
On Fri, Feb 07, 2014 at 05:06:28PM +0800, WANG Chao wrote:
On 02/07/14 at 04:32pm, Dave Young wrote:
Kdump does not support secure boot yet, so let's claim it is not supported at the begginning of service start function.
In this patch for checking secure boot status I'm checking the efivars per suggestion from pjones. see in code comments for the details.
Why you didn't use /sys/kernel/security/securelevel interface?
In plumbers conference, Linus did not like the idea of securelevels either and it it is not upstream. So I would prefer not to rely on securelevel interface.
Secondly, a better place to check secureboot status might be status() function. There we are already making other checks.
Also I think status() probably broken in two functions. Say check_kdump_feasibility() and check_current_kdump_status().
First function will check whether it is possible to run kdump on this machine or not. There we could check for presence of /sys/kernel/kexec_crash_loaded as well as secureboot enabled check.
Second function could check the current status of kdump.
Vivek, Do you want kdump start() return success even if secure boot is on? I think kdump start should fail instead as what I do in the patch.
No, I just want to organize the code better without changing existing behavior.
start() { check_config save raw -- check_kdump_feasibility() check_current_kdump_status() }
Secureboot and presence of kexec_crash_loaded can go inside check_kdump_feasibility() function and return failure if it is not feasible to start kdump on this machine.
Thanks Vivek
On 02/10/14 at 11:22am, Vivek Goyal wrote:
On Sat, Feb 08, 2014 at 08:02:01AM +0800, Dave Young wrote:
Removing Peter from cc as for kdump only discussing.
On 02/07/14 at 10:24am, Vivek Goyal wrote:
On Fri, Feb 07, 2014 at 05:06:28PM +0800, WANG Chao wrote:
On 02/07/14 at 04:32pm, Dave Young wrote:
Kdump does not support secure boot yet, so let's claim it is not supported at the begginning of service start function.
In this patch for checking secure boot status I'm checking the efivars per suggestion from pjones. see in code comments for the details.
Why you didn't use /sys/kernel/security/securelevel interface?
In plumbers conference, Linus did not like the idea of securelevels either and it it is not upstream. So I would prefer not to rely on securelevel interface.
Secondly, a better place to check secureboot status might be status() function. There we are already making other checks.
Also I think status() probably broken in two functions. Say check_kdump_feasibility() and check_current_kdump_status().
First function will check whether it is possible to run kdump on this machine or not. There we could check for presence of /sys/kernel/kexec_crash_loaded as well as secureboot enabled check.
Second function could check the current status of kdump.
Vivek, Do you want kdump start() return success even if secure boot is on? I think kdump start should fail instead as what I do in the patch.
No, I just want to organize the code better without changing existing behavior.
start() { check_config save raw -- check_kdump_feasibility() check_current_kdump_status() }
Secureboot and presence of kexec_crash_loaded can go inside check_kdump_feasibility() function and return failure if it is not feasible to start kdump on this machine.
Thanks for explanation. I have sent the new patches..
Thanks Dave
-
Dave Young -
Peter Jones -
Vivek Goyal -
WANG Chao