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:   Wed, 23 May 2018 15:10:22 -0400
From:   Luiz Capitulino <lcapitulino@...hat.com>
To:     Baoquan He <bhe@...hat.com>
Cc:     Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org,
        keescook@...omium.org, tglx@...utronix.de, x86@...nel.org,
        hpa@...or.com, fanc.fnst@...fujitsu.com, yasu.isimatu@...il.com,
        indou.takao@...fujitsu.com, douly.fnst@...fujitsu.com
Subject: Re: [PATCH 0/2] x86/boot/KASLR: Skip specified number of 1GB huge
 pages when do physical randomization

On Fri, 18 May 2018 19:28:36 +0800
Baoquan He <bhe@...hat.com> wrote:

> > Note that it's not KASLR specific: if we had some other kernel feature that tried 
> > to allocate a piece of memory from what appears to be perfectly usable generic RAM 
> > we'd have the same problems!  
> 
> Hmm, this may not be the situation for 1GB huge pages. For 1GB huge
> pages, the bug is that on KVM guest with 4GB ram, when user adds
> 'default_hugepagesz=1G hugepagesz=1G hugepages=1' to kernel
> command-line, if 'nokaslr' is specified, they can get 1GB huge page
> allocated successfully. If remove 'nokaslr', namely KASLR is enabled,
> the 1GB huge page allocation failed.

Let me clarify that this issue is not specific to KVM in any way. The same
issue happens on bare-metal, but if you have lots of memory you'll hardly
notice it. On the other hand, it's common to create KVM guests with a few
GBs of memory. In those guests, you may not be able to get a 1GB hugepage
at all if kaslr is enabled.

This series is a simple fix for this bug. It hooks up into already existing
KASLR code that scans memory regions to be avoided. The memory hotplug
issue is left for another day.

Now, if I understand what Ingo is saying is that he wants to see all problems
solved with a generic solution vs. a specific solution for each problem.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ