Subj : Re: JavaScript memory allocation To : netscape.public.mozilla.jseng From : Michael Vincent van Rantwijk Date : Sun Aug 28 2005 03:49 pm Matthew Mondor wrote: > Hi Micheal, Thanks for your reply Matthew! > Since your questions are mostly JS internals related, this does seem > like an appropriate mailing list/usenet group, Perfect. > On Tue, 23 Aug 2005 09:11:15 +0200 > Michael Vincent van Rantwijk wrote: > >> It is my understanding, but maybe I'm totally wrong in this, that if I >> use something like this: var someVar = "foobar"; the JavaScript engine >> allocates a six (6) byte memory block and assigns a pointer to it, right? > > More than six bytes, but at least 6 characters (the JSString object has > to be created/allocated, characters could also be unicode or ASCII), it > must be linked to the context and/or parent object, etc if you need > exact details the SpiderMonkey source might be best to look at, but > maybe some people can actually remind and post the details by heart Ok, I understand this, I think. >> My first question is: "What happens when I use something like this: >> someVar = "" / someVar = null; someVar = undefined; ? >> >> Will that clear the pointer *and* allocated memory or will there be a >> trace left of the text "foobar" i.e. is that still 'available' in >> readable text somewhere in memory? > > Even if the engine replaced the new string contents by another one, and > eventually did free the old string contents, it could still remain > readable in the process heap's memory. This largely depends on the > internal OS/libc-specific malloc()/calloc()/free()/realloc() allocators. > If I understand, there is no provision in SpiderMonkey to clear any > memory before it gets dismissed. Hm, so when I enter my (master) password it already gets cpied to some other part of allocated memory, great but not really. > Most (all?) code in SpiderMonkey eventually rely on JS_free() to > free actual memory (and that is normally done once the Garbage Collector > freed unnecessary objects, when this happens depends on the application, > memory currently in use and various factors). JS_free() just relies on > the OS/libc specific free() function, which might or might not clear > memory prior to release and can use various algorithms. malloc() itself > can allocate more or less memory (and always more memory than requested) > depending on the implementation. > >> My second question is: if the latter is the true, I guess that setting >> someVar to = "123456" will overwrite the text "foobar" (right?) but what >> happens when I set if to a shorter/longer text string? Will that re-use >> the same allocated memory block, or will it allocate a new block and >> will that also keep the text "foobar" in memory or will that be cleared? > > A new string will be created, because in JS strings are immutable. > The old string, if no longer referenced, will belong to the GC and > will eventually be freed when needed. OK, I understand this. > My guess (although only a guess) is that your purpose is to make sure > that some memory is not accessible anymore after it is discarded (i.e. a > password or cryptographic session key). If this is the case, what I > recommend is to create a new native object for JavaScript in C using > SpiderMonkey with custom properties and methods and internal data, which > could provide a method which when called realy causes the internal > memory to be zeroed, and/or to cause the finalizer of that object to do > so. However, because of the way JavaScript works, this could be partly > useless depending on several factors. It would be great to have it available in all Seamonkey and Mozilla Firefox version from a certain version, without me (trying) to fix this, but maybe it isn't because of the other factors? > For instance, if you provide a method to return the internal data as a > string, the caller can then actually create new JSString objects holding > copies of that data just by calling it (since such a method/property > needs to create a JSString, to fill it and to return it of course). > > If, on the other hand, you only provide methods/property to say, set a > password and verify if it matches another, this might be less of a > problem, but still, where does the user password originate from? If it > doesn't originate from another custom system there are many chances that > the data has copies in the memory heap. It seems to be getting more and more complicated. > If those parts can be worked around, then there always remains the way > memory is allocated. On Unix systems, one can allocate anonymous pages > of physical memory using mmap(2) and then subsequently locking them in > RAM using mlock(2) to ensure that they cannot be swapped out (to the > swap virtual memory device), when such information is very critical. I > am not sure how this is done on other paging Operating Systems, but in > any case this means that the custom module must rely on such a function > if the information loss is that critical instead of to > malloc(3)/free(3). Because on systems with virtual memory, even if > free(3) made sure to first zero the buffer, or if a custom method was > provided to cause the internal data to be zeroed, if load is high enough > and/or another process requireing a lot of RAM is considered more vital > by the OS, the process can be swapped out to the swap device for more > physical RAM to become available, at any time. This means that another > physical entity would have the data written to it. > > If discarding such information is the purpose, is there a particular > reason or situation which causes you to easily access this unwanted > information? Perhaps that other solutions to this particular situation > could be found. Some of what I posted is related to the most extreme > critical situations (i.e. OpenSSL code) and might not even be > necessary... I'm told that there are utilities that enable you to scan allocated memory for passwords, and that can't be a good thing, if this is true. Thanks for the (long) reply, but it currently doesn't help me in any way, but I've learned some new facts, I hope. Michael .