Ethan Zhao <ethan.kernel@xxxxxxxxx> wrote:
> May I ask a question here -- Is it intentionally enabling the
> read-only mode, so userspace
> tools like dmidecode could work with kernel_is_locked_down ? while it
> was impossible to work
> with the attached patch applied. Is it a security policy change with
> secure boot ?
I removed readability on /dev/mem, /dev/kmem and /proc/kcore so that userspace
can't use this to gain access to cryptographic material in use by the kernel.
Readability was removed on /dev/port because reading from an I/O port register
might have a side effect or might allow you to snoop h/w interactions, such as
keyboard input.
I can provide an additional config option to allow /dev/mem and similar to
remain readable - but it needs to be a temporary affair.
I can also log accesses to these interfaces so that we can find out what
breaks and fix it.
Note that dmidecode doesn't necessarily use /dev/mem:
[root@andromeda ~]# strace -f -eopen dmidecode >/dev/null
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/sys/firmware/dmi/tables/smbios_entry_point", O_RDONLY) = 3
open("/sys/firmware/dmi/tables/DMI", O_RDONLY) = 3
+++ exited with 0 +++
Indeed, my Fedora 24 test system boots without a /dev/mem file being present
(I'm not sure *why* /dev/mem isn't present, but I hadn't noticed till now).
David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
