Re: [PATCH v2 0/7] efi: Enhance capsule loader to support signed Quark images

On Fri, Mar 24, 2017 at 7:34 PM, Jan Kiszka wrote: > This addresses the review feedback provided on round 1, specifically > - refactored queue to keep the Quark mess in > - only check for CSH on Quark CPUs > - added some smaller cleanups of the capsule loader > -

Re: [PATCH v2 7/7] efi/capsule: Add support for Quark security header

On Fri, Mar 24, 2017 at 7:34 PM, Jan Kiszka wrote: > 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 - >

Re: [PATCH v2 5/7] efi/capsule: Prepare for loading images with security header

On Fri, Mar 24, 2017 at 7:34 PM, Jan Kiszka wrote: > The Quark security header is nicely located in front of the capsule > image, but we still need to pass the image to the update service as if > there was none. Prepare efi_capsule_update and its user for this by >

Re: [PATCH v2 4/7] efi/capsule: Adjust return type of efi_capsule_setup_info

On 24 March 2017 at 17:34, Jan Kiszka wrote: > We actually expect int at the caller and never return any size > information. > > Signed-off-by: Jan Kiszka Reviewed-by: Ard Biesheuvel > --- >

Re: [PATCH v2 3/7] efi/capsule: Clean up pr_err/info messages

On 24 March 2017 at 17:34, Jan Kiszka wrote: > Avoid __func__, improve the information provided by some of the > messages. > > Signed-off-by: Jan Kiszka Reviewed-by: Ard Biesheuvel > --- >

Re: [PATCH v2 1/7] efi/capsule: Fix return code on failing kmap/vmap

On 24 March 2017 at 17:34, Jan Kiszka wrote: > 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 Reviewed-by: Ard Biesheuvel

Re: [PATCH v2 2/7] efi/capsule: Remove pr_debug on ENOMEM or EFAULT

On 24 March 2017 at 17:34, Jan Kiszka wrote: > Both cases are not worth a debug log message - the error code is telling > enough. > > Signed-off-by: Jan Kiszka Reviewed-by: Ard Biesheuvel > --- >

[PATCH v2 4/7] efi/capsule: Adjust return type of efi_capsule_setup_info

We actually expect int at the caller and never return any size information. Signed-off-by: Jan Kiszka --- drivers/firmware/efi/capsule-loader.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/firmware/efi/capsule-loader.c

[PATCH v2 6/7] efi/capsule: Factor out overloadable efi_capsule_identify_image

Another step to prepare Quark's CSH capsule format: Factor out the weak efi_capsule_identify_image function which is supposed to tell standard- conforming images apart from the special ones. The conforming version of it is __efi_capsule_identify_image, and that is called unless

[PATCH v2 2/7] efi/capsule: Remove pr_debug on ENOMEM or EFAULT

Both cases are not worth a debug log message - the error code is telling enough. Signed-off-by: Jan Kiszka --- drivers/firmware/efi/capsule-loader.c | 11 ++- 1 file changed, 2 insertions(+), 9 deletions(-) diff --git a/drivers/firmware/efi/capsule-loader.c

[PATCH v2 0/7] efi: Enhance capsule loader to support signed Quark images

This addresses the review feedback provided on round 1, specifically - refactored queue to keep the Quark mess in - only check for CSH on Quark CPUs - added some smaller cleanups of the capsule loader - documented capsule header / linked to original code See last patch for the background of the

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

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 any GUID conflict - validating its size field to contain the expected value.

[PATCH v2 3/7] efi/capsule: Clean up pr_err/info messages

Avoid __func__, improve the information provided by some of the messages. Signed-off-by: Jan Kiszka --- drivers/firmware/efi/capsule-loader.c | 19 --- 1 file changed, 8 insertions(+), 11 deletions(-) diff --git a/drivers/firmware/efi/capsule-loader.c

[PATCH v2 1/7] efi/capsule: Fix return code on failing kmap/vmap

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 --- drivers/firmware/efi/capsule-loader.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH v2 5/7] efi/capsule: Prepare for loading images with security header

The Quark security header is nicely located in front of the capsule image, but we still need to pass the image to the update service as if there was none. Prepare efi_capsule_update and its user for this by defining and evaluating a EFI header displacement in the image located in memory. For

Re: [RFC PATCH v2 15/32] x86: Add support for changing memory encryption attribute in early boot

On Thu, Mar 02, 2017 at 10:15:28AM -0500, Brijesh Singh wrote: > Some KVM-specific custom MSRs shares the guest physical address with > hypervisor. When SEV is active, the shared physical address must be mapped > with encryption attribute cleared so that both hypervsior and guest can > access the

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

(restarting this topic, new patches are in the make) On 2017-02-17 02:30, Bryan O'Donoghue wrote: > > > On 15/02/17 18:14, Jan Kiszka wrote: >> The firmware for Quark X102x prepends a security header to the capsule >> which is needed to support the mandatory secure boot on this processor. >>

Re: [PATCH V13 10/10] arm/arm64: KVM: add guest SEA support

On Tue, Mar 21, 2017 at 04:47:05PM -0600, Tyler Baicar wrote: > Currently external aborts are unsupported by the guest abort > handling. Add handling for SEAs so that the host kernel reports > SEAs which occur in the guest kernel. The logic in kvm_handle_guest_abort could deserve an explanation

Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark images

On 2017-02-20 02:33, Bryan O'Donoghue wrote: > > > On 19/02/17 13:33, Jan Kiszka wrote: >>> I would not object strongly to having conditionally compiled code in >>> mainline that adds support for this, but bodging the default code path >>> like this for a Quark quirk is out of the question imo.

Re: [PATCH 3/4] efi/libstub: arm/arm64: disable debug prints on 'quiet' cmdline arg

On Fri, Mar 24, 2017 at 01:24:09PM +, Ard Biesheuvel wrote: > The EFI stub currently prints a number of diagnostic messages that do > not carry a lot of information. Since these prints are not controlled > by 'loglevel' or other command line parameters, and since they appear on > the EFI

Re: [PATCH V13 10/10] arm/arm64: KVM: add guest SEA support

On 21/03/17 22:47, Tyler Baicar wrote: > Currently external aborts are unsupported by the guest abort > handling. Add handling for SEAs so that the host kernel reports > SEAs which occur in the guest kernel. > > Signed-off-by: Tyler Baicar > --- >

[PATCH 2/4] efi/libstub: unify command line param parsing

Merge the parsing of the command line carried out in arm-stub.c with the handling in efi_parse_options. Note that this also fixes the missing handling of CONFIG_CMDLINE_FORCE=y, in which case the builtin command line should supersede the one passed by the firmware. Cc: Matt Fleming

[PATCH 1/4] efi/libstub: fix harmless command line parsing bug

When we parse the 'efi=' command line parameter in the stub, we fail to take spaces into account. Currently, the only way this could result in unexpected behavior is when the string 'nochunk' appears as a separate command line argument after 'efi=xxx,yyy,zzz ', so this is harmless in practice. But

[PATCH 4/4] ef/libstub: arm/arm64: randomize the base of the UEFI rt services region

Update the allocation logic for the virtual mapping of the UEFI runtime services to start from a randomized base address if KASLR is in effect, and if the UEFI firmware exposes an implementation of EFI_RNG_PROTOCOL. This makes it more difficult to predict the location of exploitable data

[PATCH 3/4] efi/libstub: arm/arm64: disable debug prints on 'quiet' cmdline arg

The EFI stub currently prints a number of diagnostic messages that do not carry a lot of information. Since these prints are not controlled by 'loglevel' or other command line parameters, and since they appear on the EFI framebuffer as well (if enabled), it would be nice if we could turn them off.

[PATCH 0/4] efi: libstub enhancements for cmdline parsing and kaslr

This adds support for the 'quiet' kernel command line parameter, so that meaningless debug prints can be prevented from corrupting the boot splash (#3) Secondly, it enables randomization of the UEFI runtime services region when KASLR is in effect (#4) Patches #1 and #2 are preparatory cleanup

Re: [PATCH v2] x86/mm/KASLR: EFI region is mistakenly included into KASLR VA space for randomization

On 03/24/17 at 10:24am, Ingo Molnar wrote: > > * Dave Young wrote: > > > > > So I applied this kexec fix and extended the changelog to clearly show > > > > why > > > > this fix matters in practice. > > > > > > I thought it only impacts kexec, but Dave thought it will

[PATCH v2] efi/arm32-stub: allow boottime allocations in the vmlinux region

The arm32 kernel decompresses itself to the base of DRAM unconditionally, and so it is the EFI stub's job to ensure that the region is available. Currently, we do this by creating an allocation there, and giving up if that fails. However, any boot services regions occupying this area are not an

Re: [PATCH v2] x86/mm/KASLR: EFI region is mistakenly included into KASLR VA space for randomization

* Ard Biesheuvel wrote: > > Turning KASLR off actively degrades that randomization of the kernel > > virtual > > addresses. > > > > Am I missing anything? > > > > No, I think you are right. UEFI runtime services region are likely to consist > of > R+W+X mappings

Re: [PATCH v2] x86/mm/KASLR: EFI region is mistakenly included into KASLR VA space for randomization

On 24 March 2017 at 10:36, Ingo Molnar wrote: > > * Ard Biesheuvel wrote: > >> No. It is the firmware's EFI code, and the virtual translation applied by >> the OS >> is made known to the firmware by means of a call into the runtime service >>

Re: [PATCH v2] x86/mm/KASLR: EFI region is mistakenly included into KASLR VA space for randomization

* Ard Biesheuvel wrote: > No. It is the firmware's EFI code, and the virtual translation applied by the > OS > is made known to the firmware by means of a call into the runtime service > SetVirtualAddressMap(). This service can only be called once after each boot,

Re: [PATCH v2] x86/efi: Clean up a minor mistake in code comment

On 03/24/17 at 09:43am, Ard Biesheuvel wrote: > On 24 March 2017 at 09:17, Baoquan He wrote: > > EFI allocate runtime services regions from EFI_VA_START, -4G, down > > to -68G, EFI_VA_END, 64G altogether. The mechanism was introduced in > > commit d2f7cbe7b26a7 ("x86/efi: Runtime

Re: [PATCH v2] x86/mm/KASLR: EFI region is mistakenly included into KASLR VA space for randomization

On 24 March 2017 at 09:46, Borislav Petkov wrote: > On Fri, Mar 24, 2017 at 09:42:40AM +, Ard Biesheuvel wrote: >> That is a different matter. If the regions are only mapped while >> runtime services invocations are in progress (as we do on ARM), I am >> not sure if it matters

Re: [PATCH v2] x86/mm/KASLR: EFI region is mistakenly included into KASLR VA space for randomization

On Fri, Mar 24, 2017 at 09:42:40AM +, Ard Biesheuvel wrote: > That is a different matter. If the regions are only mapped while > runtime services invocations are in progress (as we do on ARM), I am > not sure if it matters that much, given how rarely that occurs in > normal use. Question is,

Re: [PATCH v2] x86/mm/KASLR: EFI region is mistakenly included into KASLR VA space for randomization

On Fri, Mar 24, 2017 at 10:24:34AM +0100, Ingo Molnar wrote: > Preserving virtual addresses for kexec is a red herring: the randomized > offset > could be passed to the kexec-ed kernel just fine. Not only that - kexec'ed kernel gets the addresses from sysfs so we can randomize. --

Re: [PATCH v2] x86/mm/KASLR: EFI region is mistakenly included into KASLR VA space for randomization

On 03/24/17 at 09:08am, Ingo Molnar wrote: > > Cc: #4.8+ > > Signed-off-by: Baoquan He > > Acked-by: Dave Young > > Reviewed-by: Bhupesh Sharma > > Acked-by: Thomas Garnier > > Cc: Thomas

Re: [PATCH v2] x86/mm/KASLR: EFI region is mistakenly included into KASLR VA space for randomization

* Baoquan He wrote: > Currently KASLR is enabled on three regions: the direct mapping of physical > memory, vamlloc and vmemmap. However EFI region is also mistakenly included > for VA space randomization because of misusing EFI_VA_START macro and > assuming EFI_VA_START <