linux-kernel - Re: [GIT PULL] Small Xen bugfixes

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]

Message-ID: <4CCD9935.50308@goop.org>
Date:	Sun, 31 Oct 2010 09:28:37 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Ian Campbell <Ian.Campbell@...citrix.com>
CC:	Linus Torvalds <torvalds@...ux-foundation.org>,
	"Xen-devel@...ts.xensource.com" <Xen-devel@...ts.xensource.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Vasiliy G Tolstov <v.tolstov@...fip.ru>
Subject: Re: [GIT PULL] Small Xen bugfixes

 On 10/31/2010 02:13 AM, Ian Campbell wrote:
>> The 3rd is certainly simplest, at the cost of wasting a trivial amount
>> of memory.
> Doesn't Linux avoid using the lowest 1M anyway? (obviously apart from
> the start of day probing for firmware tables etc).

No, it tries to use most of it I think.  It will tend to avoid the low
64k (maybe more) to avoid BIOS bugs.

>>   Unfortunately it crashes early.  Sigh, will try and sort it
>> out this afternoon.
> Strange!

I didn't get a chance to poke at it again, but in retrospect, I think
there are various "must succeed" allocations in low memory.  We don't
need those allocations (things like AP boot trampoline, etc), but we
don't bother to stub them out or prevent them from happening.  Reducing
the system to one with *no* allocatable memory below 1M is just too
strange, and would be a continuous source of problems in the future.

Of the other two options, I think your original approach is going to be
simplest.  E820 gap filling wouldn't be too bad, but we'd end up having
to add a bit of gap-tracking logic to the E820 loop which isn't
currently there.  Ignoring sub-1M gaps is simpler (and it needn't be
conditional on xen_initial_domain(), because we would never expect to
see anything strange sub-1M in a domU, and if there is, we should still
be careful of it in case something odd is going on).

    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/