Hardware

The "insecure memory" FAQ

The problem of "insecure memory" is little-known and pervasive. Read on to find out what "insecure memory" means, and how it affects you. I even intentionally changed settings on a (secured) machine to use "insecure" memory just to show you how such a message might look. See the sacrifices I make for my readers?

There are times when a user of a free and open source operating system like FreeBSD or Debian GNU/Linux might encounter a warning or error message that looks something like this:

"Warning: using insecure memory!"

A likely moment might be the first time one uses GnuPG, because it's helpful with the scary warning messages like that:

Insecure Memory

Yes, I intentionally changed settings on a (secured) machine to use "insecure" memory just to show you how such a message might look. See the sacrifices I make for my readers?

One might ask, "What does this mean? Does my computer's RAM need a therapist?" Of course, the second question would just be a joke. I hope so, anyway. The first question is somewhat more serious, however. That and nineteen other questions, have been answered below.

What does it mean?

So-called "insecure memory" is used when something stored in memory might be written to non-volatile storage, as in the case of data being swapped out of RAM to the hard drive because too much memory is being used to keep everything in RAM.

Why is it insecure?

Data in your swap partition or swapfile (what Microsoft calls the "pagefile" in its Windows OS) is not automatically lost when you shut down your computer. Something "swapped out" of RAM might thus be retrieved later by someone who has physical access to your computer, even if it has been turned off, while something that was only stored in RAM theoretically "goes away" irretrievably when there is no longer any power maintaining the data in memory.

Why does it matter?

When working with encrypted data, you need to decrypt it at some point so that you can do something meaningful with it. Similarly, passwords should hopefully never be written to disk when you enter them at a prompt for authentication. Such things should only exist in RAM for the minimum necessary time to do what needs to be done, while the encrypted form is all that ever gets stored on disk.

Does this mean that RAM is secure and the hard drive isn't?

Not exactly. It means that there are some very real, immediate security issues related to storing sensitive data on the hard drive and other long-term storage devices without encrypting it that do not apply to volatile memory. RAM does have other problems, however:

  1. For one thing, while people imagine that turning off the power immediately clears RAM, the truth is that data can persist for several minutes -- retrievable by someone with the correct skills and forensic tools.
  2. Another problem arises if you use solid-state storage devices (like a USB flash drive) to extend your memory capacity (such as via MS Windows Vista's ReadyBoost), because such storage devices are non-volatile. That means they do not automatically clear after cutting power to the computer.
  3. In addition, if a malicious security cracker gains access to your computer either via the network or in person while it is on, unencrypted data in RAM may be accessible.
  4. Finally, more esoteric tricks (like van Eck phreaking -- perhaps a subject for another article later) can be used to access data in RAM without having direct access to the computer, either physically or over the network.

Can't we just encrypt RAM?

Theoretically, yes. On the other hand, that wouldn't be very useful. If all your sensitive data in RAM was encrypted, you wouldn't be able to read it. Security can't be perfect -- but if you're smarter about it than the guy trying to break in, it can be secure enough.

Can I make sure I don't use "insecure memory?"

Yes, you generally can. As an example, we'll address the fact that on some systems non-root users do not have permission to "lock memory pages" to prevent the OS from writing data to disk from volatile memory -- so you might get an "insecure memory" warning when using GnuPG. The way to fix this is to "setuid root" your gpg binary.

I've heard "setuid root" is bad -- but what does it mean?

When a program is "setuid root", this means that running it does so with root privileges. In general, that is not a very good idea for security purposes, but GnuPG is written such that when the gpg utility runs, it drops any root privileges as soon as the memory allocated to the task you are performing with GnuPG is "locked" so that it cannot be written to disk. If you don't believe me, you can check the source code, since it's open source software. I haven't checked it personally, but I've talked to people who have.

How do I actually make gpg "setuid root?"

It's pretty simple, really. Assuming your gpg binary is located at /usr/local/bin/gpg2 as it is on FreeBSD, you can "setuid root" with these two commands:

  # chown root /usr/local/bin/gpg2

# chmod u+s /usr/local/bin/gpg2

The first command makes root the "owner" of the gpg binary (in case root didn't already have ownership of the file). The second makes the program run with the privileges of its "owner" no matter who started it up.

Do I need root access for those commands?

Yes, you do. If you do not have root access to the machine, you can ask whoever does to do it for you, obviously. On the other hand, if there's someone else with root access on a system where you do not have root access, you may want to rethink using encryption software there -- unless that person is allowed to see unencrypted copies of everything you're encrypting there. After all, such a person has enough access to employ all sorts of dirty tricks (like keyloggers, for instance) to capture data you don't want him having, such as your GnuPG passphrase.

Can I make the warning go away on Microsoft Windows?

Of course you can! You can use the --no-secmem-warning command line option, or put no-secmem-warning in your gpg.conf file, to tell GnuPG that you don't want to see the warning.

Does that actually stop it from using "insecure memory?"

No, sorry, it doesn't. All it does is stop the warning from appearing. There are ways you can improve security in this matter, but you cannot achieve the same level of security on MS Windows that you can on Unix and Linux-based systems. In all my years of IT security work, I have never discovered a reasonable way to lock memory pages against being swapped to disk on MS Windows.

It's possible you may even get a version of GnuPG for MS Windows that doesn't give you that warning in the first place -- but be aware that doesn't mean you aren't using "insecure memory."

Does that mean I shouldn't use GnuPG on Microsoft Windows?

Yes and no:

  1. No -- it doesn't mean that. This is not a problem specific to GnuPG. This is a problem with any tools you might use to encrypt and decrypt data on your MS Windows system. The problem is that decrypted data in RAM (as well as passwords, et cetera) cannot reasonably be prevented from being written to the swapfile (including SSH, SSL, and so on), and not any issue with GnuPG itself. It means that, if you have a better option, you shouldn't use any encryption tools on MS Windows. On the other hand, using GnuPG for encryption with MS Windows is better than never using encryption at all.
  2. Yes -- it does mean that, in a manner of speaking. It means that, given a choice, you should use an operating system other than MS Windows when working with encrypted data. If you aren't given that choice, though, see the last sentence of the No answer above.

Can't I just clear the swapfile before shutting down Microsoft Windows?

Yes, you can. In fact, you can make MS Windows do it automatically, using a registry setting. This approach has some shortcomings, however, that render it significantly less "safe" than simply never writing sensitive decrypted data to the swapfile itself (in addition to degrading system performance):

  1. Data on the hard drive is usually easier to access when you're not supposed to do so than data in RAM. This means that if someone has compromised system security, but doesn't have some tool in place to log keystrokes and otherwise intercept decrypted data you're using, it can be quicker and easier to get at sensitive data in the swapfile before MS Windows deletes it than in RAM.
  2. MS Windows cannot overwrite an "active page" in a swapfile. That means that it only overwrites the data when you're done with the application that created the memory that was written to the swapfile in the first place. That assumes both that there isn't a memory leak that lets the data in the swapfile stay where it is even when you're done, and that MS Windows overwrites the relevant pages in the swapfile right away -- which it often won't, thus prolonging the life of those pages in the swapfile. There are rumors that MS Windows Vista has the capacity to clean up after memory leaks where previous versions of MS Windows could not, but I wouldn't bet the security of my encrypted data on that. In matters of security, the base assumption should be that the system isn't secure enough, and only with evidence should you revise that in a positive direction.
  3. This technique's effectiveness depends on the assumption that MS Windows will get a chance to overwrite the swapfile. If your computer loses power suddenly, or the OS crashes (a very real danger), it may not get a chance to overwrite the swapfile with zeroes.
  4. All this technique does for you is overwrite the relevant sectors of the disk with zeroes. This means that it still might be possible to recover data from those pages in the swapfile. Multiple overwrites with random data would make it more difficult, but it might still be possible, depending on the skills and resources of whoever is trying to recover your sensitive data -- but, sadly, this technique doesn't lead to multiple overwrites with random data. Of course, just overwriting once with zeroes is better than "deleting" as when you delete a file from the drive in Windows Explorer, because that kind of "deleting" doesn't overwrite the data at all -- it just tells the file index on the drive to forget the data is there so that it can be treated as empty (and overwritten with other data as needed) later.

Can't I just allocate some RAM for a "ramdisk" and put my swapfile in that?

I suppose so. You could do so on a Unix or Linux-based system, too. That completely defeats the purpose of a swapfile, though. A swapfile is meant to provide a place for data in memory to go when RAM is full. Creating that ramdisk removes that much memory from circulation, making it fill up faster, so that by the time you would be writing your first bit of data to a swapfile on the drive you will have filled up both normal RAM and the ramdisk swapfile. If anyone suggests you should use a randisk swapfile, he or she is probably either incompetent or making a joke.

Can I eliminate the swapfile entirely?

Yes, of course. This might create problems if you ever need more memory than you have in RAM, however. Make sure you have lots of RAM before doing this, especially if you are running a recent version of MS Windows (which will of course require a lot of RAM).

How else can I mitigate the risk?

If you have more than one computer where you will be using GnuPG, you could use it for the more critical and important sensitive data on a non-Microsoft OS that allows you to lock memory pages against being written to disk, and with a different set of keys (to protect the passphrase) use it only for less critical and less important senstive data on the MS Windows machine. This assumes, of course, that you have that option. If you have to use GnuPG on MS Windows for some reason, chances are good this isn't much of an option. Still, separating as much sensitive data from the system without the ability to lock memory pages against writing to disk as possible is a good idea.

What is the best way to protect myself on Microsoft Windows?

A high-quality full disk encryption tool like TrueCrypt can be used to keep your swapfile (as well as everything else in the same partition) encrypted at all times, as long as it is on the disk. Of course, it all gets decrypted as it is brought into RAM so you can use it, but anything written to disk in an encrypted volume is encrypted before it is written to disk, including memory pages sent to the swapfile. TrueCrypt is a handy tool that way, and can actually make other encryption tools like GnuPG almost as well secured on MS Windows as they are on systems that can lock memory pages against being written to disk.

That's my take on the best answer. If, for some reason, TrueCrypt (or a similar tool) is not an option for you, it may not be the best answer for you.

Is this "insecure memory" thing a common problem?

It is far more common than you know. Very, very few encryption and decryption programs bother to tell you that you're using "insecure memory" when they do so. There are several reasons for this:

  1. MS Windows applications use "insecure memory" all the time, so there's not much point in mentioning it, generally. There's no way to fix the problem on MS Windows other than encrypting the swapfile (which, by the way, tends to slow it down quite a bit).
  2. The vendors for some supposedly "secure" software don't want you to worry your pretty little head when there's a security problem, especially since that might affect sales.
  3. Most programmers aren't even aware the "insecure memory" problem exists. Thus, there's a lot of cryptographic software that doesn't provide any means of locking memory pages against being written to disk at all because the programmers simply didn't know any better. Now, hopefully, you know better.

How likely is this stuff to be a problem?

As long as you maintain strict physical control over your system and ensure that network security is tight as a drum, you should be okay. On the other hand, there's always someone out there that can figure out how to get around your security. You just need to stay on the right side of luck -- and that's not just limited to systems using "insecure memory." It's best to avoid the "insecure memory" problem, in case someone gets past your other defenses.

Why do you keep putting "scare quotes" around "insecure memory?"

"Insecure memory" is kind of a misnomer, but it's what everybody calls it. I use the "scare quotes" to indicate that "insecure memory" isn't a perfect term.

A more correct term would be unsecured memory. The problem with what is called "insecure memory" is that it has not been secured against sensitive data being written to disk as plaintext -- thus making it unsecured.

About

Chad Perrin is an IT consultant, developer, and freelance professional writer. He holds both Microsoft and CompTIA certifications and is a graduate of two IT industry trade schools.

37 comments
Photogenic Memory
Photogenic Memory

I though this article was kinda dull and boring. Apologies. However, the moment you mentioned Van Eck Phreaking caught my attention. It's totally amazing! What a hack!! Everybody's so paranoid about wireless hacks. This stuff is what spying is really about. Cool stuff but scary. Thanks for mentioning it. Here's a wiki link: http://en.wikipedia.org/wiki/Van_Eck_phreaking

foster.ryan
foster.ryan

Chad, Nothing kills the laughter faster than explaining your jokes right after them. If you don't assume that we will get the joke, I wouldn't include it. I was laughing at the therapist line, only to but cut short less than a second later by the explanation that it was a joke. Sad :(

JandNL
JandNL

We don't have gpg anything on our computer. What else do we need to check for to ensure we don't have unsecured memory?

JCitizen
JCitizen

But I have no idea if this is in the gnu pg category! I'm just a newbie; still trying to learn Grub and doing dual boot installations. They look easy but, you never know!

pgit
pgit

Someone ought to clone Chad Perrin repeatedly and loose an army of superb writers to cover all things technical. You've done it again. You have a gift for delivering the goods as clearly and concise as humanly possible, no matter how complex the subject. Wish I could write half as good...

boxfiddler
boxfiddler

thanks for that one. There is a lot I don't know about how certain things work, and this was very informative. I had not really thought before that information stored in RAM was briefly accessible to someone who knows what they are about, nor have I been particularly comfy with some of those 'insecure memory' messages I see on occasion when logged into Ubuntu. Now I have lots more to explore.

apotheon
apotheon

Is your memory insecure? Have you subjected the problem to examination by a "therapist" (security expert)? How do you deal with the matter of unsecured memory in your life -- or, if you haven't really dealt with it in the past, how will you deal with it now?

apotheon
apotheon

I didn't explain a joke -- I explained a metaphor. While I'm happy if I elicited a laugh with the use of the word "therapist", the really important point was to get people thinking about something, which is difficult to do if they don't know what it is I'm trying to get them thinking about. The "joke" was only secondary.

JCitizen
JCitizen

if he was on stage; and had good timing, sometimes it makes the joke even funnier!

apotheon
apotheon

I'm afraid that how you might check depends on the specific application -- and there may not be any way to check on that with a given application, other than some rather in-depth debugging and maybe fuzz testing.

frank.schafer
frank.schafer

... that's the question. GPG reports the problem. Other cryptographic soft maybe don't. If you don't know ... well IMHO the only possible solution to be sure about it is to build the soft with debug information and install (and use afterwards ;) a good debugger. Or you could --read the source Luke-- ;) Regards Frank

apotheon
apotheon

Thank you. That's the most interesting compliment I've received in a long time.

Ron_007
Ron_007

This is an idea I'm tossing out for discussion. I understand that Win 32 can't actually handle a full 4gb, depending on specific hardware and drivers it will handle a max of 2.75 - 3.5 gb. (ie http://blogs.msdn.com/hiltonl/archive/2007/04/13/the-3gb-not-4gb-ram-problem.aspx) If that is correct, would it be possible to assign the "unused" portion as a RAM drive and point the swap file at the RAM drive. Or is it only possible to carve the RAM drive out of the "recognized" RAM? Any comments are welcome.

synergy4results
synergy4results

First, I thank you all to keep in mind that I am NOT a server administrator, nor am I informed on server maintenance to any degree. I only know enough to know that you should be able to help me. Here is the issue: I have a small medical office that submits claims via FTP to a clearinghouse. Six months ago, the clearinghouse was "bought out". Before this time, we sent the claims encrypted using PGP software. Once the buyout occurred, they said it was no longer necessary. We send claims to the "new" named clearinghouse for several months for both doctors with no issue. Suddenly, in our "inbox", we started receiving the error message "gpg: WARNING: using insecure memory!gpg: please see http://www.gnupg.org/faq.html for more informationgpg: [don't know]: invalid packet" On calling the clearinghouse, you can't talk to an IT person, and their customer reps have been schooled to exhort that any issue not on their system must be in the software of the office it is coming from (i.e. - our computer). My understanding is that this error is a SERVER error, and we only have one PC (XP). The interesting part is that the file submission works for one set of accounts (same computer, nothing has changed) and not for the other set. Could any of you please confirm/deny my suspicion that the error message is some kind of wrong setting on "their" server? If so, can you give me enough information that I can sound intelligent enough that they don't brush me off completely again? I thank you in advance for your assistance.

Your Mom 2.0
Your Mom 2.0

I tell my memory how proud of itself it should be and remind it of all the neat things it helps my computer do.

groffg
groffg

Regarding the cheap shots of Windows, they are valid for the "home" versions of XP/Vista, but become less valid on the "professional/business" versions of XP/Vista. Specifics... RAM itself on all OSes can be analyzed directly via the "cold boot" attack scenario, given the tools. (I think this link will give you more info, but the link's currently timing out on me.) Regarding the content of the article (which was a good article, IMO), the negative focus on Windows was probably unwarranted, on the proviso that the user is using XP Pro or Vista Business, Enterprise, or Ultimate. In the case of Vista B/E/U, the contents of the pagefile can be encrypted (though it is not by default). If you use ReadyBoost, the contents of memory stored on the SSD is always encrypted. Further, on Vista E or U, the entire disk (well, OS volume) can be encrypted using BitLocker (as of SP1, other volumes in addition to the OS volume are supported). In that case, all data, programs, pagefiles, hibernation files, etc, are encrypted. If you're on XP Pro (or any of the Vista editions above), then you can allow non-admins to lock pages in memory via a group policy setting (use gpedit.msc at the Run prompt). That becomes less pivotal if your pagefiles are encrypted (and especially if your entire OS volume is encrypted). Hope that helps.

boxfiddler
boxfiddler

to take things too lightly, I am having a hard time getting past a giggle at your phraseology, above. Speaking for those of us facing certain 'age related idiosyncrasies' (for lack of a better way to put it), you have just asked the question/s of a lifetime! :D

JandNL
JandNL

This is really frustrating. First TechRepublic calls a security issue to our attention, then we are told we have to check each application on our computer separately to track down whether we even have the problem. We have hundreds of programs on our computer! Someone needs to create software to detect this and other security issues and provide ways to fix them. Fix-It Utilities, Norton, McAfee, etc. have all addressed one or more security issues. We are surprised and disgusted that there is no simple way to detect or address unsecured memory. If detection and/or the solution depends on the program, why didn't you just say that?

JandNL
JandNL

That doesn't really help. We need to know where to look in order to track down unsecured memory and how to fix the problem if we have any. We have three computers. Our primary computer is a SONY VAIO with WinXP SP3. Our newest laptop uses Vista SP1. Our old laptop has WinXP, not sure which SP.

Dr Dij
Dr Dij

now I'm feeling "insecure" about my "unsecured memory". :) I guess I'll need to hire an expensive security therapist to get over these feelings. And I've got a 'Big Chill' regarding recovery of memory for encryption keys where they put the PC or memory chip in a freezer at minus 50o I think to recover your boot encryption keys. Just one more thing - a vat of liquid nitrogen and sensitive memory tapping gear - to carry around as I climb down ropes to avoid laser zaps into secure terminal rooms to spook into systems.

apotheon
apotheon

As I understand it, the reason it can't use the whole 4GB is as follows: 1. A 32 bit OS doesn't have 64 bit memory addressing, so it can't directly use more than 2GB of RAM. 2. Many 32 bit OSes do provide extensible RAM addressing, however. 3. Part of the available RAM above 2GB has to be used to manage access to the additional RAM. 4. As a result, the "unused" half gigabyte of RAM when you get only 3.5 out of 4GB of RAM is, in fact, being used to provide access to the 1.5GB of RAM above and beyond 2GB. . . . so, in short, there is not unused RAM; there is only RAM that is not used as efficiently as it could be if you were using an OS that could handle 64 bit memory addressing natively. Take my explanation with the advisement that it may not be strictly accurate, though. I don't write memory addressing subsystems for OSes, so my understanding of how this works is third-hand.

apotheon
apotheon

I mentioned encryption as a way to mitigate the swap security issue. I mentioned that volatile RAM isn't entirely secure itself. The article mentioned the sort of thing you're using in an attempt to dispute what the article said about MS Windows. Cheap shots? Is it a cheap shot if it's true? I'm just reporting facts. If you take issue with that, I don't know what to tell you.

JCitizen
JCitizen

but I still love to joke about it; and besides it is just an excuse for my old timer's disease(another excuse HA!) :^0

apotheon
apotheon

One option is to encrypt a volume/directory, using something like TrueCrypt -- the PGP Corporation also offers excellent volume encryption software (PGPDisk) -- and store the stuff you want protected in that volume. There are a great many other high quality options for volume encryption -- including GELI encryption, loop-AES, GBDE, and CGD, for instance. My first criterion for determining what encryption software, though, tends to apply as much here as anywhere else: never trust encryption software that doesn't trust you. Another is to encrypt each file individually. For that, you could use PGP Corp's encryption solutions or, if you want a more "do it yourself" solution that doesn't cost anything, you could use GnuPG (a free/open source implementation of the OpenPGP standard). There are, of course, other options out there -- but most of them haven't been proven anywhere near as trustworthy as PGP and GnuPG.

JandNL
JandNL

The files we would want to protect are either Office files (Excel, Outlook emails, Word) or PDF files, at this point. There may be other types in the future. We would prefer to encrypt the original files, but encrypted storage is a good idea as well.

apotheon
apotheon

Are you looking for general-purpose storage encryption? If so, TrueCrypt is pretty good, by all accounts.

JandNL
JandNL

The only program we know that offers encryption on our computer, and it's generally not usable, is Outlook. What encryption programs would you recommend? We have a number of files we would prefer outsiders never got into.

apotheon
apotheon

This is primarily a problem with encryption software. Anything that doesn't deal with encryption is going to end up being stored on the hard drive after you turn off the computer anyway, unless it's not something you want to keep around beyond the moment you first use it. Anything you want to be able to store should be encrypted if you don't want it to be available to someone else who has physical access to your computer. That's the only way to really protect data that's stored on the hard drive, short of some kind of mechanism involving a magnetic field to junk everything on the drive -- and that might violate your notion of "protection" for data, anyway. It should pretty much be assumed that anything you don't encrypt is something you're not too worried about having stored on your hard drive. Anything you *do* encrypt should, at least in theory, be safe even when stored on the hard drive. As such, we're back to the fact that it's really only encryption software that is the sort of software for which this "virtual memory" issue is a problem. It's a problem for encryption software because, at some point, the manner in which you access encrypted data, and the data itself when it's decrypted, has to exist in memory -- and if your data in memory is being swapped out to persistent storage media, you may have a problem. So . . . check on your encryption software. The rest of the software shouldn't really be a problem, unless it somehow interferes with the protections afforded by the encryption software itself. Don't worry so much about whether the latest Grand Theft Auto version is using unsecured memory. Who cares if someone can access data on your high scores?

JCitizen
JCitizen

I now have installed most of my favorite AV/AS solutions, Open Office, and of course all the regular utilities like Adobe PDF Reader all work on 64 now. As I shop for software online, I see almost everything I'm looking for is not only Vista x64 compliant but XP x64 as well. I've even installed some programs like open source download managers that are not even written for 64bit that work fine. I didn't even use the XP 32 bit compatibility installer! That being, because I didn't know about it until recently. I noticed, in taskmanager, very few background processes run in *32 bit mode anymore, like they did a few months ago. But then I keep everything pretty well updated. Now if Macromedia/Adobe would straighten out Flash 10 problems, I'd be a happy camper for sure. I just run the 32 bit IE 7 when flash doesn't work, and this solves the problem everytime. I suppose this is why they've taken their sweet time on an code rewrite.

apotheon
apotheon

The major problem now is application compatibility, not drivers that exist for 32b and not 64b.

JCitizen
JCitizen

should be correct as I understand it too. I'm sure you're right Apotheon. Good thing that x64 hardware is getting cheap, and my Vista x64 is running smoothly, for now, anyway. Driver and application availability issues pretty much evaporated by the time I purchased it also. Very few driver issues so far.(miniscule to be exact)

apotheon
apotheon

1. I'm not really sure you're reading what I'm saying. I think you're reading [b]into[/b] what I'm saying, because some of your complaints seem to have little in common with the circumstances of what I [b]actually said[/b]. 2. By "not portable" I mean more than just "#ifdef may be necessary". If a significant percentage of your code is dependent on the use of a specific OS, you've left the land of software portability and entered that of different versions of the software for different OSes. I mean, sure, you could conceivably write two completely different programs from scratch that are intended to provide the same functionality, then cram them into the same source file with an #ifdef, but that's not exactly what I'd call "portable software design".

bsmgr_wmaster
bsmgr_wmaster

It is your article, therefore.... Explaning the reason for this "insecure memory" message and why locking memory is important was great. Telling everybody that any password on Windows is in any case not secured (or you have to crypt your disk) was NOT. Anyway, if you mean by not portable the fact that Windows is not a UX OS, and have therefore different APIs, well, you are right... But adding an #ifdef in a program to really port the program and fix the issue should not be no complicated....

apotheon
apotheon

Notice I said, in the article, that "In all my years of IT security work, I have never discovered a reasonable way to lock memory pages against being swapped to disk on MS Windows." Pay particular attention to the use of the word "reasonable". There is no [b]portable[/b] means of locking memory so it doesn't get swapped out to disk, because your program must make use of a Microsoft-only library, and there is no means of doing so that doesn't lead to some uncomfortable memory usage issues. These two limitations add up to an [b]unreasonable[/b] approach to locking memory so it won't get swapped out. Of course, explaining that in sufficient depth so that the casual reader of the IT Security Weblog would basically require writing an entire article just dedicated to that subject. As such, rather than ignoring the original intent of this article and writing six hundred words or so of off-topic programming minutiae, I used the word "reasonable" to equivocate. Sorry if that's not good enough for you.

bsmgr_wmaster
bsmgr_wmaster

I think the real answer to your question is inside the post. He says you CAN lock pages in Windows. Check the VirtualLock function in MSDN and you will see what I meam. I am starting to be sick of all the people who say "this is not possible in/this OS is really unsecure: Windows/linux/bsd/Macos (choose the one you hate)" but have no clue of the real answer.