From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 8C1CAD6F for ; Thu, 6 Sep 2018 10:01:11 +0000 (UTC) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3336E713 for ; Thu, 6 Sep 2018 10:01:11 +0000 (UTC) From: Jani Nikula To: Andy Lutomirski , Justin Forbes In-Reply-To: References: <17533.1536166384@warthog.procyon.org.uk> <32341.1536178494@warthog.procyon.org.uk> Date: Thu, 06 Sep 2018 13:00:36 +0300 Message-ID: <87y3cfymgr.fsf@intel.com> MIME-Version: 1.0 Content-Type: text/plain Cc: James Bottomley , Peter Jones , joeyli.kernel@gmail.com, ksummit-discuss@lists.linuxfoundation.org Subject: Re: [Ksummit-discuss] [TECH TOPIC] Kernel lockdown and secure boot List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Wed, 05 Sep 2018, Andy Lutomirski wrote: > 2. What exactly does lockdown do? > > #2 is a bigger deal. At least one version that shipped in a Fedora > kernel actually broke systemd, and that's not cool. And I really > think we need to make lockdown non-binary to get this right. I've > proposed LOCKDOWN_PROTECT_INTEGRITY (i.e. try to prevent root from > modifying the running kernel) and LOCKDOWN_PROTECT_SECRECY (try to > prevent root from reading kernel memory), and no one seems to have > actually objected. Clueless bystander comment: I spent a while debugging a bug reporter's -EPERM issue on direct PCI bar access. Took me a while to realize this was caused by kernel lockdown on the user's distro. I expect more issues like this to pop up as the use of lockdown proliferates, and I don't think it's necessarily obvious when lockdown changes behaviour. I guess I'm asking, have you considered an audit log for lockdown blocked access, and if you've rejected the idea, why? BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center