User: Password:
|
|
Subscribe / Log in / New account

Sanitizing kernel memory

Sanitizing kernel memory

Posted May 28, 2009 8:01 UTC (Thu) by gmaxwell (guest, #30048)
Parent article: Sanitizing kernel memory

Why not make this a default behaviour?

When userspace sbrks to increase memory the kernel must hand it cleared memory or data leaks will result. From a performance perspective clearing at free is probably superior to clearing at the time the memory is allocated.

I expect that there would be a performance hit from the clearing of sub-page kernel allocations. But it may be negligible and if it isn't then just that part of this patch could be made an optional parameter.

With userspace memory protected and kernel cryptographic memory protected that would eliminate a significant part of the attack surface... am I missing a reason why this couldn't perform well?


(Log in to post comments)

Sanitizing kernel memory

Posted May 28, 2009 13:27 UTC (Thu) by lemmings (guest, #53618) [Link]

> Why not make this a default behaviour?

Memory that is free will upon allocation either be over-written (e.g. DMA from HDD/network) or zeroed (e.g. stack frame) prior to use.

Making this the default behaviour will add a performance cost in the over-written case. Part of the cost could be hidden though by having
a low priority memory clearing thread which used the appropriate instructions to avoid filling the data cache.

The extent of the cost can only be determined with proper benchmarks though. Then whether the cost is acceptable is another question...

Disclaimer: I'm not a kernel hacker so I could be full of it.

Sanitizing kernel memory

Posted May 28, 2009 18:25 UTC (Thu) by anton (subscriber, #25547) [Link]

Clearing on freeing will also add a performance cost in the zeroed case: Even if you avoid the cache and CPU cost of clearing in some way, there are still the memory bandwidth costs of writing the zeros out, and later loading them again; plus the CPU latency cost of having to load the zeros into the cache on use. In contrast, if you zero the page on-demand, the zeros are written to the cache, and in many cases are then available to the user program from the cache, requiring less CPU time and less memory bandwidth.

Sanitizing kernel memory

Posted May 28, 2009 18:38 UTC (Thu) by gmaxwell (guest, #30048) [Link]

My thought process was the that the writing at free is cheap (especially as you can avoid pulling in anything in from memory or evicting anything from the cache) and that any userspace app that reads memory handed to it by the kernel before writing it is broken. Don't these people have valgrind?

:)

Sanitizing kernel memory

Posted May 28, 2009 19:09 UTC (Thu) by anton (subscriber, #25547) [Link]

any userspace app that reads memory handed to it by the kernel before writing it is broken.
If the application writes a byte to a line that's not in cache, current CPUs load (the rest of) the cache line from main memory (write allocate). In a few special cases this read can be avoided, but for ordinary writes it happens.

Sanitizing kernel memory

Posted May 30, 2009 10:10 UTC (Sat) by willezurmacht (guest, #58372) [Link]

"any userspace app that reads memory handed to it by the kernel before writing it is broken. Don't these people have valgrind?"

Or maybe it's an exploit for an information/memory leak bug in the kernel that retrieves your root password and tty buffers contents from memory.

Sanitizing kernel memory

Posted May 28, 2009 22:06 UTC (Thu) by nix (subscriber, #2304) [Link]

Would a DMA engine help here? A lot of modern chipsets have them
(sometimes they even work).

Sanitizing kernel memory

Posted May 29, 2009 8:50 UTC (Fri) by anton (subscriber, #25547) [Link]

A DMA engine would "avoid the cache and CPU cost of clearing" (that's what I was thinking about when I wrote that), but the other costs would still be there.

Sanitizing kernel memory

Posted Jun 2, 2009 15:29 UTC (Tue) by etienne_lorrain@yahoo.fr (guest, #38022) [Link]

On the other side, if a function allocates more than it will use (allocating the maximum size is quite usual, and *alloc() may round up the size), then the zeroing at allocation will pollute all those very performance enhancing 32+ bytes cache 1 lines...
Moreover, DMA zeroing at free() time should set those cache lines in a state where they will be first reused (instead of more important lines).
Sorry, not statistics available.

Sanitizing kernel memory

Posted Jun 2, 2009 16:24 UTC (Tue) by anton (subscriber, #25547) [Link]

Yes, if the zeroed cache lines are not accessed or not accessed before being replaced in the cache, then the performance of on-demand zeroing for that cache line will be just as bad as eager zeroing in the cache, and a little worse than for eager methods that don't go through the cache. But I doubt that that's the case for the majority of cache lines. In particular, I don't think that there are replaced at all cache levels before being accessed. But yes, measurements would be a good idea.

Concerning eager zeroing of cache lines, that is certain to replace a page full of cache lines just as on-demand zeroing does, except that it is far less likely that the cache lines will be accessed before being replaced by other cache lines, so it is a bad idea. Tagging the line as least-recently-used helps only a little, if it is possible at all.

Sanitizing kernel memory

Posted Jun 4, 2009 18:30 UTC (Thu) by oak (guest, #2786) [Link]

> On the other side, if a function allocates more than it will use

I think all the user-space allocated pages point to the same zeroed/shared
physical page until they're written to?

Sanitizing kernel memory

Posted Jun 9, 2009 12:28 UTC (Tue) by etienne_lorrain@yahoo.fr (guest, #38022) [Link]

> user-space allocated pages
We were talking about kernel-space allocated memory...
Having a stock of cleared pages for user-space would probably also be an improvement (when user-space writes its first byte on a page), as long as clearing those pages does not wipe the memory cache (i.e. DMA to memory instead of processor writing).


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds