Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <47ae05f8d3a67ee5e1607ab8e718cc4b3e95cebb.camel@HansenPartnership.com>
Subject: Re: [PATCH v8 16/17] integrity: Trust MOK keys if MokListTrustedRT
 found
From:   James Bottomley <James.Bottomley@HansenPartnership.com>
To:     Morten Linderud <morten@linderud.pw>,
        Eric Snowberg <eric.snowberg@oracle.com>
Cc:     "keyrings@vger.kernel.org" <keyrings@vger.kernel.org>,
        "linux-integrity@vger.kernel.org" <linux-integrity@vger.kernel.org>,
        Mimi Zohar <zohar@linux.ibm.com>,
        David Howells <dhowells@redhat.com>,
        David Woodhouse <dwmw2@infradead.org>,
        "herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
        "davem@davemloft.net" <davem@davemloft.net>,
        Jarkko Sakkinen <jarkko@kernel.org>,
        "jmorris@namei.org" <jmorris@namei.org>,
        "serge@hallyn.com" <serge@hallyn.com>,
        "keescook@chromium.org" <keescook@chromium.org>,
        "torvalds@linux-foundation.org" <torvalds@linux-foundation.org>,
        "weiyongjun1@huawei.com" <weiyongjun1@huawei.com>,
        Nayna Jain <nayna@linux.ibm.com>,
        Eric Biggers <ebiggers@google.com>,
        "ardb@kernel.org" <ardb@kernel.org>,
        Lakshmi Ramasubramanian <nramas@linux.microsoft.com>,
        "lszubowi@redhat.com" <lszubowi@redhat.com>,
        "jason@zx2c4.com" <jason@zx2c4.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
        "linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>,
        "linux-security-module@vger.kernel.org" 
        <linux-security-module@vger.kernel.org>,
        "pjones@redhat.com" <pjones@redhat.com>,
        Konrad Wilk <konrad.wilk@oracle.com>
Date:   Thu, 10 Nov 2022 10:27:24 -0500
In-Reply-To: <20221110150607.h4iaymkgc4f7kuue@framework>
References: <20211124044124.998170-1-eric.snowberg@oracle.com>
         <20211124044124.998170-17-eric.snowberg@oracle.com>
         <20221110000129.kl6pjy5mafpuptbk@framework>
         <4A479B96-4B41-4323-9920-5A909423F998@oracle.com>
         <20221110150607.h4iaymkgc4f7kuue@framework>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.42.4 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Thu, 2022-11-10 at 16:06 +0100, Morten Linderud wrote:
> I'm not really sure what Peter means with "much more reliable"
> though.

It's that in-head knowledge you referred to.  You can't see the true
MoK variables because they're BootServices, meaning they're not visible
in the RunTime, which is why the shadow RT variables exist (this is a
security property: BS only variables can only be altered by trusted,
signed entities).  However lots of things can create RT variables so
you have to run through a sequence of checks on the RT shadows to try
to defeat clever attackers (like verifying the variable attributes),
because the chain of custody from BS to RT is not guaranteed.  If you
use a configuration table instead, that is BS only, the kernel (which
is also a trusted entity) has to pick it out before ExitBootServices,
so if the kernel has the table, you have a reliable chain of custody
for the entries.

James