Re: [PATCH v2] kdumpctl: claim that kdump does not support secure boot when service start

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/s..., > > 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?