From mboxrd@z Thu Jan 1 00:00:00 1970 From: jikos@kernel.org (Jiri Kosina) Date: Fri, 10 Nov 2017 11:15:56 +0100 (CET) Subject: [PATCH 26/30] Lock down ftrace In-Reply-To: <27323.1510308432@warthog.procyon.org.uk> References: <151024863544.28329.2436580122759221600.stgit@warthog.procyon.org.uk> <151024883613.28329.14808632296386937974.stgit@warthog.procyon.org.uk> <27323.1510308432@warthog.procyon.org.uk> Message-ID: To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org On Fri, 10 Nov 2017, David Howells wrote: > > I fail to see how this fits into the secure boot security model, could you > > please explain? > > The idea is to prevent cryptographic data for filesystems and other things > from being read out of the kernel memory as well as to prevent unauthorised > modification of kernel memory. Then it would make sense to actually lock down dumping of registers / function arguments (kprobes can currently do that, ftrace eventually could as well I guess), but disabling the whole ftrace altogether seems like a totally unnecessary overkill. > > Secure boot is about having a constant proof / verification that the code > > you're running in ring0 can be trusted (IOW is the one that has been > > signed and verified by the whole boot chain). > > > > Checking execution patterns doesn't seem to fit at all. > > I'll defer this question to Alexei since he suggested I needed to deal > with this too. Thanks. -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html