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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <47584.30338.qm@web45202.mail.sp1.yahoo.com>
Date:	Fri, 28 Aug 2009 17:20:31 -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

Thanks for the reply Alan,
What I am looking for is this: Let us keep aside the virtual addresses for a process aside for a second. My question does not relate to that at all.

why does kernel map only 896MB of RAM to linear addresses in kernel page tables at the startup even if RAM size is more than that say 3.5GB of RAM
Why does it use dynamic memory mapping technique using zones for mapping the remaining 2.5 GB of RAM( 3.5GB - 1GB = 2.5GB)

Why not it does the following?
kernel sets up the page tables during initialization phase such that it maps all the available physical RAM i.e 3.5GB to linear addresses.
what is wrong with this approach. 




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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ