linux-kernel - Re: 2.6.25-rc1 xen pvops regression

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]

Message-ID: <47BE0017.1020205@goop.org>
Date:	Thu, 21 Feb 2008 14:49:59 -0800
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	"H. Peter Anvin" <hpa@...or.com>
CC:	Ian Campbell <ijc@...lion.org.uk>,
	Joel Becker <Joel.Becker@...cle.com>,
	Jody Belka <lists-lkml@...b.org>, linux-kernel@...r.kernel.org,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Andi Kleen <andi@...stfloor.org>,
	Mika Penttila <mika.penttila@...umbus.fi>
Subject: Re: 2.6.25-rc1 xen pvops regression

H. Peter Anvin wrote:
> Ian Campbell wrote:
>> On Thu, 2008-02-21 at 13:37 -0800, Jeremy Fitzhardinge wrote:
>>> H. Peter Anvin wrote:
>>>>> Still curious about why a pagetable page is ending up in that 
>>>>> range though.  Seems like it shouldn't be possible, since we 
>>>>> shouldn't be allowed to allocate from those pages, at least until 
>>>>> the DMI probe has happened...  Unless the early allocator is only 
>>>>> excluded from e820 reserved pages, which would cause a problem on 
>>>>> systems which don't reserve the DMI space...  HPA?
>>>>>
>>>> I thought the problem was a Xen-provided pagetable from before 
>>>> Linux started? 
>>> Hm, I don't think so.  The domain-builder pagetable is put after the 
>>> kernel, so it shouldn't be under 1M.
>>
>> I can confirm that it is Linux which is allocating it. The call path:
>>         # xm create -c debian-x86_32p-1
>>         Using config file "/etc/xen/debian-x86_32p-1".
>>         Started domain debian-1
>>         xen_alloc_pt_init PFN f0
>>         Pid: 0, comm: swapper Not tainted 2.6.25-rc2 #68
>>          [<c02ecb6b>] xen_alloc_pt_init+0x4b/0x60
>>          [<c02f5e2b>] one_page_table_init+0x8b/0xf0
>>          [<c02f63df>] paging_init+0x3bf/0x520
>>          [<c02ee444>] setup_arch+0x2a4/0x410
>>          [<c02e9a64>] start_kernel+0x64/0x380
>>          [<c02efd7f>] cpu_detect+0x6f/0xf0
>>          [<c02ed1a1>] xen_start_kernel+0x2f1/0x310
>>          =======================
>>         Entering add_active_range(0, 0, 262144) 0 entries of 256 used
>>         Zone PFN ranges:
>>           DMA             0 ->     4096
>>
>
> What is the e820 information you feed the kernel?  We should only ever 
> allocate page tables out of available RAM, not any other type of 
> memory (reserved or not). 

The kernel gets a flat memory map; all memory is just plain RAM.  The 
problem is that we're allocating a normal page and turning it into a 
pagetable - so far so good.  Then the DMI code is randomly mapping that 
same page RW so it can scan it for DMI signatures, which Xen is preventing.

There are two immediate fixes:

   1. Only scan for DMI if the memory is reserved (rejected, because HPA
      says some machines don't reserve the DMI space).  Alternatively,
      don't bother scanning if booting under Xen.
   2. Make DMI map the memory RO so that Xen doesn't complain (which is
      sensible because DMI is ROM anyway).

But as far as I can tell, this shouldn't be happening anyway, and could 
happen on real hardware which doesn't reserve the DMI space.  It 
probably doesn't because initial pagetables on real hardware use large 
pages, and therefore allocate less memory for pagetable memory and 
therefore doesn't end up hitting the 0xf0000 region.  But that area 
should be excluded from the allocation pool.

    J
--
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/