Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1461757 > unrolled thread

Re: [tip:x86/boot] x86/mm: Enable KASLR for physical mapping memory regions

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [tip:x86/boot] x86/mm: Enable KASLR for physical mapping memory regions Brian Gerst <brgerst@gmail.com> - 2016-08-14 11:50 +0200
    Re: [tip:x86/boot] x86/mm: Enable KASLR for physical mapping memory  regions Baoquan He <bhe@redhat.com> - 2016-08-15 01:30 +0200
      Re: [tip:x86/boot] x86/mm: Enable KASLR for physical mapping memory regions Brian Gerst <brgerst@gmail.com> - 2016-08-16 13:40 +0200
        Re: [tip:x86/boot] x86/mm: Enable KASLR for physical mapping memory  regions Borislav Petkov <bp@alien8.de> - 2016-08-16 15:50 +0200
          Re: [tip:x86/boot] x86/mm: Enable KASLR for physical mapping memory  regions Borislav Petkov <bp@alien8.de> - 2016-08-16 15:50 +0200
            Re: [tip:x86/boot] x86/mm: Enable KASLR for physical mapping memory  regions Borislav Petkov <bp@alien8.de> - 2016-08-16 18:00 +0200
              Re: [tip:x86/boot] x86/mm: Enable KASLR for physical mapping memory  regions Borislav Petkov <bp@alien8.de> - 2016-08-16 20:00 +0200
                Re: [tip:x86/boot] x86/mm: Enable KASLR for physical mapping memory regions Kees Cook <keescook@chromium.org> - 2016-08-16 22:00 +0200
                  Re: [tip:x86/boot] x86/mm: Enable KASLR for physical mapping memory  regions Borislav Petkov <bp@alien8.de> - 2016-08-16 23:20 +0200
                    Re: [tip:x86/boot] x86/mm: Enable KASLR for physical mapping memory regions Brian Gerst <brgerst@gmail.com> - 2016-08-17 02:40 +0200
                      Re: [tip:x86/boot] x86/mm: Enable KASLR for physical mapping memory  regions Borislav Petkov <bp@alien8.de> - 2016-08-17 11:20 +0200
                        Re: [tip:x86/boot] x86/mm: Enable KASLR for physical mapping memory  regions Ingo Molnar <mingo@kernel.org> - 2016-08-17 12:30 +0200
                          Re: [tip:x86/boot] x86/mm: Enable KASLR for physical mapping memory  regions Borislav Petkov <bp@alien8.de> - 2016-08-17 13:40 +0200
                            [tip:x86/urgent] x86/microcode/AMD: Fix initrd loading with  CONFIG_RANDOMIZE_MEMORY=y tip-bot for Borislav Petkov <tipbot@zytor.com> - 2016-08-18 13:00 +0200

#1461757 — Re: [tip:x86/boot] x86/mm: Enable KASLR for physical mapping memory regions

On Fri, Jul 8, 2016 at 4:35 PM, tip-bot for Thomas Garnier
<tipbot@zytor.com> wrote:
> Commit-ID:  021182e52fe01c1f7b126f97fd6ba048dc4234fd
> Gitweb:     http://git.kernel.org/tip/021182e52fe01c1f7b126f97fd6ba048dc4234fd
> Author:     Thomas Garnier <thgarnie@google.com>
> AuthorDate: Tue, 21 Jun 2016 17:47:03 -0700
> Committer:  Ingo Molnar <mingo@kernel.org>
> CommitDate: Fri, 8 Jul 2016 17:35:15 +0200
>
> x86/mm: Enable KASLR for physical mapping memory regions
>
> Add the physical mapping in the list of randomized memory regions.
>
> The physical memory mapping holds most allocations from boot and heap
> allocators. Knowing the base address and physical memory size, an attacker
> can deduce the PDE virtual address for the vDSO memory page. This attack
> was demonstrated at CanSecWest 2016, in the following presentation:
>
>   "Getting Physical: Extreme Abuse of Intel Based Paged Systems":
>   https://github.com/n3k/CansecWest2016_Getting_Physical_Extreme_Abuse_of_Intel_Based_Paging_Systems/blob/master/Presentation/CanSec2016_Presentation.pdf
>
> (See second part of the presentation).
>
> The exploits used against Linux worked successfully against 4.6+ but
> fail with KASLR memory enabled:
>
>   https://github.com/n3k/CansecWest2016_Getting_Physical_Extreme_Abuse_of_Intel_Based_Paging_Systems/tree/master/Demos/Linux/exploits
>
> Similar research was done at Google leading to this patch proposal.
>
> Variants exists to overwrite /proc or /sys objects ACLs leading to
> elevation of privileges. These variants were tested against 4.6+.
>
> The page offset used by the compressed kernel retains the static value
> since it is not yet randomized during this boot stage.

This patch is causing my system to fail to boot.  The last messages
that are printed before it hangs are:

[    0.195652] smpboot: CPU0: AMD Phenom(tm) II X6 1055T Processor
(family: 0x10, model: 0xa, stepping: 0x0)
[    0.195656] Performance Events: AMD PMU driver.
[    0.195659] ... version:                0
[    0.195660] ... bit width:              48
[    0.195660] ... generic registers:      4
[    0.195661] ... value mask:             0000ffffffffffff
[    0.195662] ... max period:             00007fffffffffff
[    0.195663] ... fixed-purpose events:   0
[    0.195664] ... event mask:             000000000000000f
[    0.196185] NMI watchdog: enabled on all CPUs, permanently consumes
one hw-PMU counter.
[    0.196291] x86: Booting SMP configuration:
[    0.196292] .... node  #0, CPUs:      #1

I'm taking a guess here, but it may be that this is interfering with
the APIC accesses.

--
Brian Gerst

[toc] | [next] | [standalone]

#1462503 — Re: [tip:x86/boot] x86/mm: Enable KASLR for physical mapping memory regions

On 08/14/16 at 12:25am, Brian Gerst wrote:
> On Fri, Jul 8, 2016 at 4:35 PM, tip-bot for Thomas Garnier
> <tipbot@zytor.com> wrote:
> > Commit-ID:  021182e52fe01c1f7b126f97fd6ba048dc4234fd
> > Gitweb:     http://git.kernel.org/tip/021182e52fe01c1f7b126f97fd6ba048dc4234fd
> > Author:     Thomas Garnier <thgarnie@google.com>
> > AuthorDate: Tue, 21 Jun 2016 17:47:03 -0700
> > Committer:  Ingo Molnar <mingo@kernel.org>
> > CommitDate: Fri, 8 Jul 2016 17:35:15 +0200
> >
> > x86/mm: Enable KASLR for physical mapping memory regions
> >
> > Add the physical mapping in the list of randomized memory regions.
> >
> > The physical memory mapping holds most allocations from boot and heap
> > allocators. Knowing the base address and physical memory size, an attacker
> > can deduce the PDE virtual address for the vDSO memory page. This attack
> > was demonstrated at CanSecWest 2016, in the following presentation:
> >
> >   "Getting Physical: Extreme Abuse of Intel Based Paged Systems":
> >   https://github.com/n3k/CansecWest2016_Getting_Physical_Extreme_Abuse_of_Intel_Based_Paging_Systems/blob/master/Presentation/CanSec2016_Presentation.pdf
> >
> > (See second part of the presentation).
> >
> > The exploits used against Linux worked successfully against 4.6+ but
> > fail with KASLR memory enabled:
> >
> >   https://github.com/n3k/CansecWest2016_Getting_Physical_Extreme_Abuse_of_Intel_Based_Paging_Systems/tree/master/Demos/Linux/exploits
> >
> > Similar research was done at Google leading to this patch proposal.
> >
> > Variants exists to overwrite /proc or /sys objects ACLs leading to
> > elevation of privileges. These variants were tested against 4.6+.
> >
> > The page offset used by the compressed kernel retains the static value
> > since it is not yet randomized during this boot stage.
> 
> This patch is causing my system to fail to boot.  The last messages
> that are printed before it hangs are:
> 
> [    0.195652] smpboot: CPU0: AMD Phenom(tm) II X6 1055T Processor
> (family: 0x10, model: 0xa, stepping: 0x0)
> [    0.195656] Performance Events: AMD PMU driver.
> [    0.195659] ... version:                0
> [    0.195660] ... bit width:              48
> [    0.195660] ... generic registers:      4
> [    0.195661] ... value mask:             0000ffffffffffff
> [    0.195662] ... max period:             00007fffffffffff
> [    0.195663] ... fixed-purpose events:   0
> [    0.195664] ... event mask:             000000000000000f
> [    0.196185] NMI watchdog: enabled on all CPUs, permanently consumes
> one hw-PMU counter.
> [    0.196291] x86: Booting SMP configuration:
> [    0.196292] .... node  #0, CPUs:      #1
> 
> I'm taking a guess here, but it may be that this is interfering with
> the APIC accesses.

Seems it hang when startup 2nd cpu. It may give more information if
add below line to the beginning of arch/x86/kernel/smpboot.c and
rebuild bzImage.

#define DEBUG

> 
> --
> Brian Gerst

[toc] | [prev] | [next] | [standalone]

#1463723

On Sun, Aug 14, 2016 at 7:26 PM, Baoquan He <bhe@redhat.com> wrote:
> On 08/14/16 at 12:25am, Brian Gerst wrote:
>> On Fri, Jul 8, 2016 at 4:35 PM, tip-bot for Thomas Garnier
>> <tipbot@zytor.com> wrote:
>> > Commit-ID:  021182e52fe01c1f7b126f97fd6ba048dc4234fd
>> > Gitweb:     http://git.kernel.org/tip/021182e52fe01c1f7b126f97fd6ba048dc4234fd
>> > Author:     Thomas Garnier <thgarnie@google.com>
>> > AuthorDate: Tue, 21 Jun 2016 17:47:03 -0700
>> > Committer:  Ingo Molnar <mingo@kernel.org>
>> > CommitDate: Fri, 8 Jul 2016 17:35:15 +0200
>> >
>> > x86/mm: Enable KASLR for physical mapping memory regions
>> >
>> > Add the physical mapping in the list of randomized memory regions.
>> >
>> > The physical memory mapping holds most allocations from boot and heap
>> > allocators. Knowing the base address and physical memory size, an attacker
>> > can deduce the PDE virtual address for the vDSO memory page. This attack
>> > was demonstrated at CanSecWest 2016, in the following presentation:
>> >
>> >   "Getting Physical: Extreme Abuse of Intel Based Paged Systems":
>> >   https://github.com/n3k/CansecWest2016_Getting_Physical_Extreme_Abuse_of_Intel_Based_Paging_Systems/blob/master/Presentation/CanSec2016_Presentation.pdf
>> >
>> > (See second part of the presentation).
>> >
>> > The exploits used against Linux worked successfully against 4.6+ but
>> > fail with KASLR memory enabled:
>> >
>> >   https://github.com/n3k/CansecWest2016_Getting_Physical_Extreme_Abuse_of_Intel_Based_Paging_Systems/tree/master/Demos/Linux/exploits
>> >
>> > Similar research was done at Google leading to this patch proposal.
>> >
>> > Variants exists to overwrite /proc or /sys objects ACLs leading to
>> > elevation of privileges. These variants were tested against 4.6+.
>> >
>> > The page offset used by the compressed kernel retains the static value
>> > since it is not yet randomized during this boot stage.
>>
>> This patch is causing my system to fail to boot.  The last messages
>> that are printed before it hangs are:
>>
>> [    0.195652] smpboot: CPU0: AMD Phenom(tm) II X6 1055T Processor
>> (family: 0x10, model: 0xa, stepping: 0x0)
>> [    0.195656] Performance Events: AMD PMU driver.
>> [    0.195659] ... version:                0
>> [    0.195660] ... bit width:              48
>> [    0.195660] ... generic registers:      4
>> [    0.195661] ... value mask:             0000ffffffffffff
>> [    0.195662] ... max period:             00007fffffffffff
>> [    0.195663] ... fixed-purpose events:   0
>> [    0.195664] ... event mask:             000000000000000f
>> [    0.196185] NMI watchdog: enabled on all CPUs, permanently consumes
>> one hw-PMU counter.
>> [    0.196291] x86: Booting SMP configuration:
>> [    0.196292] .... node  #0, CPUs:      #1
>>
>> I'm taking a guess here, but it may be that this is interfering with
>> the APIC accesses.
>
> Seems it hang when startup 2nd cpu. It may give more information if
> add below line to the beginning of arch/x86/kernel/smpboot.c and
> rebuild bzImage.
>
> #define DEBUG

That didn't provide any useful information.  However, when I boot with
"nosmp", I do get an oops in load_microcode_amd().  I can't capture
the oops message (no serial console), but it's being called from
save_microcode_in_initrd_amd().

--
Brian Gerst

[toc] | [prev] | [next] | [standalone]

#1463811 — Re: [tip:x86/boot] x86/mm: Enable KASLR for physical mapping memory regions

On Tue, Aug 16, 2016 at 07:31:20AM -0400, Brian Gerst wrote:
> That didn't provide any useful information.  However, when I boot with
> "nosmp", I do get an oops in load_microcode_amd().  I can't capture
> the oops message (no serial console), but it's being called from
> save_microcode_in_initrd_amd().

That is possible. KASLR already broke microcode loading on Intel. :-\

I'll try to reproduce and fix this at some point but am away currently
so don't hold your breath. Does "dis_ucode_ldr" on the kernel cmdline
get you any further?

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

[toc] | [prev] | [next] | [standalone]

#1463813 — Re: [tip:x86/boot] x86/mm: Enable KASLR for physical mapping memory regions

On Tue, Aug 16, 2016 at 03:42:05PM +0200, Borislav Petkov wrote:
> I'll try to reproduce and fix this at some point but am away currently
> so don't hold your breath. Does "dis_ucode_ldr" on the kernel cmdline
> get you any further?

Just a stab in the dark: does something like that help?

---
diff --git a/arch/x86/kernel/cpu/microcode/amd.c b/arch/x86/kernel/cpu/microcode/amd.c
index 27a0228c9cae..2debaf119baf 100644
--- a/arch/x86/kernel/cpu/microcode/amd.c
+++ b/arch/x86/kernel/cpu/microcode/amd.c
@@ -434,6 +434,10 @@ int __init save_microcode_in_initrd_amd(void)
 	else
 		container = cont_va;
 
+#ifdef CONFIG_RANDOMIZE_MEMORY
+	container += PAGE_OFFSET - __PAGE_OFFSET_BASE;
+#endif
+
 	eax   = cpuid_eax(0x00000001);
 	eax   = ((eax >> 8) & 0xf) + ((eax >> 20) & 0xff);
 
---

Thanks.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

[toc] | [prev] | [next] | [standalone]

#1463907 — Re: [tip:x86/boot] x86/mm: Enable KASLR for physical mapping memory regions

On Tue, Aug 16, 2016 at 03:49:28PM +0200, Borislav Petkov wrote:
> Just a stab in the dark: does something like that help?
> 
> ---
> diff --git a/arch/x86/kernel/cpu/microcode/amd.c b/arch/x86/kernel/cpu/microcode/amd.c
> index 27a0228c9cae..2debaf119baf 100644
> --- a/arch/x86/kernel/cpu/microcode/amd.c
> +++ b/arch/x86/kernel/cpu/microcode/amd.c
> @@ -434,6 +434,10 @@ int __init save_microcode_in_initrd_amd(void)
>  	else
>  		container = cont_va;
>  
> +#ifdef CONFIG_RANDOMIZE_MEMORY
> +	container += PAGE_OFFSET - __PAGE_OFFSET_BASE;
> +#endif
> +
>  	eax   = cpuid_eax(0x00000001);
>  	eax   = ((eax >> 8) & 0xf) + ((eax >> 20) & 0xff);
>  
> ---

Ok, I ran this in a guest and it finds the microcode patches properly.

My .config has:

CONFIG_ARCH_HAS_ELF_RANDOMIZE=y
CONFIG_RANDOMIZE_BASE=y
CONFIG_RANDOMIZE_MEMORY=y
CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING=0x0

When you run this, please check whether it really applies the microcode
on every core.

Thanks.

Without the above, I get:

[    0.432103] BUG: unable to handle kernel paging request at ffff88007fa5540c
[    0.436000] IP: [<ffffffffbc03ea8b>] load_microcode_amd+0x2b/0x3b0
[    0.436000] PGD 0 
[    0.436000] Oops: 0000 [#1] PREEMPT SMP
[    0.436000] Modules linked in:
[    0.436000] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.8.0-rc1+ #16
[    0.436000] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1 04/01/2014
[    0.436000] task: ffff9ebf7b460000 task.stack: ffff9ebf7bffc000
[    0.436000] RIP: 0010:[<ffffffffbc03ea8b>]  [<ffffffffbc03ea8b>] load_microcode_amd+0x2b/0x3b0
[    0.436000] RSP: 0018:ffff9ebf7bfffe08  EFLAGS: 00010246
[    0.436000] RAX: 0000000080000000 RBX: 0000000000000006 RCX: 0000000000001ec4
[    0.436000] RDX: ffff88007fa55408 RSI: 0000000000000015 RDI: 0000000000000000
[    0.436000] RBP: ffff9ebf7bfffe48 R08: ffff9ebf7b805960 R09: 0000000000000000
[    0.436000] R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000001ec4
[    0.436000] R13: ffff88007fa55408 R14: 0000000000000015 R15: 0000000000001ec4
[    0.436000] FS:  0000000000000000(0000) GS:ffff9ebf7e800000(0000) knlGS:0000000000000000
[    0.436000] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    0.436000] CR2: ffff88007fa5540c CR3: 0000000067c06000 CR4: 00000000000406f0
[    0.436000] Stack:
[    0.436000]  ffff9ebf7b805900 0000000000000246 0000000000000006 0000000000000006
[    0.436000]  0000000000000000 000000000000000f ffff88007fa55408 0000000000001ec4
[    0.436000]  ffff9ebf7bfffe80 ffffffffbcd49762 0000000000000000 00000000000000ee
[    0.436000] Call Trace:
[    0.436000]  [<ffffffffbcd49762>] save_microcode_in_initrd_amd+0xac/0xe0
[    0.436000]  [<ffffffffbcd49037>] ? microcode_init+0x1b1/0x1b1
[    0.436000]  [<ffffffffbcd49073>] save_microcode_in_initrd+0x3c/0x45
[    0.436000]  [<ffffffffbc000459>] do_one_initcall+0x59/0x190
[    0.436000]  [<ffffffffbc08ccc1>] ? parse_args+0x271/0x400
[    0.436000]  [<ffffffffbcd3d089>] kernel_init_freeable+0x118/0x19e
[    0.436000]  [<ffffffffbc76aa3e>] kernel_init+0xe/0x100
[    0.436000]  [<ffffffffbc7749ef>] ret_from_fork+0x1f/0x40
[    0.436000]  [<ffffffffbc76aa30>] ? rest_init+0x140/0x140
[    0.436000] Code: 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 89 f6 41 55 49 89 d5 41 54 49 89 cc 53 48 83 ec 18 48 8b 3d d2 d9 e2 00 e8 e5 15 18 00 <41> 8b 4d 04 48 c7 05 be d9 e2 00 00 00 00 00 41 8b 5d 08 85 c9 
[    0.436000] RIP  [<ffffffffbc03ea8b>] load_microcode_amd+0x2b/0x3b0
[    0.436000]  RSP <ffff9ebf7bfffe08>
[    0.436000] CR2: ffff88007fa5540c
[    0.436000] ---[ end trace 21a612b6619d1c00 ]---
[    0.436019] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
[    0.436019] 
[    0.438843] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
[    0.438843]

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

[toc] | [prev] | [next] | [standalone]

#1463977 — Re: [tip:x86/boot] x86/mm: Enable KASLR for physical mapping memory regions

On Tue, Aug 16, 2016 at 05:54:12PM +0200, Borislav Petkov wrote:
> Ok, I ran this in a guest and it finds the microcode patches properly.

Here's a better version to take care of the APs too:

---
diff --git a/arch/x86/kernel/cpu/microcode/amd.c b/arch/x86/kernel/cpu/microcode/amd.c
index 27a0228c9cae..05242322e324 100644
--- a/arch/x86/kernel/cpu/microcode/amd.c
+++ b/arch/x86/kernel/cpu/microcode/amd.c
@@ -355,6 +355,7 @@ void load_ucode_amd_ap(void)
 	unsigned int cpu = smp_processor_id();
 	struct equiv_cpu_entry *eq;
 	struct microcode_amd *mc;
+	u8 *cont;
 	u32 rev, eax;
 	u16 eq_id;
 
@@ -371,8 +372,12 @@ void load_ucode_amd_ap(void)
 	if (check_current_patch_level(&rev, false))
 		return;
 
+#ifdef CONFIG_RANDOMIZE_MEMORY
+	cont = container + PAGE_OFFSET - __PAGE_OFFSET_BASE;
+#endif
+
 	eax = cpuid_eax(0x00000001);
-	eq  = (struct equiv_cpu_entry *)(container + CONTAINER_HDR_SZ);
+	eq  = (struct equiv_cpu_entry *)(cont + CONTAINER_HDR_SZ);
 
 	eq_id = find_equiv_id(eq, eax);
 	if (!eq_id)
@@ -434,6 +439,10 @@ int __init save_microcode_in_initrd_amd(void)
 	else
 		container = cont_va;
 
+#ifdef CONFIG_RANDOMIZE_MEMORY
+	container += PAGE_OFFSET - __PAGE_OFFSET_BASE;
+#endif
+
 	eax   = cpuid_eax(0x00000001);
 	eax   = ((eax >> 8) & 0xf) + ((eax >> 20) & 0xff);
 

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

[toc] | [prev] | [next] | [standalone]

#1464035

On Tue, Aug 16, 2016 at 10:50 AM, Borislav Petkov <bp@alien8.de> wrote:
> On Tue, Aug 16, 2016 at 05:54:12PM +0200, Borislav Petkov wrote:
>> Ok, I ran this in a guest and it finds the microcode patches properly.
>
> Here's a better version to take care of the APs too:
>
> ---
> diff --git a/arch/x86/kernel/cpu/microcode/amd.c b/arch/x86/kernel/cpu/microcode/amd.c
> index 27a0228c9cae..05242322e324 100644
> --- a/arch/x86/kernel/cpu/microcode/amd.c
> +++ b/arch/x86/kernel/cpu/microcode/amd.c
> @@ -355,6 +355,7 @@ void load_ucode_amd_ap(void)
>         unsigned int cpu = smp_processor_id();
>         struct equiv_cpu_entry *eq;
>         struct microcode_amd *mc;
> +       u8 *cont;
>         u32 rev, eax;
>         u16 eq_id;
>
> @@ -371,8 +372,12 @@ void load_ucode_amd_ap(void)
>         if (check_current_patch_level(&rev, false))
>                 return;
>
> +#ifdef CONFIG_RANDOMIZE_MEMORY
> +       cont = container + PAGE_OFFSET - __PAGE_OFFSET_BASE;
> +#endif
> +
>         eax = cpuid_eax(0x00000001);
> -       eq  = (struct equiv_cpu_entry *)(container + CONTAINER_HDR_SZ);
> +       eq  = (struct equiv_cpu_entry *)(cont + CONTAINER_HDR_SZ);

Am I misreading this? Shouldn't it be:

       cont = container;
#ifdef CONFIG_RANDOMIZE_MEMORY
       cont += PAGE_OFFSET - __PAGE_OFFSET_BASE;
#endif

(otherwise cont is undefined in the RANDOMIZE_MEMORY=n case?)

>
>         eq_id = find_equiv_id(eq, eax);
>         if (!eq_id)
> @@ -434,6 +439,10 @@ int __init save_microcode_in_initrd_amd(void)
>         else
>                 container = cont_va;
>
> +#ifdef CONFIG_RANDOMIZE_MEMORY
> +       container += PAGE_OFFSET - __PAGE_OFFSET_BASE;
> +#endif
> +
>         eax   = cpuid_eax(0x00000001);
>         eax   = ((eax >> 8) & 0xf) + ((eax >> 20) & 0xff);
>
>
> --
> Regards/Gruss,
>     Boris.
>
> ECO tip #101: Trim your mails when you reply.
> --


-Kees

-- 
Kees Cook
Nexus Security

[toc] | [prev] | [next] | [standalone]

#1464157 — Re: [tip:x86/boot] x86/mm: Enable KASLR for physical mapping memory regions

On Tue, Aug 16, 2016 at 12:49:52PM -0700, Kees Cook wrote:
> Am I misreading this?

No you're not.

> Shouldn't it be:
> 
>        cont = container;
> #ifdef CONFIG_RANDOMIZE_MEMORY
>        cont += PAGE_OFFSET - __PAGE_OFFSET_BASE;
> #endif
> 
> (otherwise cont is undefined in the RANDOMIZE_MEMORY=n case?)

Thanks for catching this Kees, I'll send a new version in the morning.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

[toc] | [prev] | [next] | [standalone]

#1464255

On Tue, Aug 16, 2016 at 5:01 PM, Borislav Petkov <bp@alien8.de> wrote:
> On Tue, Aug 16, 2016 at 12:49:52PM -0700, Kees Cook wrote:
>> Am I misreading this?
>
> No you're not.
>
>> Shouldn't it be:
>>
>>        cont = container;
>> #ifdef CONFIG_RANDOMIZE_MEMORY
>>        cont += PAGE_OFFSET - __PAGE_OFFSET_BASE;
>> #endif
>>
>> (otherwise cont is undefined in the RANDOMIZE_MEMORY=n case?)
>
> Thanks for catching this Kees, I'll send a new version in the morning.

These fixes work for my system.

--
Brian Gerst

[toc] | [prev] | [next] | [standalone]

#1464432 — Re: [tip:x86/boot] x86/mm: Enable KASLR for physical mapping memory regions

On Tue, Aug 16, 2016 at 08:31:28PM -0400, Brian Gerst wrote:
> These fixes work for my system.

Thanks Brian.

Ingo, please queue this into x86/urgent.

Thanks!

---
From: Borislav Petkov <bp@suse.de>
Date: Wed, 17 Aug 2016 08:23:29 +0200
Subject: [PATCH] x86/microcode/AMD: Fix initrd loading with CONFIG_RANDOMIZE_MEMORY=y

Similar to

  efaad554b4ff ("x86/microcode/intel: Fix initrd loading with CONFIG_RANDOMIZE_MEMORY=y")

fix microcode loading from the initrd on AMD by adding the randomization
offset to the microcode patch container within the initrd.

Reported-and-tested-by: Brian Gerst <brgerst@gmail.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Kees Cook <keescook@chromium.org>
---
 arch/x86/kernel/cpu/microcode/amd.c | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/microcode/amd.c b/arch/x86/kernel/cpu/microcode/amd.c
index 27a0228c9cae..f43b774d0684 100644
--- a/arch/x86/kernel/cpu/microcode/amd.c
+++ b/arch/x86/kernel/cpu/microcode/amd.c
@@ -355,6 +355,7 @@ void load_ucode_amd_ap(void)
 	unsigned int cpu = smp_processor_id();
 	struct equiv_cpu_entry *eq;
 	struct microcode_amd *mc;
+	u8 *cont;
 	u32 rev, eax;
 	u16 eq_id;
 
@@ -371,8 +372,14 @@ void load_ucode_amd_ap(void)
 	if (check_current_patch_level(&rev, false))
 		return;
 
+	cont = container;
+
+#ifdef CONFIG_RANDOMIZE_MEMORY
+	cont += PAGE_OFFSET - __PAGE_OFFSET_BASE;
+#endif
+
 	eax = cpuid_eax(0x00000001);
-	eq  = (struct equiv_cpu_entry *)(container + CONTAINER_HDR_SZ);
+	eq  = (struct equiv_cpu_entry *)(cont + CONTAINER_HDR_SZ);
 
 	eq_id = find_equiv_id(eq, eax);
 	if (!eq_id)
@@ -434,6 +441,10 @@ int __init save_microcode_in_initrd_amd(void)
 	else
 		container = cont_va;
 
+#ifdef CONFIG_RANDOMIZE_MEMORY
+	container += PAGE_OFFSET - __PAGE_OFFSET_BASE;
+#endif
+
 	eax   = cpuid_eax(0x00000001);
 	eax   = ((eax >> 8) & 0xf) + ((eax >> 20) & 0xff);
 
-- 
2.8.4

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

[toc] | [prev] | [next] | [standalone]

#1464485 — Re: [tip:x86/boot] x86/mm: Enable KASLR for physical mapping memory regions

* Borislav Petkov <bp@alien8.de> wrote:

> On Tue, Aug 16, 2016 at 08:31:28PM -0400, Brian Gerst wrote:
> > These fixes work for my system.
> 
> Thanks Brian.
> 
> Ingo, please queue this into x86/urgent.
> 
> Thanks!
> 
> ---
> From: Borislav Petkov <bp@suse.de>
> Date: Wed, 17 Aug 2016 08:23:29 +0200
> Subject: [PATCH] x86/microcode/AMD: Fix initrd loading with CONFIG_RANDOMIZE_MEMORY=y
> 
> Similar to
> 
>   efaad554b4ff ("x86/microcode/intel: Fix initrd loading with CONFIG_RANDOMIZE_MEMORY=y")
> 
> fix microcode loading from the initrd on AMD by adding the randomization
> offset to the microcode patch container within the initrd.
> 
> Reported-and-tested-by: Brian Gerst <brgerst@gmail.com>
> Signed-off-by: Borislav Petkov <bp@suse.de>
> Cc: Kees Cook <keescook@chromium.org>
> ---
>  arch/x86/kernel/cpu/microcode/amd.c | 13 ++++++++++++-
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kernel/cpu/microcode/amd.c b/arch/x86/kernel/cpu/microcode/amd.c
> index 27a0228c9cae..f43b774d0684 100644
> --- a/arch/x86/kernel/cpu/microcode/amd.c
> +++ b/arch/x86/kernel/cpu/microcode/amd.c
> @@ -355,6 +355,7 @@ void load_ucode_amd_ap(void)
>  	unsigned int cpu = smp_processor_id();
>  	struct equiv_cpu_entry *eq;
>  	struct microcode_amd *mc;
> +	u8 *cont;
>  	u32 rev, eax;
>  	u16 eq_id;
>  
> @@ -371,8 +372,14 @@ void load_ucode_amd_ap(void)
>  	if (check_current_patch_level(&rev, false))
>  		return;
>  
> +	cont = container;
> +
> +#ifdef CONFIG_RANDOMIZE_MEMORY
> +	cont += PAGE_OFFSET - __PAGE_OFFSET_BASE;
> +#endif
> +
>  	eax = cpuid_eax(0x00000001);
> -	eq  = (struct equiv_cpu_entry *)(container + CONTAINER_HDR_SZ);
> +	eq  = (struct equiv_cpu_entry *)(cont + CONTAINER_HDR_SZ);
>  
>  	eq_id = find_equiv_id(eq, eax);
>  	if (!eq_id)
> @@ -434,6 +441,10 @@ int __init save_microcode_in_initrd_amd(void)
>  	else
>  		container = cont_va;
>  
> +#ifdef CONFIG_RANDOMIZE_MEMORY
> +	container += PAGE_OFFSET - __PAGE_OFFSET_BASE;
> +#endif
> +
>  	eax   = cpuid_eax(0x00000001);
>  	eax   = ((eax >> 8) & 0xf) + ((eax >> 20) & 0xff);

So I really hate this pattern, and we already have it in 
arch/x86/kernel/cpu/microcode/intel.c as well:

                start += PAGE_OFFSET - __PAGE_OFFSET_BASE;

and note that it's not #ifdefed there - I think it's safe to leave out the #ifdef?

Thanks,

	Ingo

[toc] | [prev] | [next] | [standalone]

#1464528 — Re: [tip:x86/boot] x86/mm: Enable KASLR for physical mapping memory regions

On Wed, Aug 17, 2016 at 12:19:48PM +0200, Ingo Molnar wrote:
> So I really hate this pattern, and we already have it in 
> arch/x86/kernel/cpu/microcode/intel.c as well:
> 
>                 start += PAGE_OFFSET - __PAGE_OFFSET_BASE;
> 
> and note that it's not #ifdefed there - I think it's safe to leave out the #ifdef?

Ah, yes, we got rid of the ifdeffery in:

  4a1a8e1b8f9f ("x86/asm, x86/microcode: Add __PAGE_OFFSET_BASE define on 32-bit")

So here's v2:

---
From: Borislav Petkov <bp@suse.de>
Date: Wed, 17 Aug 2016 08:23:29 +0200
Subject: [PATCH] x86/microcode/AMD: Fix initrd loading with
 CONFIG_RANDOMIZE_MEMORY=y

Similar to

  efaad554b4ff ("x86/microcode/intel: Fix initrd loading with CONFIG_RANDOMIZE_MEMORY=y")

fix microcode loading from the initrd on AMD by adding the randomization
offset to the microcode patch container within the initrd.

Reported-and-tested-by: Brian Gerst <brgerst@gmail.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Kees Cook <keescook@chromium.org>
---
 arch/x86/kernel/cpu/microcode/amd.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/microcode/amd.c b/arch/x86/kernel/cpu/microcode/amd.c
index 27a0228c9cae..b816971f5da4 100644
--- a/arch/x86/kernel/cpu/microcode/amd.c
+++ b/arch/x86/kernel/cpu/microcode/amd.c
@@ -355,6 +355,7 @@ void load_ucode_amd_ap(void)
 	unsigned int cpu = smp_processor_id();
 	struct equiv_cpu_entry *eq;
 	struct microcode_amd *mc;
+	u8 *cont = container;
 	u32 rev, eax;
 	u16 eq_id;
 
@@ -371,8 +372,11 @@ void load_ucode_amd_ap(void)
 	if (check_current_patch_level(&rev, false))
 		return;
 
+	/* Add CONFIG_RANDOMIZE_MEMORY offset. */
+	cont += PAGE_OFFSET - __PAGE_OFFSET_BASE;
+
 	eax = cpuid_eax(0x00000001);
-	eq  = (struct equiv_cpu_entry *)(container + CONTAINER_HDR_SZ);
+	eq  = (struct equiv_cpu_entry *)(cont + CONTAINER_HDR_SZ);
 
 	eq_id = find_equiv_id(eq, eax);
 	if (!eq_id)
@@ -434,6 +438,9 @@ int __init save_microcode_in_initrd_amd(void)
 	else
 		container = cont_va;
 
+	/* Add CONFIG_RANDOMIZE_MEMORY offset. */
+	container += PAGE_OFFSET - __PAGE_OFFSET_BASE;
+
 	eax   = cpuid_eax(0x00000001);
 	eax   = ((eax >> 8) & 0xf) + ((eax >> 20) & 0xff);
 
-- 
2.8.4

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

[toc] | [prev] | [next] | [standalone]

#1465153 — [tip:x86/urgent] x86/microcode/AMD: Fix initrd loading with CONFIG_RANDOMIZE_MEMORY=y

Commit-ID:  88b2f634028f1f38dcc3d412e10ff1f224976daa
Gitweb:     http://git.kernel.org/tip/88b2f634028f1f38dcc3d412e10ff1f224976daa
Author:     Borislav Petkov <bp@alien8.de>
AuthorDate: Wed, 17 Aug 2016 13:33:14 +0200
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Thu, 18 Aug 2016 10:06:49 +0200

x86/microcode/AMD: Fix initrd loading with CONFIG_RANDOMIZE_MEMORY=y

Similar to:

  efaad554b4ff ("x86/microcode/intel: Fix initrd loading with CONFIG_RANDOMIZE_MEMORY=y")

... fix microcode loading from the initrd on AMD by adding the
randomization offset to the microcode patch container within the initrd.

Reported-and-tested-by: Brian Gerst <brgerst@gmail.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-tip-commits@vger.kernel.org
Link: http://lkml.kernel.org/r/20160817113314.GA19221@nazgul.tnic
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 arch/x86/kernel/cpu/microcode/amd.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/microcode/amd.c b/arch/x86/kernel/cpu/microcode/amd.c
index 27a0228..b816971 100644
--- a/arch/x86/kernel/cpu/microcode/amd.c
+++ b/arch/x86/kernel/cpu/microcode/amd.c
@@ -355,6 +355,7 @@ void load_ucode_amd_ap(void)
 	unsigned int cpu = smp_processor_id();
 	struct equiv_cpu_entry *eq;
 	struct microcode_amd *mc;
+	u8 *cont = container;
 	u32 rev, eax;
 	u16 eq_id;
 
@@ -371,8 +372,11 @@ void load_ucode_amd_ap(void)
 	if (check_current_patch_level(&rev, false))
 		return;
 
+	/* Add CONFIG_RANDOMIZE_MEMORY offset. */
+	cont += PAGE_OFFSET - __PAGE_OFFSET_BASE;
+
 	eax = cpuid_eax(0x00000001);
-	eq  = (struct equiv_cpu_entry *)(container + CONTAINER_HDR_SZ);
+	eq  = (struct equiv_cpu_entry *)(cont + CONTAINER_HDR_SZ);
 
 	eq_id = find_equiv_id(eq, eax);
 	if (!eq_id)
@@ -434,6 +438,9 @@ int __init save_microcode_in_initrd_amd(void)
 	else
 		container = cont_va;
 
+	/* Add CONFIG_RANDOMIZE_MEMORY offset. */
+	container += PAGE_OFFSET - __PAGE_OFFSET_BASE;
+
 	eax   = cpuid_eax(0x00000001);
 	eax   = ((eax >> 8) & 0xf) + ((eax >> 20) & 0xff);
 

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web