linux-efi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lenny Szubowicz <lszubowi@redhat.com>
To: Arvind Sankar <nivedita@alum.mit.edu>, Ard Biesheuvel <ardb@kernel.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-efi <linux-efi@vger.kernel.org>,
	platform-driver-x86@vger.kernel.org,
	linux-security-module@vger.kernel.org, andy.shevchenko@gmail.com,
	James Morris <jmorris@namei.org>,
	serge@hallyn.com, Kees Cook <keescook@chromium.org>,
	Mimi Zohar <zohar@linux.ibm.com>, Borislav Petkov <bp@alien8.de>,
	Peter Jones <pjones@redhat.com>,
	David Howells <dhowells@redhat.com>,
	prarit@redhat.com
Subject: Re: [PATCH V2 1/3] efi: Support for MOK variable config table
Date: Thu, 24 Sep 2020 15:09:36 -0400	[thread overview]
Message-ID: <e01b3f50-20ee-0168-b6ee-4d3d2d4dc13f@redhat.com> (raw)
In-Reply-To: <20200921165506.GA549786@rani.riverdale.lan>

On 9/21/20 12:55 PM, Arvind Sankar wrote:
> On Mon, Sep 21, 2020 at 06:27:17PM +0200, Ard Biesheuvel wrote:
>> On Mon, 21 Sep 2020 at 18:19, Arvind Sankar <nivedita@alum.mit.edu> wrote:
>>>
>>> On Fri, Sep 04, 2020 at 09:31:05PM -0400, Lenny Szubowicz wrote:
>>>> +     /*
>>>> +      * The EFI MOK config table must fit within a single EFI memory
>>>> +      * descriptor range.
>>>> +      */
>>>> +     err = efi_mem_desc_lookup(efi.mokvar_table, &md);
>>>> +     if (err) {
>>>> +             pr_warn("EFI MOKvar config table is not within the EFI memory map\n");
>>>> +             return;
>>>> +     }
>>>> +     end_pa = efi_mem_desc_end(&md);
>>>> +     if (efi.mokvar_table >= end_pa) {
>>>> +             pr_err("EFI memory descriptor containing MOKvar config table is invalid\n");
>>>> +             return;
>>>> +     }
>>>
>>> efi_mem_desc_lookup() can't return success if efi.mokvar_table >= end_pa,
>>> why check it again?

I agree it's unnecessary and I see that Ard has addressed this in a patch.

>>>
>>>> +     offset_limit = end_pa - efi.mokvar_table;
>>>> +     /*
>>>> +      * Validate the MOK config table. Since there is no table header
>>>> +      * from which we could get the total size of the MOK config table,
>>>> +      * we compute the total size as we validate each variably sized
>>>> +      * entry, remapping as necessary.
>>>> +      */
>>>> +     while (cur_offset + sizeof(*mokvar_entry) <= offset_limit) {
>>>> +             mokvar_entry = va + cur_offset;
>>>> +             map_size_needed = cur_offset + sizeof(*mokvar_entry);
>>>> +             if (map_size_needed > map_size) {
>>>> +                     if (va)
>>>> +                             early_memunmap(va, map_size);
>>>> +                     /*
>>>> +                      * Map a little more than the fixed size entry
>>>> +                      * header, anticipating some data. It's safe to
>>>> +                      * do so as long as we stay within current memory
>>>> +                      * descriptor.
>>>> +                      */
>>>> +                     map_size = min(map_size_needed + 2*EFI_PAGE_SIZE,
>>>> +                                    offset_limit);
>>>> +                     va = early_memremap(efi.mokvar_table, map_size);
>>>
>>> Can't we just map the entire region from efi.mokvar_table to end_pa in
>>> one early_memremap call before the loop and avoid all the remapping
>>> logic?
>>>
>>
>> I suppose that depends on whether there is a reasonable upper bound on
>> the size which is guaranteed to be mappable using early_memremap()
>> (e.g., 128 KB on 32-bit ARM, or 256 KB on other architectures)
> 
> Ah, sorry, I thought only the number of early mappings was limited, not
> the size as well. We could still just map the maximum possible
> (NR_FIX_BTMAPS * PAGE_SIZE), since it will fail anyway if the config
> table turns out to be bigger than that?

In practice, the loop will only do one or two mappings. That's because of
two factors.

First the code attempts to map a little more than it needs (2*EFI_PAGE_SIZE).
Secondly, right now only one entry in the MOKvar config table might be quite
large, i.e. the entry named MoKListRT. It's extremely likely that the header
of MokListRT entry will be encountered on the first mapping. If that entry
goes beyond what was originally mapped, then a second mapping will cover all
the data in that large entry as well as the remaining small entries that might
follow it.

> 
>>
>>
>>>> +     if (va)
>>>> +             early_memunmap(va, map_size);
>>>> +     if (err) {
>>>> +             pr_err("EFI MOKvar config table is not valid\n");
>>>> +             return;
>>>> +     }
>>>
>>> err will never be non-zero here: it was cleared when the
>>> efi_mem_desc_lookup() was done. I think the initialization of err to
>>> -EINVAL needs to be moved just prior to the loop.
>>>
>>>> +     efi_mem_reserve(efi.mokvar_table, map_size_needed);
>>>> +     efi_mokvar_table_size = map_size_needed;
>>>> +}
> 


  reply	other threads:[~2020-09-24 19:09 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-05  1:31 [PATCH V2 0/3] integrity: Load certs from EFI MOK config table Lenny Szubowicz
2020-09-05  1:31 ` [PATCH V2 1/3] efi: Support for MOK variable " Lenny Szubowicz
2020-09-21 16:18   ` Arvind Sankar
2020-09-21 16:27     ` Ard Biesheuvel
2020-09-21 16:55       ` Arvind Sankar
2020-09-24 19:09         ` Lenny Szubowicz [this message]
2020-10-01 17:44   ` Nathan Chancellor
2020-10-01 20:57     ` Ard Biesheuvel
2020-10-01 21:07       ` Nathan Chancellor
2020-09-05  1:31 ` [PATCH V2 2/3] integrity: Move import of MokListRT certs to a separate routine Lenny Szubowicz
2020-09-11 15:02   ` Ard Biesheuvel
2020-09-11 15:54     ` Lenny Szubowicz
2020-09-11 15:59       ` Mimi Zohar
2020-09-11 17:18         ` Lenny Szubowicz
2020-09-11 18:16           ` Ard Biesheuvel
2020-09-11 19:08             ` Mimi Zohar
2020-09-11 19:46               ` Lenny Szubowicz
2020-09-05  1:31 ` [PATCH V2 3/3] integrity: Load certs from the EFI MOK config table Lenny Szubowicz
2020-09-11 15:17 ` [PATCH V2 0/3] integrity: Load certs from " Ard Biesheuvel
2020-09-11 16:01   ` Mimi Zohar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e01b3f50-20ee-0168-b6ee-4d3d2d4dc13f@redhat.com \
    --to=lszubowi@redhat.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=ardb@kernel.org \
    --cc=bp@alien8.de \
    --cc=dhowells@redhat.com \
    --cc=jmorris@namei.org \
    --cc=keescook@chromium.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=nivedita@alum.mit.edu \
    --cc=pjones@redhat.com \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=prarit@redhat.com \
    --cc=serge@hallyn.com \
    --cc=zohar@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).