linux-kernel - Re: kernel page table mapping for >1GB <3 GB for x86 arch without PAE

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: <ada8wh3renp.fsf@cisco.com>
Date:	Fri, 28 Aug 2009 11:12:26 -0700
From:	Roland Dreier <rdreier@...co.com>
To:	joe Shmoe <jsmoe3@...oo.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: kernel page table mapping for >1GB <3 GB for x86 arch without PAE


 > Assuming I have 3GB RAM, why does not kernel create page tables in a way that all of this 3GB physical memory can be addressed . (for x86 arch 32 bit with PAE disabled )
 > 
 > I understand the 3GB/1GB split for user/kernel address space.Isn't  this just a matter of setting up the page table entries in such a way that so all the available RAM upto 3GB can mapped in the kernel page tables. In this way CPU's MMU can take care of mapping any virtual address within first 4GB to physical address using the page table entries regardless of a process is in kernel/user mode. 

On a 32-bit architecture, there is only 4GB of address space available.
If the kernel uses 3GB of address space for a direct mapping of physical
memory, then only 1GB is available for everything else (userspace,
vmalloc, etc).  BTW, this is available by enabling CONFIG_VMSPLIT_1G.

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