linux-kernel - Re: [PATCH] reserve end-of-conventional-memory to 1MB on 32-bit v2

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:	Tue, 04 Mar 2008 09:05:37 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Alexander van Heukelum <heukelum@...tmail.fm>
CC:	Jeremy Fitzhardinge <jeremy@...p.org>,
	Mark McLoughlin <markmc@...hat.com>,
	Alexander van Heukelum <heukelum@...lshack.com>,
	Ingo Molnar <mingo@...e.hu>, Ian Campbell <ijc@...lion.org.uk>,
	Andi Kleen <ak@...e.de>, Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] reserve end-of-conventional-memory to 1MB on 32-bit v2

Alexander van Heukelum wrote:
> 
> If this is indeed not executed, is there a way to detect whether
> we can expect the environment to behave like a normal pc in terms
> of magic addresses, bios areas, isa reserved address space and so
> on?
> 

The subarch stuff (boot_params.hdr.hardware_subarch) is indeed executed, 
at least with newer PV guests.

However, as far as this kind of stuff, one really have to wonder to what 
extent the PV users really care about how much they perturb the guests. 
  The canonical view of virtualization is that you should perturb your 
guests as little as possible, but that doesn't really seem to be 
considered in the observable bits of the PV universe as far as I can tell.

A *massive* issue with hooks -- including paravirt_ops -- is that they 
are largely undocumented both in code and in specification, and usually 
hard-code the underlying implemenentation at a specific point in time: I 
have yet to see any sort of specification document for paravirt_ops, and 
most of the hooks are simply empty on hardware.  This means that the 
burden has shifted onto the kernel maintainers to test every possible 
paravirt_ops client, because it is quite literally the only way to know 
when it's broken.

I'm starting to feel that the PV clients need to document their 
environments and their constraints better for the benefit of the core 
maintainers.

	-hpa

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