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

[Brian Gerst]

On Sun, Aug 14, 2016 at 7:26 PM, Baoquan He <bhe@xxxxxxxxxx> 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@xxxxxxxxx> wrote:
>> > Commit-ID:  021182e52fe01c1f7b126f97fd6ba048dc4234fd
>> > Gitweb:     http://git.kernel.org/tip/021182e52fe01c1f7b126f97fd6ba048dc4234fd
>> > Author:     Thomas Garnier <thgarnie@xxxxxxxxxx>
>> > AuthorDate: Tue, 21 Jun 2016 17:47:03 -0700
>> > Committer:  Ingo Molnar <mingo@xxxxxxxxxx>
>> > 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