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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 20 Feb 2008 22:29:57 +0000
From:	Ian Campbell <ijc@...lion.org.uk>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
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


On Wed, 2008-02-20 at 13:58 -0800, Jeremy Fitzhardinge wrote:
> Ian Campbell wrote:
> > On Tue, 2008-02-19 at 23:43 -0800, H. Peter Anvin wrote:
> >   
> >> Ian Campbell wrote:
> >>     
> >>> On Mon, 2008-02-18 at 02:40 -0800, Joel Becker wrote:
> >>>       
> >>>> On Sun, Feb 17, 2008 at 06:49:21PM +0000, Ian Campbell wrote:
> >>>>         
> >>>>> x86/xen: Do not scan for DMI unless the DMI region is reserved by e820.
> >>>>>           
> >>>> 	This fixed it.  I'm now booting successfully.  Thank you!
> >>>>         
> >>> Excellent. Jeremy, are you happy for this to go in?
> >>>       
> 
> I had no problem with it, but Peter's objection seems substantial enough.

Definitely.

> > As far as the actual change goes I was assuming that any machine that
> > has DMI/SMBIOS would easily be new enough to have an E820 which could be
> > expected to reserve this region. Looks like I was mistaken about how
> > long E820 had been around and/or how reliably it is used to reserve the
> > tables.
> >
> > Anyway, will have to think of another solution.
> >   
> 
> Well, the way we've handled this kind of thing elsewhere is to just 
> reserve that pseudophys address space in earlish Xen init code and fill 
> it with not-DMI things (zero, I guess).  It's a bit of a waste of 
> memory, but maybe we can recover it once DMI has given up and gone 
> away.  This also makes it easy to insert faked-up DMI info if that turns 
> out to be useful.

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.

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).

Ian.
-- 
Ian Campbell

Universe, n.:
	The problem.

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