From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753576AbcHPLbY (ORCPT ); Tue, 16 Aug 2016 07:31:24 -0400 Received: from mail-oi0-f65.google.com ([209.85.218.65]:34373 "EHLO mail-oi0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752323AbcHPLbW (ORCPT ); Tue, 16 Aug 2016 07:31:22 -0400 MIME-Version: 1.0 In-Reply-To: <20160814232657.GA10704@x1.redhat.com> References: <1466556426-32664-7-git-send-email-keescook@chromium.org> <20160814232657.GA10704@x1.redhat.com> From: Brian Gerst Date: Tue, 16 Aug 2016 07:31:20 -0400 Message-ID: Subject: Re: [tip:x86/boot] x86/mm: Enable KASLR for physical mapping memory regions To: Baoquan He Cc: Borislav Petkov , Yinghai Lu , Juergen Gross , Thomas Garnier , Andy Lutomirski , "H. Peter Anvin" , Alexander Kuleshov , Josh Poimboeuf , borntraeger@de.ibm.com, sds@tycho.nsa.gov, kirill.shutemov@linux.intel.com, jroedel@suse.de, Kees Cook , "Williams, Dan J" , Mark Salter , Borislav Petkov , Jonathan Corbet , matt@codeblueprint.co.uk, guangrong.xiao@linux.intel.com, aneesh.kumar@linux.vnet.ibm.com, Ingo Molnar , Linus Torvalds , Dave Hansen , toshi.kani@hpe.com, alpopov@ptsecurity.com, Linux Kernel Mailing List , Jan Beulich , Andrew Morton , Boris Ostrovsky , Denys Vlasenko , Peter Zijlstra , dyoung@redhat.com, Thomas Gleixner , Dmitry Vyukov , lv.zheng@intel.com, schwidefsky@de.ibm.com, linux-tip-commits@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Aug 14, 2016 at 7:26 PM, Baoquan He 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 >> wrote: >> > Commit-ID: 021182e52fe01c1f7b126f97fd6ba048dc4234fd >> > Gitweb: http://git.kernel.org/tip/021182e52fe01c1f7b126f97fd6ba048dc4234fd >> > Author: Thomas Garnier >> > AuthorDate: Tue, 21 Jun 2016 17:47:03 -0700 >> > Committer: Ingo Molnar >> > 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