From mboxrd@z Thu Jan 1 00:00:00 1970 From: torvalds@linux-foundation.org (Linus Torvalds) Date: Tue, 3 Apr 2018 15:46:11 -0700 Subject: [GIT PULL] Kernel lockdown for secure boot In-Reply-To: References: <4136.1522452584@warthog.procyon.org.uk> <186aeb7e-1225-4bb8-3ff5-863a1cde86de@kernel.org> <30459.1522739219@warthog.procyon.org.uk> <9758.1522775763@warthog.procyon.org.uk> <13189.1522784944@warthog.procyon.org.uk> <9349.1522794769@warthog.procyon.org.uk> Message-ID: To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org On Tue, Apr 3, 2018 at 3:39 PM, Andy Lutomirski wrote: > > Sure. I have no problem with having an upstream kernel have a > lockdown feature, although I think that feature should distinguish > between reads and writes. But I don't think the upstream kernel > should apply a patch that ties any of this to Secure Boot without a > genuine technical reason why it makes sense. So this is where I violently agree with Andy. For example, I love signed kernel modules. The fact that I love them has absolutely zero to do with secure boot, though. There is absolutely no linkage between the two issues: I use (self-)signed kernel modules simply because I think it's a good thing in general. The same thing is true of some lockdown patch. Maybe it's a good thing in general. But whether it's a good thing is _entirely_ independent of any secure boot issue. I can see using secure boot without it, but I can very much also see using lockdown without secure boot. The two things are simply entirely orthogonal. They have _zero_ overlap. I'm not seeing why they'd be linked at all in any way. Linus -- 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