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] [day] [month] [year] [list]

Message-ID: <477591.96177.qm@web45216.mail.sp1.yahoo.com>
Date:	Sat, 29 Aug 2009 07:40:34 -0700 (PDT)
From:	joe Shmoe <jsmoe3@...oo.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: kernel page table mapping for >1GB <3 GB for x86 arch without PAE

Hey Alan,
May be I confused you. Sorry

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

Can those "arbitary basically random physical addresses" fall outside 
1GB-3GB is my question. Why does kernel stop at 896MB during page table setup. Why not go ahead and map the remaining available RAM (where RAM size is > 1GB < 4GB)
But kernel uses different technique for addressing the high memory > 896MB

Not sure this is being done so that it will be easier for kernel to maintain page table assignments/swaping to various processes.
 
> 3GB+        Physical mapping
> only accessible in kernel mode

Yes. This part I understand obviously these addresses are issued only when a process is running in kernel mode.


--- On Fri, 8/28/09, Alan Cox <alan@...rguk.ukuu.org.uk> wrote:

> From: Alan Cox <alan@...rguk.ukuu.org.uk>
> Subject: Re: kernel page table mapping for >1GB <3 GB for x86 arch without PAE
> To: "joe Shmoe" <jsmoe3@...oo.com>
> Cc: linux-kernel@...r.kernel.org
> Date: Friday, August 28, 2009, 6:16 PM
> 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/