linux-kernel - Re: [Xen-devel] Xen PV domain regression with KASLR enabled (kernel 3.16)

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:	Tue, 12 Aug 2014 10:28:05 -0700
From:	Kees Cook <keescook@...omium.org>
To:	Stefan Bader <stefan.bader@...onical.com>
Cc:	David Vrabel <david.vrabel@...rix.com>,
	"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [Xen-devel] Xen PV domain regression with KASLR enabled (kernel 3.16)

On Fri, Aug 8, 2014 at 7:35 AM, Stefan Bader <stefan.bader@...onical.com> wrote:
> On 08.08.2014 14:43, David Vrabel wrote:
>> On 08/08/14 12:20, Stefan Bader wrote:
>>> Unfortunately I have not yet figured out why this happens, but can confirm by
>>> compiling with or without CONFIG_RANDOMIZE_BASE being set that without KASLR all
>>> is ok, but with it enabled there are issues (actually a dom0 does not even boot
>>> as a follow up error).
>>>
>>> Details can be seen in [1] but basically this is always some portion of a
>>> vmalloc allocation failing after hitting a freshly allocated PTE space not being
>>> PTE_NONE (usually from a module load triggered by systemd-udevd). In the
>>> non-dom0 case this repeats many times but ends in a guest that allows login. In
>>> the dom0 case there is a more fatal error at some point causing a crash.
>>>
>>> I have not tried this for a normal PV guest but for dom0 it also does not help
>>> to add "nokaslr" to the kernel command-line.
>>
>> Maybe it's overlapping with regions of the virtual address space
>> reserved for Xen?  What the the VA that fails?
>>
>> David
>>
> Yeah, there is some code to avoid some regions of memory (like initrd). Maybe
> missing p2m tables? I probably need to add debugging to find the failing VA (iow
> not sure whether it might be somewhere in the stacktraces in the report).
>
> The kernel-command line does not seem to be looked at. It should put something
> into dmesg and that never shows up. Also today's random feature is other PV
> guests crashing after a bit somewhere in the check_for_corruption area...

Right now, the kaslr code just deals with initrd, cmdline, etc. If
there are other reserved regions that aren't listed in the e820, it'll
need to locate and skip them.

-Kees

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