linux-efi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
To: Peter Jones <pjones-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH] efi: Add esrt support.
Date: Thu, 15 Jan 2015 21:25:55 +0000	[thread overview]
Message-ID: <20150115212555.GC12079@codeblueprint.co.uk> (raw)
In-Reply-To: <1421070174-27513-1-git-send-email-pjones-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

On Mon, 12 Jan, at 08:42:54AM, Peter Jones wrote:
> Add sysfs files for the EFI System Resource Table (ESRT) under
> /sys/firmware/efi/esrt and for each EFI System Resource Entry under
> entries/ as a subdir.
> 
> The EFI System Resource Table (ESRT) provides a read-only catalog of
> system components for which the system accepts firmware upgrades via
> UEFI's "Capsule Update" feature.  This module allows userland utilities
> to evaluate what firmware updates can be applied to this system, and
> potentially arrange for those updates to occur.
> 
> The ESRT is described as part of the UEFI specification, in version 2.5
> which should be available from http://uefi.org/specifications in early
> 2015.  If you're a member of the UEFI Forum, information about its
> addition to the standard is available as UEFI Mantis 1090.
> 
> For some hardware platforms, additional restrictions may be found at
> http://msdn.microsoft.com/en-us/library/windows/hardware/jj128256.aspx ,
> and additional documentation may be found at
> http://download.microsoft.com/download/5/F/5/5F5D16CD-2530-4289-8019-94C6A20BED3C/windows-uefi-firmware-update-platform.docx
> .
> 
> Signed-off-by: Peter Jones <pjones-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
>  drivers/firmware/efi/Makefile |   2 +-
>  drivers/firmware/efi/efi.c    |  63 ++++++-
>  drivers/firmware/efi/esrt.c   | 402 ++++++++++++++++++++++++++++++++++++++++++
>  include/linux/efi.h           |   7 +
>  4 files changed, 472 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/firmware/efi/esrt.c

[...]

> +/*
> + * ioremap the table, copy it to kmalloced pages, and unmap it.
> + */
> +static int esrt_duplicate_pages(void)
> +{
> +	struct efi_system_resource_table *tmpesrt;
> +	struct efi_system_resource_entry *entries;
> +	size_t size, max;
> +	efi_memory_desc_t md;
> +	int err = -EINVAL;
> +	int rc;
> +
> +	if (!esrt_table_exists())
> +		return err;
> +
> +	rc = efi_mem_desc_lookup(efi.esrt, &md);
> +	if (rc < 0) {
> +		pr_err("ESRT header is not in the memory map.\n");
> +		return err;

Probably wanna return 'rc' here? Since efi_mem_desc_lookup() now may
return -ENOENT or -EINVAL on failure.

> +	}
> +
> +	max = efi_mem_desc_end(&md);
> +	if (max < 0) {
> +		pr_err("EFI memory descriptor is invalid.\n");
> +		return err;
> +	}
> +
> +	size = sizeof(*esrt);
> +
> +	if (max < size) {
> +		pr_err("ESRT header doen't fit on single memory map entry.\n");
> +		return err;
> +	}

This doesn't look right. You're comparing an address 'max' and a size
'size'. Unless we have memory descriptors at address 0x0, this condition
will never be false.

> +
> +	tmpesrt = ioremap(efi.esrt, size);
> +	if (!tmpesrt) {
> +		pr_err("ioremap failed.\n");
> +		return -ENOMEM;
> +	}
> +
> +	if (tmpesrt->fw_resource_count > 0 && max - size < sizeof(*entries)) {
> +		pr_err("ESRT memory map entry can only hold the header.\n");
> +		goto err_iounmap;
> +	}

Ditto. Is this ever going to be false?

> +	/*
> +	 * The format doesn't really give us any boundary to test here,
> +	 * so I'm making up 128 as the max number of individually updatable
> +	 * components we support.
> +	 * 128 should be pretty excessive, but there's still some chance
> +	 * somebody will do that someday and we'll need to raise this.
> +	 */
> +	if (tmpesrt->fw_resource_count > 128) {
> +		pr_err("ESRT says fw_resource_count has very large value %d.\n",
> +		       tmpesrt->fw_resource_count);
> +		goto err_iounmap;
> +	}
> +
> +	/*
> +	 * We know it can't be larger than N * sizeof() here, and N is limited
> +	 * by the previous test to a small number, so there's no overflow.
> +	 */
> +	size += tmpesrt->fw_resource_count * sizeof(*entries);
> +	if (max < size) {
> +		pr_err("ESRT does not fit on single memory map entry.\n");
> +		goto err_iounmap;
> +	}

Ditto^2

> +	esrt = kmalloc(size, GFP_KERNEL);
> +	if (!esrt) {
> +		err = -ENOMEM;
> +		goto err_iounmap;
> +	}
> +
> +	memcpy(esrt, tmpesrt, size);
> +	err = 0;
> +err_iounmap:
> +	iounmap(tmpesrt);
> +	return err;
> +}
> +
> +static int register_entries(void)
> +{
> +	struct efi_system_resource_entry *entries = esrt->entries;
> +	int i, rc;
> +
> +	if (!esrt_table_exists())
> +		return 0;
> +
> +	for (i = 0; i < le32_to_cpu(esrt->fw_resource_count); i++) {

This caught my eye. Do any of the architectures with UEFI support
running in big endian mode?

-- 
Matt Fleming, Intel Open Source Technology Center

  parent reply	other threads:[~2015-01-15 21:25 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-09 19:19 [PATCH] efi: Add esrt support Peter Jones
     [not found] ` <1420831159-17285-1-git-send-email-pjones-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-01-12 13:03   ` Matt Fleming
     [not found]     ` <20150112130332.GG26589-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
2015-01-12 13:42       ` Peter Jones
     [not found]         ` <1421070174-27513-1-git-send-email-pjones-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-01-15 21:25           ` Matt Fleming [this message]
     [not found]             ` <20150115212555.GC12079-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
2015-01-20 16:21               ` Peter Jones
2015-01-20 16:24               ` Peter Jones
  -- strict thread matches above, loose matches on Subject: below --
2015-02-19 14:54 Peter Jones
     [not found] ` <1424357660-13733-1-git-send-email-pjones-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-02-26  8:00   ` Dave Young
     [not found]     ` <20150226080033.GB6207-4/PLUo9XfK/1wF9wiOj0lkEOCMrvLtNR@public.gmane.org>
2015-02-26 14:37       ` Peter Jones
2015-04-28 22:44 ESRT support Peter Jones
     [not found] ` <1430261071-14005-1-git-send-email-pjones-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-04-28 22:44   ` [PATCH] efi: Add esrt support Peter Jones
     [not found]     ` <1430261071-14005-2-git-send-email-pjones-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-04-30 10:42       ` Matt Fleming

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=20150115212555.GC12079@codeblueprint.co.uk \
    --to=matt-mf/unelci9gs6ibeejttw/xrex20p6io@public.gmane.org \
    --cc=linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=pjones-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    /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).