linux-kernel - Re: [PATCH] reserve RAM below PHYSICAL

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: <20080229185029.GZ8091@v2.random>
Date:	Fri, 29 Feb 2008 19:50:29 +0100
From:	Andrea Arcangeli <andrea@...ranet.com>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	linux-kernel@...r.kernel.org, Andrew Morton <akpm@...l.org>,
	Nick Piggin <npiggin@...e.de>, Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH] reserve RAM below PHYSICAL_START

Hi Peter,

On Fri, Feb 29, 2008 at 10:21:08AM -0800, H. Peter Anvin wrote:
> Hi Andrea,
>
> Sorry for the long delay in replying.
>
> I'm trying to grok the use cases for this.  In particular, it seems like a 
> particularly restricted case of wanting to be able to reserve an arbitrary 
> bit of memory, which seems like it would be more useful (don't we already 
> have memmap= options for that, anyway?)

I'll answer the memmap in separate email.

> In particular, what's the reason for reserving *low* memory?  Low memory 
> (first megabyte) is full of special-use address space which, as the Xen 

The only special ones are zero page and trampoline (the trampoline
optionally can later be moved near 640k with an independent patch).

> address space discussion has showed, is nontrivial to tamper with even if 
> it initially works.  If you want a dedicated chunk of mappable PCI space, 
> it would seem cleaner to have it higher up in the memory map.

The whole e820 must be PCI mappable, bootloader starts in real mode
and if any dma happens it will crash. This is to let any guest OS or
bootloader run with pci passthrough. There's no paravirt here, the
guest has fully native drivers (which is the whole point of this
approach I guess).

This will allow things like running random 3d apps on a random 3d card
on random OS with random 3d driver, all on top of linux host that
leaves the first 1G free for this OS to run with direct access to the
graphics card. Clearly linux host isn't safe, but if you trust that
guest OS that talks directly to the 3d card, you can run many more
guests that are fully swapped out or ballooned or rss limited or ksm
shared, etc... plus the host can run apps too. This is to retain the
full KVM/Linux virtualization power and flexibility without leaving 3d
or any other proprietary hardware out of the equation in the
pci-passthrough guest.
--
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/