Re: [PATCH 00/14] EFI capsule update support for IOT2000 devices

On 30 August 2017 at 20:27, Jan Kiszka wrote: > On 2017-08-30 21:24, Ard Biesheuvel wrote: >> Hello Jan, >> >> On 30 August 2017 at 20:13, Jan Kiszka wrote: >>> Last chunk: This backports EFI capsule updates, primarily for the use >>> with the

Re: [PATCH 00/14] EFI capsule update support for IOT2000 devices

Hello Jan, On 30 August 2017 at 20:13, Jan Kiszka wrote: > Last chunk: This backports EFI capsule updates, primarily for the use > with the IOT2020 and IOT2040, the latter with Quark-proprietary security > header format. The feature should also work for the Galileo Gen 2

[PATCH 03/14] x86/efi: Force EFI reboot to process pending capsules

From: Matt Fleming commit 87615a34d561ef59bd0cffc73256a21220dfdffd upstream. If an EFI capsule has been sent to the firmware we must match the type of EFI reset against that required by the capsule to ensure it is processed correctly. Force an EFI reboot if a capsule

[PATCH 01/14] efi: Move efi_status_to_err() to drivers/firmware/efi/

From: Matt Fleming commit 806b0351c9ff9890c1ef0ba2c46237baef49ac79 upstream. Move efi_status_to_err() to the architecture independent code as it's generally useful in all bits of EFI code where there is a need to convert an efi_status_t to a kernel error value.

[PATCH 02/14] efi: Add 'capsule' update support

From: Matt Fleming commit f0133f3c5b8bb34ec4dec50c27e7a655aeee8935 upstream. The EFI capsule mechanism allows data blobs to be passed to the EFI firmware. A common use case is performing firmware updates. This patch just introduces the main infrastructure for

[PATCH 06/14] efi/capsule: Allocate whole capsule into virtual memory

From: Austin Christ commit 6862e6ad95e984991a6ceec592cf67831658f928 upstream. According to UEFI 2.6 section 7.5.3, the capsule should be in contiguous virtual memory and firmware may consume the capsule immediately. To correctly implement this functionality, the kernel

[PATCH 04/14] efi: Add misc char driver interface to update EFI firmware

From: Kweh, Hock Leong commit 65117f1aa1b2d145fd5ca376bde642794d0aae1b upstream. This patch introduces a kernel module to expose a capsule loader interface (misc char device file note) for users to upload capsule binaries. Example: cat firmware.bin >

[PATCH 00/14] EFI capsule update support for IOT2000 devices

Last chunk: This backports EFI capsule updates, primarily for the use with the IOT2020 and IOT2040, the latter with Quark-proprietary security header format. The feature should also work for the Galileo Gen 2 and, at least conceptually, for any EFI capsule update compatible firmware. Jan Cc:

[PATCH 05/14] efi/capsule: Move 'capsule' to the stack in efi_capsule_supported()

From: Matt Fleming commit fb7a84cac03541f4da18dfa25b3f4767d4efc6fc upstream. Dan Carpenter reports that passing the address of the pointer to the kmalloc()'d memory for 'capsule' is dangerous: "drivers/firmware/efi/capsule.c:109 efi_capsule_supported() warn: did

[PATCH 11/14] efi/capsule-loader: Use a cached copy of the capsule header

From: Ard Biesheuvel commit 82c3768b8d68c40ecde92338899c838b7c674ffb upstream. Instead of kmapping the capsule data twice, copy the capsule header into the capsule info struct we keep locally. This is an improvement by itself, but will also enable handling of

[PATCH 09/14] efi/capsule: Clean up pr_err/_info() messages

From: Jan Kiszka commit 5dce14b9d1a29cf76331f0fe8eb7efd63e0fcb9a upstream. Avoid __func__, improve the information provided by some of the messages. Signed-off-by: Jan Kiszka Signed-off-by: Ard Biesheuvel Reviewed-by:

[PATCH 07/14] efi/capsule: Fix return code on failing kmap/vmap

From: Jan Kiszka commit fb153dc53f0eb8e8ad6a69f773e44c2d12daa5d0 upstream. If kmap or vmap fail, it means we ran out of memory. There are no user-provided addressed involved that would justify EFAULT. Signed-off-by: Jan Kiszka Signed-off-by: Ard

[PATCH 12/14] efi/capsule-loader: Redirect calls to efi_capsule_setup_info() via weak alias

From: Ard Biesheuvel commit 3fabd628d5ea24b02ddb1230ffca1df0f779f84e upstream. To allow platform specific code to hook into the capsule loading routines, indirect calls to efi_capsule_setup_info() via a weak alias of __efi_capsule_setup_info(), allowing platforms to

[PATCH 14/14] efi/capsule: Add support for Quark security header

From: Jan Kiszka commit 2959c95d510cc45b246ba727eb8fdf8b601c6eec upstream. The firmware for Quark X102x prepends a security header to the capsule which is needed to support the mandatory secure boot on this processor. The header can be detected by checking for the "_CSH"

[PATCH 08/14] efi/capsule: Remove pr_debug() on ENOMEM or EFAULT

From: Jan Kiszka commit 7367633f0bfd783ae5838141f3af88bba6c45eb9 upstream. Both cases are not worth a debug log message - the error code is telling enough. Signed-off-by: Jan Kiszka Signed-off-by: Ard Biesheuvel

[PATCH 10/14] efi/capsule: Adjust return type of efi_capsule_setup_info()

From: Jan Kiszka commit 41b0c376951417d1b37448957b30f766b10d3090 upstream. We actually expect int at the caller and never return any size information. Signed-off-by: Jan Kiszka Signed-off-by: Ard Biesheuvel

[PATCH 13/14] efi/capsule-loader: Use page addresses rather than struct page pointers

From: Ard Biesheuvel commit 2a457fb31df62c6b482f78e4f74aaed99271f44d upstream. To give some leeway to code that handles non-standard capsule headers, let's keep an array of page addresses rather than struct page pointers. This gives special implementations of

Re: [RFC Part1 PATCH v3 16/17] X86/KVM: Provide support to create Guest and HV shared per-CPU variables

On Wed, Aug 30, 2017 at 11:18:42AM -0500, Brijesh Singh wrote: > I was trying to avoid mixing early and no-early set_memory_decrypted() but if > feedback is: use early_set_memory_decrypted() only if its required otherwise > use set_memory_decrypted() then I can improve the logic in next rev.

Re: [RFC Part1 PATCH v3 16/17] X86/KVM: Provide support to create Guest and HV shared per-CPU variables

Hi Boris, On 08/29/2017 05:22 AM, Borislav Petkov wrote: [...] On Mon, Jul 24, 2017 at 02:07:56PM -0500, Brijesh Singh wrote: Some KVM specific MSR's (steal-time, asyncpf, avic_eio) allocates per-CPU MSRs variable at compile time and share its physical address with

Re: [PATCH v1 6/6] device property: Switch to use new generic UUID API

On Wed, Aug 30, 2017 at 03:46:34PM +0200, Rafael J. Wysocki wrote: > 3689d3d69072 ACPI: device property: Switch to use new generic UUID API > > in my linux-next branch. Isn't it this one? Yes, that should be it. Somehow my linux-next tree seems to be a mess through or my git log skills aren't

Re: [PATCH v1 6/6] device property: Switch to use new generic UUID API

On Wednesday, August 30, 2017 2:41:41 PM CEST Christoph Hellwig wrote: > On Wed, Jul 26, 2017 at 02:27:44AM +0200, Rafael J. Wysocki wrote: > > > >> > Cc: "Rafael J. Wysocki" > > > >> > Cc: Mika Westerberg > > > >> > > > >> Acked-by: Mika

Re: [PATCH v1 3/6] staging: unisys: Switch to use new generic UUID API

On Wed, Aug 30, 2017 at 02:38:45PM +0200, Christoph Hellwig wrote: > On Mon, Jul 31, 2017 at 08:20:25PM +0300, Andy Shevchenko wrote: > > Yep! There are so many conflicts that would be better just to push > > through your tree. > > > > I have just sent a v2 of this patch separately. > > Greg,

Re: [PATCH v1 3/6] staging: unisys: Switch to use new generic UUID API

On Wed, 2017-08-30 at 14:38 +0200, Christoph Hellwig wrote: > On Mon, Jul 31, 2017 at 08:20:25PM +0300, Andy Shevchenko wrote: > > Yep! There are so many conflicts that would be better just to push > > through your tree. > > > > I have just sent a v2 of this patch separately. > > Greg, did you

Re: [PATCH v1 6/6] device property: Switch to use new generic UUID API

On Wed, Jul 26, 2017 at 02:27:44AM +0200, Rafael J. Wysocki wrote: > > >> > Cc: "Rafael J. Wysocki" > > >> > Cc: Mika Westerberg > > >> > > >> Acked-by: Mika Westerberg > > > > > > OK > > > > > > Andy, do you

Re: [PATCH v1 3/6] staging: unisys: Switch to use new generic UUID API

On Mon, Jul 31, 2017 at 08:20:25PM +0300, Andy Shevchenko wrote: > Yep! There are so many conflicts that would be better just to push > through your tree. > > I have just sent a v2 of this patch separately. Greg, did you pick that patch up? -- To unsubscribe from this list: send the line