Re: [PATCH 3.12 25/91] x86/setup: Extend low identity map to cover whole kernel range

2016-01-06 Thread Luis Henriques 
[ Adding Greg and Kamal ]

On Wed, Jan 06, 2016 at 01:31:55PM +, Matt Fleming wrote:
> On Wed, 06 Jan, at 11:24:55AM, Luis Henriques wrote:
> > On Wed, Jan 06, 2016 at 11:00:31AM +, Matt Fleming wrote:
> > > On Wed, 06 Jan, at 11:47:20AM, Paolo Bonzini wrote:
> > > > 
> > > > Without testing the problematic scenario explicitly (32-bit UEFI
> > > > kernel), I think this patch and 26/91 should not be backported to
> > > > kernels that do not have 23a0d4e8fa6d.
> > > 
> > > I tend to agree.
> > 
> > I can see these 2 commits in kernels as old as 3.10 (which definitely do
> > not include 23a0d4e8fa6d).  Does this mean these should be reverted from
> > stable kernels that already include these patches?  Or would you rather
> > recommend to backport 23a0d4e8fa6d?
> 
> That depends on your appetite for risk ;-)
>

Heh, I guess stable kernels aren't really about appetite for risk :-)

> 23a0d4e8fa6d does fix a legitimate bug, albeit one that no one seems
> to have ever hit. Personally, I'd go for backporting 23a0d4e8fa6d.

This commit doesn't seem to be too bad to backport.  I'm attaching 2
backports:

 - one is for the 3.16 stable kernel,
 - the other can be applied to 3.10, 3.12 and 3.13

(For the other kernels, I believe 23a0d4e8fa6d will be a clean
cherry-pick.)

Cheers,
--
Luís
>From 6b58a852d51e7d1991d759c331bc276b2461c4c3 Mon Sep 17 00:00:00 2001
From: Ingo Molnar 
Date: Tue, 3 Mar 2015 07:34:33 +0100
Subject: efi: Disable interrupts around EFI calls, not in the epilog/prolog
 calls

commit 23a0d4e8fa6d3a1d7fb819f79bcc0a3739c30ba9 upstream.

Tapasweni Pathak reported that we do a kmalloc() in efi_call_phys_prolog()
on x86-64 while having interrupts disabled, which is a big no-no, as
kmalloc() can sleep.

Solve this by removing the irq disabling from the prolog/epilog calls
around EFI calls: it's unnecessary, as in this stage we are single
threaded in the boot thread, and we don't ever execute this from
interrupt contexts.

Reported-by: Tapasweni Pathak 
Signed-off-by: Ingo Molnar 
Signed-off-by: Matt Fleming 
[ luis: backported to 3.10: adjusted context ]
Signed-off-by: Luis Henriques 
---
 arch/x86/platform/efi/efi.c|  7 +++
 arch/x86/platform/efi/efi_32.c | 11 +++
 arch/x86/platform/efi/efi_64.c |  3 ---
 3 files changed, 10 insertions(+), 11 deletions(-)

diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 6033be9ff81a..3c8bffdc71c8 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -250,12 +250,19 @@ static efi_status_t __init phys_efi_set_virtual_address_map(
 	efi_memory_desc_t *virtual_map)
 {
 	efi_status_t status;
+	unsigned long flags;
 
 	efi_call_phys_prelog();
+
+	/* Disable interrupts around EFI calls: */
+	local_irq_save(flags);
 	status = efi_call_phys4(efi_phys.set_virtual_address_map,
 memory_map_size, descriptor_size,
 descriptor_version, virtual_map);
+	local_irq_restore(flags);
+
 	efi_call_phys_epilog();
+
 	return status;
 }
 
diff --git a/arch/x86/platform/efi/efi_32.c b/arch/x86/platform/efi/efi_32.c
index 40e446941dd7..bebbee05e331 100644
--- a/arch/x86/platform/efi/efi_32.c
+++ b/arch/x86/platform/efi/efi_32.c
@@ -33,19 +33,16 @@
 
 /*
  * To make EFI call EFI runtime service in physical addressing mode we need
- * prelog/epilog before/after the invocation to disable interrupt, to
- * claim EFI runtime service handler exclusively and to duplicate a memory in
- * low memory space say 0 - 3G.
+ * prolog/epilog before/after the invocation to claim the EFI runtime service
+ * handler exclusively and to duplicate a memory mapping in low memory space,
+ * say 0 - 3G.
  */
 
-static unsigned long efi_rt_eflags;
 
 void efi_call_phys_prelog(void)
 {
 	struct desc_ptr gdt_descr;
 
-	local_irq_save(efi_rt_eflags);
-
 	load_cr3(initial_page_table);
 	__flush_tlb_all();
 
@@ -64,6 +61,4 @@ void efi_call_phys_epilog(void)
 
 	load_cr3(swapper_pg_dir);
 	__flush_tlb_all();
-
-	local_irq_restore(efi_rt_eflags);
 }
diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index 39a0e7f1f0a3..2f6c1a9734c8 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -40,7 +40,6 @@
 #include 
 
 static pgd_t *save_pgd __initdata;
-static unsigned long efi_flags __initdata;
 
 static void __init early_code_mapping_set_exec(int executable)
 {
@@ -66,7 +65,6 @@ void __init efi_call_phys_prelog(void)
 	int n_pgds;
 
 	early_code_mapping_set_exec(1);
-	local_irq_save(efi_flags);
 
 	n_pgds = DIV_ROUND_UP((max_pfn << PAGE_SHIFT), PGDIR_SIZE);
 	save_pgd = kmalloc(n_pgds * sizeof(pgd_t), GFP_KERNEL);
@@ -90,7 +88,6 @@ void __init efi_call_phys_epilog(void)
 		set_pgd(pgd_offset_k(pgd * PGDIR_SIZE), save_pgd[pgd]);
 	kfree(save_pgd);
 	__flush_tlb_all();
-	local_irq_restore(efi_flags);
 	early_code_mapping_set_exec(0);
 }
 
>From 466b891857a536af2a9b7ad058e1cc00b702a528 Mon Sep 17 00:00:00 2001
From: Ingo Molnar 
Date: Tue, 3 Mar 2015 07:34:33 +0100
Subject: [PATCH] efi: Disable

Re: [PATCH 3.12 25/91] x86/setup: Extend low identity map to cover whole kernel range

2016-01-06 Thread Matt Fleming 
On Wed, 06 Jan, at 11:24:55AM, Luis Henriques wrote:
> On Wed, Jan 06, 2016 at 11:00:31AM +, Matt Fleming wrote:
> > On Wed, 06 Jan, at 11:47:20AM, Paolo Bonzini wrote:
> > > 
> > > Without testing the problematic scenario explicitly (32-bit UEFI
> > > kernel), I think this patch and 26/91 should not be backported to
> > > kernels that do not have 23a0d4e8fa6d.
> > 
> > I tend to agree.
> 
> I can see these 2 commits in kernels as old as 3.10 (which definitely do
> not include 23a0d4e8fa6d).  Does this mean these should be reverted from
> stable kernels that already include these patches?  Or would you rather
> recommend to backport 23a0d4e8fa6d?

That depends on your appetite for risk ;-)

23a0d4e8fa6d does fix a legitimate bug, albeit one that no one seems
to have ever hit. Personally, I'd go for backporting 23a0d4e8fa6d.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3.12 25/91] x86/setup: Extend low identity map to cover whole kernel range

2016-01-06 Thread Luis Henriques 
On Wed, Jan 06, 2016 at 11:00:31AM +, Matt Fleming wrote:
> On Wed, 06 Jan, at 11:47:20AM, Paolo Bonzini wrote:
> > 
> > Without testing the problematic scenario explicitly (32-bit UEFI
> > kernel), I think this patch and 26/91 should not be backported to
> > kernels that do not have 23a0d4e8fa6d.
> 
> I tend to agree.

I can see these 2 commits in kernels as old as 3.10 (which definitely do
not include 23a0d4e8fa6d).  Does this mean these should be reverted from
stable kernels that already include these patches?  Or would you rather
recommend to backport 23a0d4e8fa6d?

Cheers,
--
Luís
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3.12 25/91] x86/setup: Extend low identity map to cover whole kernel range

2016-01-06 Thread Matt Fleming 
On Wed, 06 Jan, at 11:47:20AM, Paolo Bonzini wrote:
> 
> Without testing the problematic scenario explicitly (32-bit UEFI
> kernel), I think this patch and 26/91 should not be backported to
> kernels that do not have 23a0d4e8fa6d.

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

Re: [PATCH 3.12 25/91] x86/setup: Extend low identity map to cover whole kernel range

2016-01-06 Thread Paolo Bonzini 
This bug

On 05/01/2016 18:46, Jiri Slaby wrote:
> From: Paolo Bonzini 
> 
> 3.12-stable review patch.  If anyone has any objections, please let me know.
> 
> ===
> 
> commit f5f3497cad8c8416a74b9aaceb127908755d020a upstream.
> 
> On 32-bit systems, the initial_page_table is reused by
> efi_call_phys_prolog as an identity map to call
> SetVirtualAddressMap.  efi_call_phys_prolog takes care of
> converting the current CPU's GDT to a physical address too.
> 
> For PAE kernels the identity mapping is achieved by aliasing the
> first PDPE for the kernel memory mapping into the first PDPE
> of initial_page_table.  This makes the EFI stub's trick "just work".
> 
> However, for non-PAE kernels there is no guarantee that the identity
> mapping in the initial_page_table extends as far as the GDT; in this
> case, accesses to the GDT will cause a page fault (which quickly becomes
> a triple fault).  Fix this by copying the kernel mappings from
> swapper_pg_dir to initial_page_table twice, both at PAGE_OFFSET and at
> identity mapping.
> 
> For some reason, this is only reproducible with QEMU's dynamic translation
> mode, and not for example with KVM.  However, even under KVM one can clearly
> see that the page table is bogus:
> 
> $ qemu-system-i386 -pflash OVMF.fd -M q35 vmlinuz0 -s -S -daemonize
> $ gdb
> (gdb) target remote localhost:1234
> (gdb) hb *0x02858f6f
> Hardware assisted breakpoint 1 at 0x2858f6f
> (gdb) c
> Continuing.
> 
> Breakpoint 1, 0x02858f6f in ?? ()
> (gdb) monitor info registers
> ...
> GDT= 0724e000 00ff
> IDT= fffbb000 07ff
> CR0=0005003b CR2=ff896000 CR3=032b7000 CR4=0690
> ...
> 
> The page directory is sane:
> 
> (gdb) x/4wx 0x32b7000
> 0x32b7000:0x03398063  0x03399063  0x0339a063  
> 0x0339b063
> (gdb) x/4wx 0x3398000
> 0x3398000:0x0163  0x1163  0x2163  
> 0x3163
> (gdb) x/4wx 0x3399000
> 0x3399000:0x0043  0x00401003  0x00402003  
> 0x00403003
> 
> but our particular page directory entry is empty:
> 
> (gdb) x/1wx 0x32b7000 + (0x724e000 >> 22) * 4
> 0x32b7070:0x
> 
> [ It appears that you can skate past this issue if you don't receive
>   any interrupts while the bogus GDT pointer is loaded, or if you avoid
>   reloading the segment registers in general.
> 
>   Andy Lutomirski provides some additional insight:
> 
>"AFAICT it's entirely permissible for the GDTR and/or LDT
> descriptor to point to unmapped memory.  Any attempt to use them
> (segment loads, interrupts, IRET, etc) will try to access that memory
> as if the access came from CPL 0 and, if the access fails, will
> generate a valid page fault with CR2 pointing into the GDT or
> LDT."
> 
>   Up until commit 23a0d4e8fa6d ("efi: Disable interrupts around EFI
>   calls, not in the epilog/prolog calls") interrupts were disabled
>   around the prolog and epilog calls, and the functional GDT was
>   re-installed before interrupts were re-enabled.
> 
>   Which explains why no one has hit this issue until now. ]

Without testing the problematic scenario explicitly (32-bit UEFI
kernel), I think this patch and 26/91 should not be backported to
kernels that do not have 23a0d4e8fa6d.

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

Re: [PATCH 3.12 25/91] x86/setup: Extend low identity map to cover whole kernel range

2016-01-06 Thread Matt Fleming 
On Wed, 06 Jan, at 11:47:20AM, Paolo Bonzini wrote:
> 
> Without testing the problematic scenario explicitly (32-bit UEFI
> kernel), I think this patch and 26/91 should not be backported to
> kernels that do not have 23a0d4e8fa6d.

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

Re: [PATCH 3.12 25/91] x86/setup: Extend low identity map to cover whole kernel range

2016-01-06 Thread Luis Henriques 
On Wed, Jan 06, 2016 at 11:00:31AM +, Matt Fleming wrote:
> On Wed, 06 Jan, at 11:47:20AM, Paolo Bonzini wrote:
> > 
> > Without testing the problematic scenario explicitly (32-bit UEFI
> > kernel), I think this patch and 26/91 should not be backported to
> > kernels that do not have 23a0d4e8fa6d.
> 
> I tend to agree.

I can see these 2 commits in kernels as old as 3.10 (which definitely do
not include 23a0d4e8fa6d).  Does this mean these should be reverted from
stable kernels that already include these patches?  Or would you rather
recommend to backport 23a0d4e8fa6d?

Cheers,
--
Luís
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3.12 25/91] x86/setup: Extend low identity map to cover whole kernel range

2016-01-06 Thread Paolo Bonzini 
This bug

On 05/01/2016 18:46, Jiri Slaby wrote:
> From: Paolo Bonzini 
> 
> 3.12-stable review patch.  If anyone has any objections, please let me know.
> 
> ===
> 
> commit f5f3497cad8c8416a74b9aaceb127908755d020a upstream.
> 
> On 32-bit systems, the initial_page_table is reused by
> efi_call_phys_prolog as an identity map to call
> SetVirtualAddressMap.  efi_call_phys_prolog takes care of
> converting the current CPU's GDT to a physical address too.
> 
> For PAE kernels the identity mapping is achieved by aliasing the
> first PDPE for the kernel memory mapping into the first PDPE
> of initial_page_table.  This makes the EFI stub's trick "just work".
> 
> However, for non-PAE kernels there is no guarantee that the identity
> mapping in the initial_page_table extends as far as the GDT; in this
> case, accesses to the GDT will cause a page fault (which quickly becomes
> a triple fault).  Fix this by copying the kernel mappings from
> swapper_pg_dir to initial_page_table twice, both at PAGE_OFFSET and at
> identity mapping.
> 
> For some reason, this is only reproducible with QEMU's dynamic translation
> mode, and not for example with KVM.  However, even under KVM one can clearly
> see that the page table is bogus:
> 
> $ qemu-system-i386 -pflash OVMF.fd -M q35 vmlinuz0 -s -S -daemonize
> $ gdb
> (gdb) target remote localhost:1234
> (gdb) hb *0x02858f6f
> Hardware assisted breakpoint 1 at 0x2858f6f
> (gdb) c
> Continuing.
> 
> Breakpoint 1, 0x02858f6f in ?? ()
> (gdb) monitor info registers
> ...
> GDT= 0724e000 00ff
> IDT= fffbb000 07ff
> CR0=0005003b CR2=ff896000 CR3=032b7000 CR4=0690
> ...
> 
> The page directory is sane:
> 
> (gdb) x/4wx 0x32b7000
> 0x32b7000:0x03398063  0x03399063  0x0339a063  
> 0x0339b063
> (gdb) x/4wx 0x3398000
> 0x3398000:0x0163  0x1163  0x2163  
> 0x3163
> (gdb) x/4wx 0x3399000
> 0x3399000:0x0043  0x00401003  0x00402003  
> 0x00403003
> 
> but our particular page directory entry is empty:
> 
> (gdb) x/1wx 0x32b7000 + (0x724e000 >> 22) * 4
> 0x32b7070:0x
> 
> [ It appears that you can skate past this issue if you don't receive
>   any interrupts while the bogus GDT pointer is loaded, or if you avoid
>   reloading the segment registers in general.
> 
>   Andy Lutomirski provides some additional insight:
> 
>"AFAICT it's entirely permissible for the GDTR and/or LDT
> descriptor to point to unmapped memory.  Any attempt to use them
> (segment loads, interrupts, IRET, etc) will try to access that memory
> as if the access came from CPL 0 and, if the access fails, will
> generate a valid page fault with CR2 pointing into the GDT or
> LDT."
> 
>   Up until commit 23a0d4e8fa6d ("efi: Disable interrupts around EFI
>   calls, not in the epilog/prolog calls") interrupts were disabled
>   around the prolog and epilog calls, and the functional GDT was
>   re-installed before interrupts were re-enabled.
> 
>   Which explains why no one has hit this issue until now. ]

Without testing the problematic scenario explicitly (32-bit UEFI
kernel), I think this patch and 26/91 should not be backported to
kernels that do not have 23a0d4e8fa6d.

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

Re: [PATCH 3.12 25/91] x86/setup: Extend low identity map to cover whole kernel range

2016-01-06 Thread Matt Fleming 
On Wed, 06 Jan, at 11:24:55AM, Luis Henriques wrote:
> On Wed, Jan 06, 2016 at 11:00:31AM +, Matt Fleming wrote:
> > On Wed, 06 Jan, at 11:47:20AM, Paolo Bonzini wrote:
> > > 
> > > Without testing the problematic scenario explicitly (32-bit UEFI
> > > kernel), I think this patch and 26/91 should not be backported to
> > > kernels that do not have 23a0d4e8fa6d.
> > 
> > I tend to agree.
> 
> I can see these 2 commits in kernels as old as 3.10 (which definitely do
> not include 23a0d4e8fa6d).  Does this mean these should be reverted from
> stable kernels that already include these patches?  Or would you rather
> recommend to backport 23a0d4e8fa6d?

That depends on your appetite for risk ;-)

23a0d4e8fa6d does fix a legitimate bug, albeit one that no one seems
to have ever hit. Personally, I'd go for backporting 23a0d4e8fa6d.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3.12 25/91] x86/setup: Extend low identity map to cover whole kernel range

2016-01-06 Thread Luis Henriques 
[ Adding Greg and Kamal ]

On Wed, Jan 06, 2016 at 01:31:55PM +, Matt Fleming wrote:
> On Wed, 06 Jan, at 11:24:55AM, Luis Henriques wrote:
> > On Wed, Jan 06, 2016 at 11:00:31AM +, Matt Fleming wrote:
> > > On Wed, 06 Jan, at 11:47:20AM, Paolo Bonzini wrote:
> > > > 
> > > > Without testing the problematic scenario explicitly (32-bit UEFI
> > > > kernel), I think this patch and 26/91 should not be backported to
> > > > kernels that do not have 23a0d4e8fa6d.
> > > 
> > > I tend to agree.
> > 
> > I can see these 2 commits in kernels as old as 3.10 (which definitely do
> > not include 23a0d4e8fa6d).  Does this mean these should be reverted from
> > stable kernels that already include these patches?  Or would you rather
> > recommend to backport 23a0d4e8fa6d?
> 
> That depends on your appetite for risk ;-)
>

Heh, I guess stable kernels aren't really about appetite for risk :-)

> 23a0d4e8fa6d does fix a legitimate bug, albeit one that no one seems
> to have ever hit. Personally, I'd go for backporting 23a0d4e8fa6d.

This commit doesn't seem to be too bad to backport.  I'm attaching 2
backports:

 - one is for the 3.16 stable kernel,
 - the other can be applied to 3.10, 3.12 and 3.13

(For the other kernels, I believe 23a0d4e8fa6d will be a clean
cherry-pick.)

Cheers,
--
Luís
>From 6b58a852d51e7d1991d759c331bc276b2461c4c3 Mon Sep 17 00:00:00 2001
From: Ingo Molnar 
Date: Tue, 3 Mar 2015 07:34:33 +0100
Subject: efi: Disable interrupts around EFI calls, not in the epilog/prolog
 calls

commit 23a0d4e8fa6d3a1d7fb819f79bcc0a3739c30ba9 upstream.

Tapasweni Pathak reported that we do a kmalloc() in efi_call_phys_prolog()
on x86-64 while having interrupts disabled, which is a big no-no, as
kmalloc() can sleep.

Solve this by removing the irq disabling from the prolog/epilog calls
around EFI calls: it's unnecessary, as in this stage we are single
threaded in the boot thread, and we don't ever execute this from
interrupt contexts.

Reported-by: Tapasweni Pathak 
Signed-off-by: Ingo Molnar 
Signed-off-by: Matt Fleming 
[ luis: backported to 3.10: adjusted context ]
Signed-off-by: Luis Henriques 
---
 arch/x86/platform/efi/efi.c|  7 +++
 arch/x86/platform/efi/efi_32.c | 11 +++
 arch/x86/platform/efi/efi_64.c |  3 ---
 3 files changed, 10 insertions(+), 11 deletions(-)

diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 6033be9ff81a..3c8bffdc71c8 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -250,12 +250,19 @@ static efi_status_t __init phys_efi_set_virtual_address_map(
 	efi_memory_desc_t *virtual_map)
 {
 	efi_status_t status;
+	unsigned long flags;
 
 	efi_call_phys_prelog();
+
+	/* Disable interrupts around EFI calls: */
+	local_irq_save(flags);
 	status = efi_call_phys4(efi_phys.set_virtual_address_map,
 memory_map_size, descriptor_size,
 descriptor_version, virtual_map);
+	local_irq_restore(flags);
+
 	efi_call_phys_epilog();
+
 	return status;
 }
 
diff --git a/arch/x86/platform/efi/efi_32.c b/arch/x86/platform/efi/efi_32.c
index 40e446941dd7..bebbee05e331 100644
--- a/arch/x86/platform/efi/efi_32.c
+++ b/arch/x86/platform/efi/efi_32.c
@@ -33,19 +33,16 @@
 
 /*
  * To make EFI call EFI runtime service in physical addressing mode we need
- * prelog/epilog before/after the invocation to disable interrupt, to
- * claim EFI runtime service handler exclusively and to duplicate a memory in
- * low memory space say 0 - 3G.
+ * prolog/epilog before/after the invocation to claim the EFI runtime service
+ * handler exclusively and to duplicate a memory mapping in low memory space,
+ * say 0 - 3G.
  */
 
-static unsigned long efi_rt_eflags;
 
 void efi_call_phys_prelog(void)
 {
 	struct desc_ptr gdt_descr;
 
-	local_irq_save(efi_rt_eflags);
-
 	load_cr3(initial_page_table);
 	__flush_tlb_all();
 
@@ -64,6 +61,4 @@ void efi_call_phys_epilog(void)
 
 	load_cr3(swapper_pg_dir);
 	__flush_tlb_all();
-
-	local_irq_restore(efi_rt_eflags);
 }
diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index 39a0e7f1f0a3..2f6c1a9734c8 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -40,7 +40,6 @@
 #include 
 
 static pgd_t *save_pgd __initdata;
-static unsigned long efi_flags __initdata;
 
 static void __init early_code_mapping_set_exec(int executable)
 {
@@ -66,7 +65,6 @@ void __init efi_call_phys_prelog(void)
 	int n_pgds;
 
 	early_code_mapping_set_exec(1);
-	local_irq_save(efi_flags);
 
 	n_pgds = DIV_ROUND_UP((max_pfn << PAGE_SHIFT), PGDIR_SIZE);
 	save_pgd = kmalloc(n_pgds * sizeof(pgd_t), GFP_KERNEL);
@@ -90,7 +88,6 @@ void __init efi_call_phys_epilog(void)
 		set_pgd(pgd_offset_k(pgd * PGDIR_SIZE), save_pgd[pgd]);
 	kfree(save_pgd);
 	__flush_tlb_all();
-	local_irq_restore(efi_flags);
 	early_code_mapping_set_exec(0);
 }
 
>From