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: <47BDEA11.6010302@goop.org>
Date:	Thu, 21 Feb 2008 13:16:01 -0800
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Ian Campbell <ijc@...lion.org.uk>
CC:	"H. Peter Anvin" <hpa@...or.com>,
	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

Ian Campbell wrote:
> I'll see if I can track down where the page is getting used and have a
> go at getting in there first. It must be pretty early to be allocated
> already when dmi_scan_machine gets called.
>
> It's possible that the domain builder might have already allocated a PT
> at this address. I haven't checked but I think currently the domain
> builder always puts PT pages after the kernel so hopefully it's only a
> theoretical problem.
>   

Yes, it does.  And presumably the early pagetable builder is guaranteed 
to avoid special memory like the DMI space.  But the bug definitely 
seems to be a result of the DMI code trying to make a RW mapping of a 
pagetable page, so something is amiss there.

Ooh, sleazy hack idea: make DMI always map RO, so even if it does get a 
pagetable it causes no complaint...  A bit awkward, since there doesn't 
seem to be an RO form of early_ioremap.

> Another option I was thinking of was a command line option to disable
> DMI, which (maybe) isn't terribly useful in itself but it introduces an
> associated variable to frob with. That's similar to how the TSC was
> handled in the past (well, the opposite since TSC was forced on).
>   

Yep, that would work too.

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?

    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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ