linux-kernel - Re: [PATCH] x86_64/efi: Mapping Boot and Runtime EFI memory regions to different starting virtual address

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 30 Jul 2015 19:09:59 +0800
From:	joeyli <jlee@...e.com>
To:	Matt Fleming <matt@...eblueprint.co.uk>
Cc:	Borislav Petkov <bp@...en8.de>, "H. Peter Anvin" <hpa@...or.com>,
	"Lee, Chun-Yi" <joeyli.kernel@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, x86@...nel.org,
	linux-efi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86_64/efi: Mapping Boot and Runtime EFI memory regions
 to different starting virtual address

On Thu, Jul 30, 2015 at 11:11:31AM +0100, Matt Fleming wrote:
> On Thu, 30 Jul, at 10:03:23AM, Borislav Petkov wrote:
> > On Thu, Jul 30, 2015 at 12:53:42AM -0700, H. Peter Anvin wrote:
> > > This changelog is at least partially incomprehensive. It also seems
> > > more than a bit aggressive to expect that 1 GB will be sufficient
> > > forever.
> > 
> > Right, before we do anything, I'd like for us to figure out first why
> > this is a problem all of a sudden. And why should we even keep boot
> > code/data, if it is fair game, once runtime services get enabled.
> > 
> > Matt, can you please chime in first before we even talk about a
> > solution...
> 
> Yeah, I do not understand the issue properly.
> 
> Why do we care about EfiBoot* regions after hibernate? Surely we've
> already freed those regions in efi_free_boot_services() during boot and
> nobody should be touching them again? If the firmware does, that's a
> whole new bug we've never encountered before.
> 
> And we obviously can't allow the runtime regions to move around during
> hibernate/resume because we've already informed the firmware where those
> regions live during SetVirtualAddressMap() at boot.
> 
> I admit that I haven't looked at the hibernate code paths. Let me go do
> that now.
> 
> -- 
> Matt Fleming, Intel Open Source Technology Center

In efi_map_regions(), kernel mapping EFI_MEMORY_RUNTIME and
EFI_BOOT_SERVICES_CODE/DATA regions to trampoline_pgd.

UEFI keeps the physical address of Runtime Code/Data were not changed in
hibernate cycle. But the changes of Boot regions causes Runtime Code/Data
mapping to different virtual address in trampoline_pgd.

The following is a case from Intel DQ57TM.

Boot:
[    0.036509] efi: mem11: [Boot Data          |   |  |  |  |   |WB|WT|WC|UC] pa=[0x00000000b7f7e000-0x00000000b7f9e000) va=[0xfffffffefff7e000-0xfffffffefff9e000) (0MB)
[    0.051393] efi: mem17: [Boot Data          |   |  |  |  |   |WB|WT|WC|UC] pa=[0x00000000b8b4f000-0x00000000b8b50000) va=[0xfffffffefff4f000-0xfffffffefff50000) (0MB)
[    0.066271] efi: mem19: [Boot Data          |   |  |  |  |   |WB|WT|WC|UC] pa=[0x00000000b8c2f000-0x00000000b9135000) va=[0xfffffffeffa2f000-0xfffffffefff35000) (5MB)
[    0.081152] efi: mem21: [Boot Data          |   |  |  |  |   |WB|WT|WC|UC] pa=[0x00000000b9138000-0x00000000baf7d000) va=[0xfffffffefdb38000-0xfffffffeff97d000) (30MB)
[    0.096120] efi: mem23: [Boot Code          |   |  |  |  |   |WB|WT|WC|UC] pa=[0x00000000bb04b000-0x00000000bb385000) va=[0xfffffffefd64b000-0xfffffffefd985000) (3MB)
[    0.111002] efi: mem24: [Runtime Code       |RUN|  |  |  |   |WB|WT|WC|UC] pa=[0x00000000bb385000-0x00000000bb3e5000) va=[0xfffffffefd585000-0xfffffffefd5e5000) (0MB)
[    0.125883] efi: mem25: [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC] pa=[0x00000000bb3e5000-0x00000000bb445000) va=[0xfffffffefd3e5000-0xfffffffefd445000) (0MB)
[    0.140764] efi: mem29: [Boot Data          |   |  |  |  |   |WB|WT|WC|UC] pa=[0x00000000bb7ff000-0x00000000bb800000) va=[0xfffffffefd1ff000-0xfffffffefd200000) (0MB)

Hibernate resumed:
[    0.036486] efi: mem11: [Boot Data          |   |  |  |  |   |WB|WT|WC|UC] pa=[0x00000000b7f7e000-0x00000000b7f9e000) va=[0xfffffffefff7e000-0xfffffffefff9e000) (0MB)
[    0.051375] efi: mem17: [Boot Data          |   |  |  |  |   |WB|WT|WC|UC] pa=[0x00000000b8c0d000-0x00000000b9113000) va=[0xfffffffeffa0d000-0xfffffffefff13000) (5MB)	<=== order of Boot Data changed
[    0.066253] efi: mem20: [Boot Data          |   |  |  |  |   |WB|WT|WC|UC] pa=[0x00000000b9132000-0x00000000b9133000) va=[0xfffffffeff932000-0xfffffffeff933000) (0MB)
[    0.081135] efi: mem22: [Boot Data          |   |  |  |  |   |WB|WT|WC|UC] pa=[0x00000000b9138000-0x00000000baf7d000) va=[0xfffffffefd938000-0xfffffffeff77d000) (30MB)
[    0.096103] efi: mem24: [Boot Code          |   |  |  |  |   |WB|WT|WC|UC] pa=[0x00000000bb04b000-0x00000000bb385000) va=[0xfffffffefd44b000-0xfffffffefd785000) (3MB)
[    0.110984] efi: mem25: [Runtime Code       |RUN|  |  |  |   |WB|WT|WC|UC] pa=[0x00000000bb385000-0x00000000bb3e5000) va=[0xfffffffefd385000-0xfffffffefd3e5000) (0MB)	<=== va changed
[    0.125865] efi: mem26: [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC] pa=[0x00000000bb3e5000-0x00000000bb445000) va=[0xfffffffefd1e5000-0xfffffffefd245000) (0MB)
[    0.140747] efi: mem30: [Boot Data          |   |  |  |  |   |WB|WT|WC|UC] pa=[0x00000000bb7ff000-0x00000000bb800000) va=[0xfffffffefcfff000-0xfffffffefd000000) (0MB)

Look at the origin va of Runtime Code is 0xfffffffefd585000, but after hibernate
result boot, the new va is 0xfffffffefd385000.

Issue machine's UEFI keeps the PA of Runtime regions unchanged, but Boot regions
moved. That causes Runtime regions mapping to different VA.



Regards
Joey Lee
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/