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 IOT2020 and IOT2040, the latter with Quark-proprietar
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 IOT2020 and IOT2040, the latter with Quark-proprietary security
>> header format. The feature should also
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 and,
> at least conceptua
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 is pending for the next res
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.
Signed-off-by: Matt Fleming
Acke
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 interacting with the
firmware, and a
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 driver needs to vmap
the e
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 > /dev/efi_capsule_loader
Any upload error
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: Andy
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 you mean to pass the address
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 non-standard header formats
more eas
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: Matt Fleming
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
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 Biesheuvel
Reviewed-by: Matt Fleming
Cc: Linus
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 redefine the former
but still
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" signature and -
to avoid
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
Reviewed-by: Matt Fleming
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gle
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
Reviewed-by: Matt Fleming
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
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 efi_capsule_setup_info() the
opport
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. thanks
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 hype
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 w
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 Westerberg
> > > >
> > > > OK
> > > >
> > > > Andy, do yo
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, did
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 pi
Thanks,
applied to the uuid for-next tree.
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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 want me to apply this?
> >
> > If you would like to.
> >
> > The patch is now pretty
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 "unsubsc
27 matches
Mail list logo
