linux-kernel - Re: kexec + ACPI in 2.6.19 (was: Re: kexec + USB storage in 2.6.19)

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] [day] [month] [year] [list]

Message-ID: <20070112184945.GC24291@localdomain>
Date:	Fri, 12 Jan 2007 20:49:45 +0200
From:	Dan Aloni <da-x@...atomic.org>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Linux Kernel List <linux-kernel@...r.kernel.org>
Subject: Re: kexec + ACPI in 2.6.19 (was: Re: kexec + USB storage in 2.6.19)

On Fri, Jan 12, 2007 at 10:33:34AM -0700, Eric W. Biederman wrote:
> > And I get:
> >
> > [ 1013.864201] PAGE ffff810001000000 (pfn=0): flags=0, count=0
> >
> > So at least no one is using that page. Still it is not clear why it
> > doesn't have the reserve flag turned on.
> 
> My hunch is that it might have something to do with the difference
> in the e820 map.  The original map reports that whole page as
> being usable while in the kexec case the memory from 0x100 is
> reported as being usable.  Perhaps someone has a rounding error?

I added this right at the beginning of sanitize_e820_map():

	for (i=0; i < *pnr_map; i++) {
		printk("index %d: addr=%llx, size=%llx, type=%d\n",
		       i, 
		       (unsigned long long)biosmap[i].addr, 
		       (unsigned long long)biosmap[i].size, 
		       (unsigned int)biosmap[i].type);
	}

.. and got (kexec boot):

[    0.000000] index 0: addr=100, size=9b700, type=1
[    0.000000] index 1: addr=9b800, size=4800, type=2
[    0.000000] index 2: addr=100000, size=cfe70000, type=1
[    0.000000] index 3: addr=cff70000, size=8000, type=3
[    0.000000] index 4: addr=cff78000, size=8000, type=4
[    0.000000] index 5: addr=cff80000, size=80000, type=2
[    0.000000] index 6: addr=e0000000, size=10000000, type=2
[    0.000000] index 7: addr=fec00000, size=10000, type=2
[    0.000000] index 8: addr=fee00000, size=1000, type=2
[    0.000000] index 9: addr=ff800000, size=400000, type=2
[    0.000000] index 10: addr=fffffc00, size=400, type=2
[    0.000000] index 11: addr=100000000, size=30000000, type=1

Compared with a normal boot:

[    0.000000] index 0: addr=0, size=9b800, type=1
[    0.000000] index 1: addr=9b800, size=4800, type=2
[    0.000000] index 2: addr=e4000, size=1c000, type=2
[    0.000000] index 3: addr=100000, size=cfe70000, type=1
[    0.000000] index 4: addr=cff70000, size=8000, type=3
[    0.000000] index 5: addr=cff78000, size=8000, type=4
[    0.000000] index 6: addr=cff80000, size=80000, type=2
[    0.000000] index 7: addr=e0000000, size=10000000, type=2
[    0.000000] index 8: addr=fec00000, size=10000, type=2
[    0.000000] index 9: addr=fee00000, size=1000, type=2
[    0.000000] index 10: addr=ff800000, size=400000, type=2
[    0.000000] index 11: addr=fffffc00, size=400, type=2
[    0.000000] index 12: addr=100000000, size=30000000, type=1

So that is the actual boot data that is passed to us.

Anyway, if I add this:

	if (*pnr_map >= 1) {
		if (biosmap[0].addr == 0x100)
			biosmap[0].addr = 0;
	}

kexec works. I'll use this for now, but obviously we _must_ come up 
with a cleaner fix...		   

-- 
Dan Aloni
XIV LTD, http://www.xivstorage.com
da-x (at) monatomic.org, dan (at) xiv.co.il
-
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/