How does Fedora clean its RAM..?
Does the system dump what's on unused RAM?.. Does it wait till reboot..? How does it work..?
How can the system be bumped-up to the next evolution of RAM-processing..?
Is there, or can there be, a continuous wiping-cleaner that instantly cleans RAM the moment its thht-data is dated..?
On Tue, Nov 01, 2011 at 18:34:15 -0700, Linda McLeod lindavaldeen@fastmail.fm wrote:
How does Fedora clean its RAM..?
Does the system dump what's on unused RAM?.. Does it wait till reboot..? How does it work..?
How can the system be bumped-up to the next evolution of RAM-processing..?
Is there, or can there be, a continuous wiping-cleaner that instantly cleans RAM the moment its thht-data is dated..?
Unprivileged users don't have access to the previous contents of ram allocated to their processes. What is the threat model you are trying to guard against?
On Wed, Nov 2, 2011 at 10:56 AM, Bruno Wolff III bruno@wolff.to wrote:
On Tue, Nov 01, 2011 at 18:34:15 -0700, Linda McLeod lindavaldeen@fastmail.fm wrote:
How does Fedora clean its RAM..?
Does the system dump what's on unused RAM?.. Does it wait till reboot..? How does it work..?
How can the system be bumped-up to the next evolution of RAM-processing..?
Is there, or can there be, a continuous wiping-cleaner that instantly cleans RAM the moment its thht-data is dated..?
Unprivileged users don't have access to the previous contents of ram allocated to their processes.
You're sure about that? What evidence do you offer? Can you point to auto-scrub code paths in all the library APIs for freeing memory?
What is the threat model you are trying to guard against?
Rather than merely imply that such threat models are beyond the scope of Fedora, wouldn't it be better to refer the OP to a wiki article on the subject, or to the dev list if there is no wiki article?
Once upon a time, Joel Rees joel.rees@gmail.com said:
On Wed, Nov 2, 2011 at 10:56 AM, Bruno Wolff III bruno@wolff.to wrote:
Unprivileged users don't have access to the previous contents of ram allocated to their processes.
You're sure about that? What evidence do you offer? Can you point to auto-scrub code paths in all the library APIs for freeing memory?
Read the kernel source.
What is the threat model you are trying to guard against?
Rather than merely imply that such threat models are beyond the scope of Fedora, wouldn't it be better to refer the OP to a wiki article on the subject, or to the dev list if there is no wiki article?
Go read a book on Unix.
On 11/02/2011 22:13, Chris Adams wrote:
Once upon a time, Joel Rees joel.rees@gmail.com said:
On Wed, Nov 2, 2011 at 10:56 AM, Bruno Wolff III bruno@wolff.to wrote:
Unprivileged users don't have access to the previous contents of
ram allocated
to their processes.
You're sure about that? What evidence do you offer? Can you point to auto-scrub code paths in all the library APIs for freeing memory?
Read the kernel source.
What is the threat model you are trying to guard against?
Rather than merely imply that such threat models are beyond the scope of Fedora, wouldn't it be better to refer the OP to a wiki article on the subject, or to the dev list if there is no wiki article?
Go read a book on Unix.
Chris Adams cmadams@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Chris is correct in saying read the kernel source. When a page is given to userspace by the kernel it is given zeroed out. The reason you would need to scrub memory is if you are reallocated a page of memory by the malloc library and not the kernel. If a memory region is freed using free and then subsequently malloced with another call it is possible for malloc to give you memory that hasn't been scrubbed. If malloc needs a new set of pages to meet your request the pages it will get from the kernel will already be zeroed.
Dave
On 11/02/2011 07:04 PM, Joel Rees wrote:
You're sure about that? What evidence do you offer? Can you point to auto-scrub code paths in all the library APIs for freeing memory?
Unless the next program allocates RAM and reads from it without first writing to it, what difference does it make? And, in the unlikely event that some program does this, there's no way of knowing a priori what was there before.
Once upon a time, Joe Zeff joe@zeff.us said:
On 11/02/2011 07:04 PM, Joel Rees wrote:
You're sure about that? What evidence do you offer? Can you point to auto-scrub code paths in all the library APIs for freeing memory?
Unless the next program allocates RAM and reads from it without first writing to it, what difference does it make? And, in the unlikely event that some program does this, there's no way of knowing a priori what was there before.
That would be a security problem, since you could have information leak from one process to another. However, Unix-like systems don't work that way.
You're sure about that? What evidence do you offer? Can you point to auto-scrub code paths in all the library APIs for freeing memory?
We actually don't wipe memory on free, but on allocate. That has performance wins. Some user space does go to the trouble of wiping things like crypto keys once they are used, as does some kernel bits.
Linux has *no* memory allocator for userspace from the kernel. It has mmap which maps in an object from the file system and sbrk() which is these days implemented in terms of mmap.
What these actually do effectively is allocate address space, and we have a /dev/zero which is an infinite supply of mappings of a single kernel page that contains only zero.
So the actual process becomes
I need 1MB mmap /dev/zero for 1MB We get 1MB of page tables pointing to the *same* page of zero
At this point our 1MB takes up 4K (plus page tables). When you write to it for the first time the page you write to is copied and updated with the new data ("copy on write") and now has its own actual data.
This is a good deal more efficient.
Rather than merely imply that such threat models are beyond the scope of Fedora, wouldn't it be better to refer the OP to a wiki article on the subject, or to the dev list if there is no wiki article?
The usual threat models for not clearing memory are the fact things like keys may hang around longer. But they may also have hit swap so really for most uses the concern is crypted swap and use of hibernate in preference to suspend. If you leave someone with physical access to a PC you lost already however, as they can trojan the BIOS and the like ready for the next boot.
The Linux kernel may move to zeroing user pages at free, at least in some circumstances. The reason for this isn't however security but virtual machines. Right now KVM with a Linux guest cannot tell properly if chunks of pages of free user data are relevant so it must preserve them. If they are zeroed on free then the ksm background scan which finds identical pages in and between guests and turns them into one mapping will be able to take all the freed user pages and turn them back into a single page of real physical host memory.
Alan
On 11/02/2011 01:34 AM, Linda McLeod wrote:
How does Fedora clean its RAM..?
with a RAM brush. 8-D
really, what are you considering as "clean it's ram"?
as in setting ram to all zeros, or do you mean when 'ram buffer' files with programs/data and a newly started program needs ram, and inactive/sleeping programs/data is dumped to swap partition?
Does the system dump what's on unused RAM?..
actually, ram is alloted. to system program areas, user program areas, system program data, user program area.
Does it wait till reboot..?
yes and no. again, it is a question of how you are defining "clean it's ram".
How does it work..?
pdg. ;-)
some programs have buffer cleaning routines, ie, keyboard input buffer, and other such that need to start out clean. even then, as with keyboard buffer, it does not really have to be cleaned as many well written routines will either set a counter to show end of data storage, or what loads buffer will put a string of zeros at end of data.
How can the system be bumped-up to the next evolution of RAM-processing..?
define you understanding of "next evolution of RAM-processing"
Is there, or can there be, a continuous wiping-cleaner that instantly cleans RAM the moment its thht-data is dated..?
why do you feel that it is really/always necessary?
On 11/02/2011 02:34 AM, Linda McLeod wrote:
How does Fedora clean its RAM..?
On Monday morning before the start of the week it lets out the Gnomes who then diligently start to do some serious housecleaning. There's Spidey Gnome who climbs up the walls to get to those difficult to reach places and do some much needed pre-winter cleaning. There's Hyper Gnome who just runs around cleaning bits of everything it can find. Then there's Grumpy Gnome who complains about Hyper Gnome just cleaning bits instead of bytes. And there's Bearded Gnome who complains incessantly about any proprietary bits it finds and makes awkward remarks about lady Gnomes. And there's off course Lazy Gnome who just sits there pretending to clean (the other Gnomes bought him a lmgtfy.com shirt but he didn't get it). Finally there is Obi Wan Gnome, the Fearless Leader who tries to keep things moving forward smoothly and always mumbles about Freedom, Friends, Features and First.
:-)
Regards, Patrick
On 02/11/11 01:34, Linda McLeod wrote:
By putting it on the lamb, Until it rains for a week or two.
-
Alan Cox -
Bruno Wolff III -
Chris Adams -
David Quigley -
Frank Murphy -
g -
Joe Zeff -
Joel Rees -
Linda McLeod -
Patrick Lists -
Sam Varshavchik