Kernel vs user memory

Kernel vs user memory

[sidc7]

The kernel maintains a free list of pages that are free in physical memory. I
was wondering, are these pages in the kernel space ? They are not mapped to
any of the user address space for sure, so will they be in the kernel memory
?

Thanks
-- 
View this message in context: http://www.nabble.com/Kernel-vs-user-memory-tp21512362p21512362.html
Sent from the linux-kernel mailing list archive at Nabble.com.

Re: Kernel vs user memory

[Bryan Donlan]

On Fri, Jan 16, 2009 at 9:56 PM, sidc7 <siddhartha.chhabra@gmail.com> wrote:
>
> The kernel maintains a free list of pages that are free in physical memory. I
> was wondering, are these pages in the kernel space ? They are not mapped to
> any of the user address space for sure, so will they be in the kernel memory
> ?

Of course. Note that much of user address space is also mapped into
kernel address space (all of it, in fact, unless you're on a 32-bit
x86 system with PAE and more than 3G or so of RAM), so such a clear
division isn't quite that easy :)

All the gory details are in mm/page_alloc.c and mm/slab.c (or slub.c
or slob.c, depending on your build configuration).

Re: Kernel vs user memory

[sidc7]

I am not an expert, just started doing some kernel programming and code
reading, so as far as I understand, memory can be either mapped to user
space or kernel space, if its neither in user and kernel, as you said, the
division is not easy, where will the memory be mapped to, is there any other
special region ?

Thanks


Bryan Donlan wrote:
> 
> On Fri, Jan 16, 2009 at 9:56 PM, sidc7 <siddhartha.chhabra@gmail.com>
> wrote:
>>
>> The kernel maintains a free list of pages that are free in physical
>> memory. I
>> was wondering, are these pages in the kernel space ? They are not mapped
>> to
>> any of the user address space for sure, so will they be in the kernel
>> memory
>> ?
> 
> Of course. Note that much of user address space is also mapped into
> kernel address space (all of it, in fact, unless you're on a 32-bit
> x86 system with PAE and more than 3G or so of RAM), so such a clear
> division isn't quite that easy :)
> 
> All the gory details are in mm/page_alloc.c and mm/slab.c (or slub.c
> or slob.c, depending on your build configuration).
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
> 

-- 
View this message in context: http://www.nabble.com/Kernel-vs-user-memory-tp21512362p21512985.html
Sent from the linux-kernel mailing list archive at Nabble.com.

Re: Kernel vs user memory

[Bryan Donlan]

On Fri, Jan 16, 2009 at 11:21 PM, sidc7 <siddhartha.chhabra@gmail.com> wrote:
>
> I am not an expert, just started doing some kernel programming and code
> reading, so as far as I understand, memory can be either mapped to user
> space or kernel space, if its neither in user and kernel, as you said, the
> division is not easy, where will the memory be mapped to, is there any other
> special region ?

For each memory space (usually one per process), the kernel sets up a
page table. The lower PAGE_OFFSET bytes are mapped differently for
each such space, but above the address PAGE_OFFSET, every process has
the same mappings - this is what one usually thinks of when one hears
'kernel memory'. The kernel then puts its data structures in this
upper area, so that the addresses of these structures remains the same
in all processes. Of course, these pages are only accessible in kernel
mode - attempting to access them at all from a user process will get
you a segmentation fault.

Note also that while on 64-bit platforms the kernel memory map
generally includes all of physical RAM, on 32-bit platforms such as
the x86, there's typically only about 700mb of physical RAM mapped in
this area by default; the remainder of RAM (if any) can only be used
for page/buffer cache and process memory.

Re: Kernel vs user memory

[Bryan Donlan]

On Thu, Mar 18, 2010 at 20:10, Siddhartha Chhabra
<siddhartha.chhabra@gmail.com> wrote:
> When the kernel tries to access user space pages, for example, for copying
> on a copy on write, in order to do so, does it need to get the page mapped
> to its address space, that is, will a page fault happen for the kernel when
> it first tries to access the user space page that it needs to copy ?
>
> I read a paper that provides security to the OS based on the assumption that
> every time, the OS tries to access the user space, it will page fault and by
> intercepting this page fault, they can check whether the kernel should be
> accessing the page or not ? But based on the discussion below, I guess, the
> kernel is free to access all the pages in memory (or atleast the first 700MB
> on a 32-bit system) without causing a page fault in the kernel space ?
>
> Am I right on this? I greatly appreciate you taking time to answer this
> question

It depends.

If the kernel's doing a copy_from_user or copy_to_user family of calls
(ie, the calls used in system call handlers when accessing user space
buffers referenced in the arguments), this will trigger a page fault
exactly like the userspace process would, and the PF handler will then
deal with any copy on write or whatever may be needed. Of course, if a
userspace access wouldn't trigger a PF, the kernel access won't
either.

For the actual copy-on-write process itself, it would be a Bad Thing
to trigger a recursive page fault, so instead the kernel will directly
access the page via the direct mapped section of the address space -
this will never cause a PF (on x86, this may require creating a
temporary mapping for memory at a high physical address, but this
still won't be a PF as it will be set up before the first access).
Additionally, memory mapped IO involves direct DMA to/from pages that
are simultaneously in use by userspace - this won't cause a PF in
kernel mode either. Same with swap.

In short, some kernel accesses to user space do go through normal
channels which may or may not PF; other accesses will never PF. So
it's a bad idea to rely on all kernel accesses triggering a page
fault.

Hope this helps,

Bryan

Re: Kernel vs user memory

[Bryan Donlan]

On Thu, Mar 18, 2010 at 20:47, Siddhartha Chhabra
<siddhartha.chhabra@gmail.com> wrote:
> On Thu, Mar 18, 2010 at 8:28 PM, Bryan Donlan <bdonlan@gmail.com> wrote:
>>
>> > If the kernel's doing a copy_from_user or copy_to_user family of calls
>> > (ie, the calls used in system call handlers when accessing user space
>> > buffers referenced in the arguments), this will trigger a page fault
>> > exactly like the userspace process would, and the PF handler will then
>> > deal with any copy on write or whatever may be needed. Of course, if a
>> > userspace access wouldn't trigger a PF, the kernel access won't
>> > either.
>>
>> > For the actual copy-on-write process itself, it would be a Bad Thing
>> > to trigger a recursive page fault, so instead the kernel will directly
>> > access the page via the direct mapped section of the address space -
>> > this will never cause a PF (on x86, this may require creating a
>> > temporary mapping for memory at a high physical address, but this
>> > still won't be a PF as it will be set up before the first access).
>> > Additionally, memory mapped IO involves direct DMA to/from pages that
>> > are simultaneously in use by userspace - this won't cause a PF in
>> > kernel mode either. Same with swap.
>>
>> > In short, some kernel accesses to user space do go through normal
>> > channels which may or may not PF; other accesses will never PF. So
>> > it's a bad idea to rely on all kernel accesses triggering a page
>> > fault.
>
>
>>
>> > Hope this helps,
>>
>> > Bryan
>
> In other words, without tying the kernel access to any specific operation
> (like COW, or copy-from/to-user, DMA, Memory mapped IO etc.), is it safe to
> say that a possibly compromised kernel wanting to read application's pages
> can do so without mapping the page to its address space, that is, without
> resulting in a page fault in the kernel mode on an attempt to access a page
> ?
>
> For example:
>
> Lets say for App A frame 5 on physical memory is mapped to its address space
> and its currently using it. The OS does a context switch, however, A's
> frames are still in the main memory. Now can the OS read these page frames
> (frame 5 in main memory) without mapping them to its address space, maybe
> just to read the application's contents and send it out to a potential
> attacker wanting to compromise the system's security ?

That is correct. The kernel can avoid a PF if it wants to by ensuring
the page tables are set up properly from the start; and physical
addresses below a certain value (which varies by architecture) can be
accessed directly without any setup at all.

Re: Kernel vs user memory

[Siddhartha Chhabra]

On Thu, Mar 18, 2010 at 9:06 PM, Bryan Donlan <bdonlan@gmail.com> wrote:

>
> That is correct. The kernel can avoid a PF if it wants to by ensuring
> the page tables are set up properly from the start; and physical
> addresses below a certain value (which varies by architecture) can be
> accessed directly without any setup at all.
>

Thank you for your time, this discussion was really helpful.

Thanks once again
Sid

Re: Kernel vs user memory

[H. Peter Anvin]

sidc7 wrote:
> The kernel maintains a free list of pages that are free in physical memory. I
> was wondering, are these pages in the kernel space ? They are not mapped to
> any of the user address space for sure, so will they be in the kernel memory
> ?

On a non-highmem kernel, they will be -- ALL memory is mapped in kernel
space on non-highmem kernels.  For highmem kernels, they will generally
not be mapped at all, unless they are lowmem pages.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: Kernel vs user memory

[sidc7]

If I am not mistaken, Linux kernel is a high memory kernel, hence for Linux
kernel, nothing will be mapped to the kernel space, other than the memory
beyond 896MB which is the kernel's virtual address space. Am I right on
this?

Thanks


H. Peter Anvin wrote:
> 
> sidc7 wrote:
>> The kernel maintains a free list of pages that are free in physical
>> memory. I
>> was wondering, are these pages in the kernel space ? They are not mapped
>> to
>> any of the user address space for sure, so will they be in the kernel
>> memory
>> ?
> 
> On a non-highmem kernel, they will be -- ALL memory is mapped in kernel
> space on non-highmem kernels.  For highmem kernels, they will generally
> not be mapped at all, unless they are lowmem pages.
> 
> 	-hpa
> 
> -- 
> H. Peter Anvin, Intel Open Source Technology Center
> I work for Intel.  I don't speak on their behalf.
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
> 

-- 
View this message in context: http://www.nabble.com/Kernel-vs-user-memory-tp21512362p21513615.html
Sent from the linux-kernel mailing list archive at Nabble.com.

Re: Kernel vs user memory

[H. Peter Anvin]

sidc7 wrote:
> If I am not mistaken, Linux kernel is a high memory kernel, hence for Linux
> kernel, nothing will be mapped to the kernel space, other than the memory
> beyond 896MB which is the kernel's virtual address space. Am I right on
> this?

It's a compilation option, and depends on the architecture.  What you
described is true for an i386 kernel compiled as a highmem kernel.  On
the other hand, a 64 bit kernel is *never* highmem.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: Kernel vs user memory

[sidc7]

One last question, which one of the two lowmem or highmem kernel is most
commonly used on contemporary linux boxes. I am guessing highmem kernel ?

Thanks for the quick replies, helped a lot


H. Peter Anvin wrote:
> 
> sidc7 wrote:
>> If I am not mistaken, Linux kernel is a high memory kernel, hence for
>> Linux
>> kernel, nothing will be mapped to the kernel space, other than the memory
>> beyond 896MB which is the kernel's virtual address space. Am I right on
>> this?
> 
> It's a compilation option, and depends on the architecture.  What you
> described is true for an i386 kernel compiled as a highmem kernel.  On
> the other hand, a 64 bit kernel is *never* highmem.
> 
> 	-hpa
> 
> -- 
> H. Peter Anvin, Intel Open Source Technology Center
> I work for Intel.  I don't speak on their behalf.
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
> 

-- 
View this message in context: http://www.nabble.com/Kernel-vs-user-memory-tp21512362p21513643.html
Sent from the linux-kernel mailing list archive at Nabble.com.

Re: Kernel vs user memory

[H. Peter Anvin]

sidc7 wrote:
> One last question, which one of the two lowmem or highmem kernel is most
> commonly used on contemporary linux boxes. I am guessing highmem kernel ?
> 
> Thanks for the quick replies, helped a lot

For PCs, 32 bit is generally highmem, and 64 bits is lowmem.  Most
embedded systems are lowmem.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: Kernel vs user memory

[sidc7]

Thanks for the help, makes things a lot clearer


H. Peter Anvin wrote:
> 
> sidc7 wrote:
>> One last question, which one of the two lowmem or highmem kernel is most
>> commonly used on contemporary linux boxes. I am guessing highmem kernel ?
>> 
>> Thanks for the quick replies, helped a lot
> 
> For PCs, 32 bit is generally highmem, and 64 bits is lowmem.  Most
> embedded systems are lowmem.
> 
> 	-hpa
> 
> -- 
> H. Peter Anvin, Intel Open Source Technology Center
> I work for Intel.  I don't speak on their behalf.
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
> 

-- 
View this message in context: http://www.nabble.com/Kernel-vs-user-memory-tp21512362p21550460.html
Sent from the linux-kernel mailing list archive at Nabble.com.