All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.