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: <20090828231603.7918be05@lxorguk.ukuu.org.uk>
Date:	Fri, 28 Aug 2009 23:16:03 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
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

O> I understand the implications of reloading CR3. But once the page tables are  setup to map all the available physical RAM to virtual (linear) address it could be for eg. 1, 2, 3 or 4 GB how does it matter.

Where are you putting the user virtual addresses. User addresses don't
map direct to physical addresses so you need both sets of translations at
once

Right now you have

0-3GB		MMU translations to arbitary basically random
physical addresses (with many pages shared and some absent)

3GB+		Physical mapping only accessible in kernel mode

If user applications ran with a 1:1 mapping of application space to
physical addresses you would be fine - but they don't and it would be
rather hard to run like that because you want page sharing, lazy unshare,
vfork etc to all work.
--
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/