All of lore.kernel.org
 help / color / mirror / Atom feed
From: Baoquan He <bhe@redhat.com>
To: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: Kees Cook <keescook@chromium.org>,
	linux-kernel@vger.kernel.org, x86@kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@kernel.org>,
	izumi.taku@jp.fujitsu.com, Thomas Garnier <thgarnie@google.com>,
	fanc.fnst@cn.fujitsu.com, Matt Fleming <matt@codeblueprint.co.uk>,
	"Jun'ichi Nomura" <j-nomura@ce.jp.nec.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: Re: [PATCH v4] x86/boot/KASLR: exclude EFI_BOOT_SERVICES_{CODE|DATA} from KASLR's choice
Date: Mon, 28 Aug 2017 14:59:51 +0800	[thread overview]
Message-ID: <20170828065951.GB23855@x1> (raw)
In-Reply-To: <1503570831-9683-1-git-send-email-n-horiguchi@ah.jp.nec.com>

Hi Naoya,

Thanks for this fix. I saw NEC had reported a bug to rhel previously,
and the bug truly will corrupt OS, it can be fixed by this patch.

This patch looks good to me, just a small concern, please see below
inline comment.

On 08/24/17 at 07:33pm, Naoya Horiguchi wrote:
> KASLR chooses kernel location from E820_TYPE_RAM regions by walking over
> e820 entries now. E820_TYPE_RAM includes EFI_BOOT_SERVICES_CODE and
> EFI_BOOT_SERVICES_DATA, so those regions can be the target. According to
> UEFI spec, all memory regions marked as EfiBootServicesCode and
> EfiBootServicesData are available for free memory after the first call
> of ExitBootServices(). So such regions should be usable for kernel on
> spec basis.
> 
> In x86, however, we have some workaround for broken firmware, where we
> keep such regions reserved until SetVirtualAddressMap() is done.
> See the following code in should_map_region():
> 
> 	static bool should_map_region(efi_memory_desc_t *md)
> 	{
> 		...
> 		/*
> 		 * Map boot services regions as a workaround for buggy
> 		 * firmware that accesses them even when they shouldn't.
> 		 *
> 		 * See efi_{reserve,free}_boot_services().
> 		 */
> 		if (md->type == EFI_BOOT_SERVICES_CODE ||
> 			md->type == EFI_BOOT_SERVICES_DATA)
> 				return false;
> 
> This workaround suppressed a boot crash, but potential issues still
> remain because no one prevents the regions from overlapping with kernel
> image by KASLR.
> 
> So let's make sure that EFI_BOOT_SERVICES_{CODE|DATA} regions are never
> chosen as kernel memory for the workaround to work fine. Furthermore,
> we choose kernel address only from EFI_CONVENTIONAL_MEMORY because it's
> the only memory type we know to be free.

Here, I think it's better to present why EFI_CONVENTIONAL_MEMORY is the
only memory type we should choose. EFI_BOOT_SERVICES_xxx has been clear
to us why it's not good. It might be worth to saying something about
EFI_LOADER_xxx why it's not ok to choose. Maybe one sentence to mention
it and take pgd as exampel as Matt ever said.

Thanks
Baoquan

> v3 -> v4:
> - update comment and patch description to mention why only
>   EFI_CONVENTIONAL_MEMORY is chosen.
> - use efi_early_memdesc_ptr()
> - I decided not to post cleanup patches (patch 2/2 in previous series)
>   because it's not necessary to fix the issue.
> 
> v2 -> v3:
> - skip EFI_LOADER_CODE and EFI_LOADER_DATA in region scan
> 
> v1 -> v2:
> - switch efi_mirror_found to local variable
> - insert break when EFI_MEMORY_MORE_RELIABLE found
> ---
>  arch/x86/boot/compressed/kaslr.c | 35 ++++++++++++++++++++++++++---------
>  1 file changed, 26 insertions(+), 9 deletions(-)
> 
> diff --git tip/x86/boot/arch/x86/boot/compressed/kaslr.c tip/x86/boot_patched/arch/x86/boot/compressed/kaslr.c
> index 7de23bb..ba5e9e5 100644
> --- tip/x86/boot/arch/x86/boot/compressed/kaslr.c
> +++ tip/x86/boot_patched/arch/x86/boot/compressed/kaslr.c
> @@ -597,19 +597,36 @@ process_efi_entries(unsigned long minimum, unsigned long image_size)
>  	for (i = 0; i < nr_desc; i++) {
>  		md = efi_early_memdesc_ptr(pmap, e->efi_memdesc_size, i);
>  		if (md->attribute & EFI_MEMORY_MORE_RELIABLE) {
> -			region.start = md->phys_addr;
> -			region.size = md->num_pages << EFI_PAGE_SHIFT;
> -			process_mem_region(&region, minimum, image_size);
>  			efi_mirror_found = true;
> -
> -			if (slot_area_index == MAX_SLOT_AREA) {
> -				debug_putstr("Aborted EFI scan (slot_areas full)!\n");
> -				break;
> -			}
> +			break;
>  		}
>  	}
>  
> -	return efi_mirror_found;
> +	for (i = 0; i < nr_desc; i++) {
> +		md = efi_early_memdesc_ptr(pmap, e->efi_memdesc_size, i);
> +
> +		/*
> +		 * According to spec, EFI_BOOT_SERVICES_{CODE|DATA} are also
> +		 * available for kernel image, but we don't include them for
> +		 * the workaround for buggy firmware.
> +		 * Only EFI_CONVENTIONAL_MEMORY is guaranteed to be free.
> +		 */
> +		if (md->type != EFI_CONVENTIONAL_MEMORY)
> +			continue;
> +
> +		if (efi_mirror_found &&
> +		    !(md->attribute & EFI_MEMORY_MORE_RELIABLE))
> +			continue;
> +
> +		region.start = md->phys_addr;
> +		region.size = md->num_pages << EFI_PAGE_SHIFT;
> +		process_mem_region(&region, minimum, image_size);
> +		if (slot_area_index == MAX_SLOT_AREA) {
> +			debug_putstr("Aborted EFI scan (slot_areas full)!\n");
> +			break;
> +		}
> +	}
> +	return true;
>  }
>  #else
>  static inline bool
> -- 
> 2.7.0
> 

  reply	other threads:[~2017-08-28  6:59 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-24 10:33 [PATCH v4] x86/boot/KASLR: exclude EFI_BOOT_SERVICES_{CODE|DATA} from KASLR's choice Naoya Horiguchi
2017-08-28  6:59 ` Baoquan He [this message]
2017-08-28  7:44   ` [PATCH v5] x86/boot/KASLR: exclude EFI_BOOT_SERVICES_* and EFI_LOADER_* " Naoya Horiguchi
2017-08-28  7:55     ` Baoquan He
2017-08-31 20:00     ` [tip:x86/boot] x86/boot/KASLR: Work around firmware bugs by excluding " tip-bot for Naoya Horiguchi

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=20170828065951.GB23855@x1 \
    --to=bhe@redhat.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=fanc.fnst@cn.fujitsu.com \
    --cc=hpa@zytor.com \
    --cc=izumi.taku@jp.fujitsu.com \
    --cc=j-nomura@ce.jp.nec.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matt@codeblueprint.co.uk \
    --cc=mingo@kernel.org \
    --cc=n-horiguchi@ah.jp.nec.com \
    --cc=tglx@linutronix.de \
    --cc=thgarnie@google.com \
    --cc=x86@kernel.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.