Small nit. On Fri, 2015-12-18 at 20:13 +0800, Kweh, Hock Leong wrote: > From: "Kweh, Hock Leong" <hock.leong.k...@intel.com> > > Introducing a kernel module to expose capsule loader interface > (misc char device file note) for user to upload capsule binaries.
This patch ? introduces a kernel module to expose a capsule loader interface... for a user ... > > Example method to load the capsule binary: Example: > cat firmware.bin > /dev/efi_capsule_loader > > This patch also export efi_capsule_supported() function symbol for > verifying the submitted capsule header in this kernel module. 1. Should be a separate patch 2. Suggested, rewording for that patch log 2/2 Title This patch exports efi_capsule_supported to enable verification of the capsule header. That said - who is the user of this symbol ? Why is it needed ? Anyway please consider splitting and rewording. > > Cc: Matt Fleming <m...@codeblueprint.co.uk> > Signed-off-by: Kweh, Hock Leong <hock.leong.k...@intel.com> > --- > drivers/firmware/efi/Kconfig | 10 > drivers/firmware/efi/Makefile | 1 > drivers/firmware/efi/capsule-loader.c | 355 > +++++++++++++++++++++++++++++++++ > drivers/firmware/efi/capsule.c | 1 > 4 files changed, 367 insertions(+) > create mode 100644 drivers/firmware/efi/capsule-loader.c > > diff --git a/drivers/firmware/efi/Kconfig > b/drivers/firmware/efi/Kconfig > index e1670d5..dc2a912 100644 > --- a/drivers/firmware/efi/Kconfig > +++ b/drivers/firmware/efi/Kconfig > @@ -87,6 +87,16 @@ config EFI_RUNTIME_WRAPPERS > config EFI_ARMSTUB > bool > > +config EFI_CAPSULE_LOADER > + tristate "EFI capsule loader" > + depends on EFI > + help > + This option exposes a loader interface > "/dev/efi_capsule_loader" for > + user to load EFI capsule binary and update the EFI > firmware. After > + a successful loading, a system reboot is required. > + > + If unsure, say N. > + This option exposes a loader interface... for a user to load an EFI capsule. A capsule isn't necessarily exclusively for updating of firmware either AFAIK - so I suggest dropping. http://www.intel.com/content/www/us/en/architecture-and-technology/unif ied-extensible-firmware-interface/efi-capsule-specification.html Quote "Capsules were designed for and are intended to be the major vehicle for delivering firmware volume changes. There is no requirement that capsules be limited to that function." > endmenu > > config UEFI_CPER > diff --git a/drivers/firmware/efi/Makefile > b/drivers/firmware/efi/Makefile > index fabf801..cf9d9d3 100644 > --- a/drivers/firmware/efi/Makefile > +++ b/drivers/firmware/efi/Makefile > @@ -18,3 +18,4 @@ obj-$(CONFIG_EFI_RUNTIME_MAP) += > runtime-map.o > obj-$(CONFIG_EFI_RUNTIME_WRAPPERS) += runtime-wrappers.o > obj-$(CONFIG_EFI_STUB) += libstub/ > obj-$(CONFIG_EFI_FAKE_MEMMAP) += fake_mem.o > +obj-$(CONFIG_EFI_CAPSULE_LOADER) += capsule-loader.o > diff --git a/drivers/firmware/efi/capsule-loader.c > b/drivers/firmware/efi/capsule-loader.c > new file mode 100644 > index 0000000..e1214bb > --- /dev/null > +++ b/drivers/firmware/efi/capsule-loader.c > @@ -0,0 +1,355 @@ > +/* > + * EFI capsule loader driver. > + * > + * Copyright 2015 Intel Corporation > + * > + * This file is part of the Linux kernel, and is made available > under > + * the terms of the GNU General Public License version 2. > + */ > + > +#define pr_fmt(fmt) "EFI: " fmt > + > +#include <linux/kernel.h> > +#include <linux/module.h> > +#include <linux/miscdevice.h> > +#include <linux/highmem.h> > +#include <linux/slab.h> > +#include <linux/mutex.h> > +#include <linux/efi.h> > + > +#define NO_FURTHER_WRITE_ACTION -1 > + > +struct capsule_info { > + bool header_obtained; > + int reset_type; > + long index; > + size_t count; > + size_t total_size; > + struct page **pages; > + size_t page_bytes_remain; > +}; > + > +static DEFINE_MUTEX(capsule_loader_lock); > + > +/** > + * efi_free_all_buff_pages - free all previous allocated buffer > pages > + * @cap_info: pointer to current instance of capsule_info structure > + * > + * Besides freeing the buffer pages, it also flagged an > + * NO_FURTHER_WRITE_ACTION flag for indicating to the next > write entries > + * that there is a flaw happened and any subsequence actions > are not > + * valid unless close(2). > + **/ The description needs to be reworded. In addition to freeing buffer pages, we flag NO_FURTHER_WRITE_ACTION on error and will cease to process data in subsequent efi_capsule_write() calls. (or similar) > +static void efi_free_all_buff_pages(struct capsule_info *cap_info) > +{ > + while (cap_info->index > 0) > + __free_page(cap_info->pages[--cap_info->index]); > + > + kfree(cap_info->pages); > + > + cap_info->index = NO_FURTHER_WRITE_ACTION; > +} > + > +/** > + * efi_capsule_setup_info - to obtain the efi capsule header in the > binary and > + * setup capsule_info structure > + * @cap_info: pointer to current instance of capsule_info structure > + * @kbuff: a mapped 1st page buffer pointer first not 1st > + * @hdr_bytes: the total bytes of received efi header the total number of received bytes of the EFI header > + **/ > +static ssize_t efi_capsule_setup_info(struct capsule_info *cap_info, > + void *kbuff, size_t hdr_bytes) > +{ > + int ret; > + void *temp_page; > + > + /* Handling 1st block is less than header size */ first or initial I think you mean to say "Ensure first > + > + /* Check if the capsule binary supported */ > + mutex_lock(&capsule_loader_lock); > + ret = efi_capsule_supported(cap_hdr->guid, cap_hdr > ->flags, > + cap_hdr->imagesize, > + &cap_info->reset_type); > + mutex_unlock(&capsule_loader_lock); What does this mutex really do ? You hold it here around efi_capsule_supported() in the call chain efi_capsule_write() => efi_capsule_setup_info() and then again inside of efi_capsule_submit_update() the call chain chain efi_capsule_write() => efi_capsule_submit_update() So if its valid to ensure you are synchronizing parallel contexts with -respect to calls into efi_capsule_supported() and efi_capsule_submit_update() why aren't you holding that lock for the duration of efi_capsule_write() - couldn't cap_info->page_bytes_remain as an example equally be racy ? > + > +/** > + * efi_capsule_submit_update - invoke the efi_capsule_update API > once binary > + * upload done > + * @cap_info: pointer to current instance of capsule_info structure > + **/ > +static ssize_t efi_capsule_submit_update(struct capsule_info > *cap_info) > +{ > + int ret; > + void *cap_hdr_temp; > + > + cap_hdr_temp = kmap(cap_info->pages[0]); > + if (!cap_hdr_temp) { > + pr_debug("%s: kmap() failed\n", __func__); > + return -EFAULT; > + } > + > + mutex_lock(&capsule_loader_lock); > + ret = efi_capsule_update(cap_hdr_temp, cap_info->pages); > + mutex_unlock(&capsule_loader_lock); > + kunmap(cap_info->pages[0]); > + if (ret) { > + pr_err("%s: efi_capsule_update() failed\n", > __func__); > + return ret; > + } > + > + /* Indicate capsule binary uploading is done */ > + cap_info->index = NO_FURTHER_WRITE_ACTION; Again - if you need a mutex for efi_capsule_update() why don't you need a mutex for cap_info->index updates looks racy... +} > + > +/** > + * efi_capsule_write - store the capsule binary and pass it to > + * efi_capsule_update() API > + * @file: file pointer > + * @buff: buffer pointer > + * @count: number of bytes in @buff > + * @offp: not used > + * > + * Expectation: > + * - User space tool should start at the beginning of capsule > binary and > + * pass data in sequential. A user-space tool.. sequentially > + * - User should close and re-open this file note in order to > upload more > + * capsules. A user should.. > + * - Any error occurred, user should close the file and > restart the > + * operation for the next try otherwise -EIO will be > returned until the > + * file is closed. On error -EIO will be returned and capsule loading will be abandoned. > + * - EFI capsule header must be located at the beginning of > capsule binary > + * file and passed in as 1st block write. An EFI capsule header.... in as the first data in the first write operation > + **/ > +static ssize_t efi_capsule_write(struct file *file, const char > __user *buff, > + size_t count, loff_t *offp) > +{ > + int ret = 0; > + struct capsule_info *cap_info = file->private_data; > + struct page *kbuff_page = NULL; > + void *kbuff = NULL; > + size_t write_byte; > + > + if (count == 0) > + return 0; > + > + /* Return error while NO_FURTHER_WRITE_ACTION is flagged */ > + if (cap_info->index < 0) > + return -EIO; > + > + /* Only alloc a new page when previous page is full */ > + if (!cap_info->page_bytes_remain) { > + kbuff_page = alloc_page(GFP_KERNEL); > + if (!kbuff_page) { > + pr_debug("%s: alloc_page() failed\n", > __func__); Shouldn't this be a pr_err() ? > + ret = -ENOMEM; > + goto failed; > + } > + cap_info->page_bytes_remain = PAGE_SIZE; > + } else { > + kbuff_page = cap_info->pages[--cap_info->index]; How are you guaranteeing this index doesn't go negative ? You compare index < 0 above so the pre-decrement could be negative ... right ? > + } > + > + kbuff = kmap(kbuff_page); > + if (!kbuff) { > + pr_debug("%s: kmap() failed\n", __func__); and here ? > + ret = -EFAULT; > + goto fail_freepage; > + } > + kbuff += PAGE_SIZE - cap_info->page_bytes_remain; > + > + /* Copy capsule binary data from user space to kernel space > buffer */ > + write_byte = min_t(size_t, count, cap_info > ->page_bytes_remain); > + if (copy_from_user(kbuff, buff, write_byte)) { > + pr_debug("%s: copy_from_user() failed\n", __func__); ditto > + ret = -EFAULT; > + goto fail_unmap; > + } > + cap_info->page_bytes_remain -= write_byte; > + > + /* Setup capsule binary info structure */ > + if (!cap_info->header_obtained) { > + ret = efi_capsule_setup_info(cap_info, kbuff, > + cap_info->count + > write_byte); > + if (ret) > + goto fail_unmap; > + } > + > + cap_info->pages[cap_info->index++] = kbuff_page; > + cap_info->count += write_byte; > + kunmap(kbuff_page); > + > + /* Submit the full binary to efi_capsule_update() API */ > + if (cap_info->header_obtained && > + cap_info->count >= cap_info->total_size) { > + if (cap_info->count > cap_info->total_size) { > + pr_err("%s: upload size exceeded header > defined size\n", > + __func__); > + ret = -EINVAL; > + goto failed; Shouldn't this be fail_freepage ? > + } > + > + ret = efi_capsule_submit_update(cap_info); > + if (ret) > + goto failed; Shouldn't this be fail_freepage ? > + } > + > + return write_byte; > + > +fail_unmap: > + kunmap(kbuff_page); > +fail_freepage: > + __free_page(kbuff_page); > +failed: > + efi_free_all_buff_pages(cap_info); > + return ret; > +} > + > +/** > + * efi_capsule_flush - called by file close or file flush > + * @file: file pointer > + * @id: not used > + * > + * If capsule being uploaded partially, calling this function > will be > + * treated as uploading canceled and will free up those > completed buffer > + * pages and then return -ECANCELED. If a capsule is being partially updated then calling this function will be treated as upload termination and will free completed buffer pages; in this case -ECANCELLED will be returned. > + **/ > +static int efi_capsule_flush(struct file *file, fl_owner_t id) > +{ > + int ret = 0; > + struct capsule_info *cap_info = file->private_data; > + > + if (cap_info->index > 0) { > + pr_err("%s: capsule upload not complete\n", > __func__); > + efi_free_all_buff_pages(cap_info); > + ret = -ECANCELED; > + } > + > + return ret; > +} > + > +/** > + * efi_capsule_release - called by file close > + * @inode: not used > + * @file: file pointer > + * > + * We would not free the successful submitted buffer pages > here due to > + * efi update require system reboot with data maintained. > + **/ We will not free successfully submitted pages since EFI update requires data to be maintained across boot. > +static int efi_capsule_open(struct inode *inode, struct file *file) > +{ > + struct capsule_info *cap_info; > + > + cap_info = kzalloc(sizeof(*cap_info), GFP_KERNEL); > + if (!cap_info) > + return -ENOMEM; > + > + file->private_data = cap_info; > + > + return 0; > +} You have a memory leak here don't you ? if I do for (i = 0; i < N; i++) { fd = open(/dev/your_node); close(fd); } You'll leak that kzalloc... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
