linux-kernel - Re: CONFIG_HIGHMEM4G and 1GB RAM

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]

Date:	Mon, 30 Apr 2007 15:45:36 -0700
From:	William Lee Irwin III <wli@...omorphy.com>
To:	Matt Keenan <tank.en.mate@...il.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Bradley Chapman <kakadu@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: CONFIG_HIGHMEM4G and 1GB RAM

William Lee Irwin III wrote:
>> The CONFIG_VMSPLIT config options were merged for such cases.
>> It should be able to split on any 4MB-aligned boundary in
>> CONFIG_HIGHMEM4G. CONFIG_VMSPLIT_3G_OPT appears to do something of
>> this sort to use an entire 1GB RAM with minimal user address space
>> reduction.
>> This is an ELF ABI violation but the number of major applications
>> that break is apparently low.

On Mon, Apr 30, 2007 at 11:18:28PM +0100, Matt Keenan wrote:
> wine and some java implementations being two of the big caveats.

Understand that when I say this, I remain one of the more staunch
critics of the ABI-violating aspect of the CONFIG_VMSPLIT options.

I would be more in favor of reorganizing the kernel virtual address
space for the case of 1GB laptops. The primary reason it now requires
highmem is that otherwise vmallocspace would alias ZONE_NORMAL, which
is not handled.

The way to handle the aliasing is simple except for the case of vmap();
simply allocate the backing pages for vmalloc() from the virtual
address range aliasing it. IOW, implement vmalloc() as __get_free_pages(),
save for supporting cases beyond power-of-two alignment. vmap() must
carry out a similar reservation to obtain a virtually contiguous range
of memory; however, it must not use the underlying pages. Instead, it
must map the physical pages specified by the caller in the range of
virtual address space reserved in tandem with the physically contiguous
allocation. The physical pages underlying the virtual mapping window,
without a way to window into them as per CONFIG_HIGHMEM, merely stay
reserved until the virtual mapping established by vmap() that clashes
with their static virtual mapping is undone.

In such a manner the static virtualspace reservation for vmallocspace
can be eliminated, and the case of 1GB laptops handled efficiently with
neither highmem nor ABI violations.

If this sounds invasive or difficult, that's because it probably is.
Taking this idea seriously is indicative of the gravity I consider
the issues of laptop/desktop users to have.

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