MMU related code

MMU related code

[Carter Cheng]

Hi,

Where do I find the code in the kernel related to the MMU and resolving
memory addresses? I am trying to understand what the implications are if
code like this has bugs and the impact on the various functions that return
chunks of memory for use via pointers (either as pages or kmalloc chunks)
etc.

Regards,

Carter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20181029/3e2c0d57/attachment.html>

MMU related code

[valdis.kletnieks at vt.edu]

On Mon, 29 Oct 2018 00:08:12 +0800, Carter Cheng said:

> Where do I find the code in the kernel related to the MMU and resolving
> memory addresses? I am trying to understand what the implications are if
> code like this has bugs and the impact on the various functions that return
> chunks of memory for use via pointers (either as pages or kmalloc chunks)
> etc.

The results are easy enough to predict even without looking at the code.  If your
memory allocations are buggy, you get random memory overlays and corruption,
attempts to access non-mapped physical or virtual memory addresses, and so on.

Basically, all the same sorts of issues beginning C programmers encounter before
they understand pointers.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 486 bytes
Desc: not available
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20181028/ad681067/attachment.sig>

MMU related code

[SeyedAlireza Sanaee]

Hi,

A BUGGY MMU may also have some security implications, like flawed
protection of one process against another one. MMU may work fine without
any performance or functionality issue. But it might reveal one's address
space to the others.

I'm not sure if what I have told is true but let me know if it is wrong pls!

Thanks

On Mon, Oct 29, 2018 at 9:50 AM <valdis.kletnieks@vt.edu> wrote:

> On Mon, 29 Oct 2018 00:08:12 +0800, Carter Cheng said:
>
> > Where do I find the code in the kernel related to the MMU and resolving
> > memory addresses? I am trying to understand what the implications are if
> > code like this has bugs and the impact on the various functions that
> return
> > chunks of memory for use via pointers (either as pages or kmalloc chunks)
> > etc.
>
> The results are easy enough to predict even without looking at the code.
> If your
> memory allocations are buggy, you get random memory overlays and
> corruption,
> attempts to access non-mapped physical or virtual memory addresses, and so
> on.
>
> Basically, all the same sorts of issues beginning C programmers encounter
> before
> they understand pointers.
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20181029/78ff40c0/attachment.html>

MMU related code

[Carter Cheng]

Is the /mm directory the correct place to look? It seems to contain memory
related code but from what little I have read it seems at a higher level
building in some cases at least on kmalloc. I am just curious about a point
raised by the SVA dissertation(by John Criswell). Another point he does
raise but I am uncertain about how true it is in general is that to do
static analysis/dynamic instrumentation properly on the kernel one needs
some method to assess what the inline assembly fragments do and to deal
with this particular problem he replaced all this code with custom bitcode
instructions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20181029/2117484f/attachment.html>

MMU related code

[Steffen Vogel]

Hi Carter,

On Mon, Oct 29, 2018 at 03:33:02PM +0800, Carter Cheng wrote:
> Is the /mm directory the correct place to look? It seems to contain memory
> related code but from what little I have read it seems at a higher level
> building in some cases at least on kmalloc. 

Most if the paging/MMU code is also architecture specific which means
that it resides in the arch/mm subfolders.

I saw that there was a MM 101 presentation last week at the Open Source
Summit [1], Unfortunatetly, it is quite high-level and most likelt
uninterestting to you.

But there is also a huge subsection in the official kernel documentation
which has many references to the mm/ and arch/mm code [2].

Cheers,
Steffen


[1] https://events.linuxfoundation.org/wp-content/uploads/2017/12/MM-101-Introduction-to-Linux-Memory-Management-Christoph-Lameter-Jump-Trading-LLC.pdf
[2] https://www.kernel.org/doc/html/latest/vm/index.html

MMU related code

[Carter Cheng]

Thanks, I'll check it out.

On Mon, Oct 29, 2018 at 3:45 PM Steffen Vogel <post@steffenvogel.de> wrote:

> Hi Carter,
>
> On Mon, Oct 29, 2018 at 03:33:02PM +0800, Carter Cheng wrote:
> > Is the /mm directory the correct place to look? It seems to contain
> memory
> > related code but from what little I have read it seems at a higher level
> > building in some cases at least on kmalloc.
>
> Most if the paging/MMU code is also architecture specific which means
> that it resides in the arch/mm subfolders.
>
> I saw that there was a MM 101 presentation last week at the Open Source
> Summit [1], Unfortunatetly, it is quite high-level and most likelt
> uninterestting to you.
>
> But there is also a huge subsection in the official kernel documentation
> which has many references to the mm/ and arch/mm code [2].
>
> Cheers,
> Steffen
>
>
> [1]
> https://events.linuxfoundation.org/wp-content/uploads/2017/12/MM-101-Introduction-to-Linux-Memory-Management-Christoph-Lameter-Jump-Trading-LLC.pdf
> [2] https://www.kernel.org/doc/html/latest/vm/index.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20181029/e4417a0a/attachment.html>