Virtual Memory

Started by
18 comments, last by frob 6 years, 9 months ago

For hard drive encryption, you've got BitLocker and other full-disk-encryption systems.  For RAM encryption, there are things like AMD's SME or Intel's SGX.

Advertisement
4 hours ago, jpetrie said:

This doesn't seem like a great reason to do this, but whatever. That unencrypted data can be read right out of RAM just as easily as reading it from the page file for somebody who is interested. There are also ways to ensure that a page file is cleared when users log out, and so on; these are all security-policy-level issues that should be in the domain of the user or the system administrator.

Well if someone wanted to do that remotely, it would be spyware, and at least there's anti-spyware available.  However, while something's in RAM, it only exists until the computer is restarted, but once something's on a hard drive, even if it's deleted it can still be found later, even if you need certain forensic tools to search the hard drive.

4 hours ago, jpetrie said:

Along the same vein, Windows knows what your password is, right? Otherwise how do you log in. That doesn't mean the OS provides you a good, old-fashioned, "GiveMeTheUserPasswordInPlainText()" API you can call.

Touche.

1 minute ago, myvraccount said:

once something's on a hard drive, even if it's deleted it can still be found later, even if you need certain forensic tools to search the hard drive.

There are ways to perform secure writes that make this harder or impossible, of course. That's why these things are generally user concerns, and generally should not be things your application tries to enforce on a user (possibly at their own expense). 

2 hours ago, jpetrie said:

There are ways to perform secure writes that make this harder or impossible, of course. That's why these things are generally user concerns, and generally should not be things your application tries to enforce on a user (possibly at their own expense). 

I might typically agree if I didn't want to send information to said user and make sure that it is kept secure.  And I don't see how it would be at anyone's "expense" if I'm implementing the security into the software.

13 minutes ago, myvraccount said:

said user and make sure that it is kept secure

If you trust the user, you should trust them to take the appropriate precautions correctly. If you don't trust the user, you're already mostly screwed because they can get the secure (decrypted) information via a number of easy ways and distribute it, circumventing all your attempts to hide it. Because it's on their computer, where they have full control.

13 minutes ago, myvraccount said:

And I don't see how it would be at anyone's "expense" if I'm implementing the security into the software.

I don't mean monetarily. By forcing them to disable the page file, you are potentially forcing them to make their computer act significantly slower or underperform in a variety of ways. Similarly by forcing them to use a secure delete on any disk, you're doing a similar thing. You're trying to force them to make particular choices for options with a larger global impact. This might be acceptable for a closed computing environment, but it's usually not for general-purpose software.

It's just seems like a waste of time since so much of is is easily bypassed by the user. It's like you're spending all this time and energy, and making big decisions on the user's behalf, to lock up and guard the front door. And then you're ignoring the back window, which is wide open.

But again, if that's how you want to waste your time, go for it. You appear to have your mind made up. Good luck.

 Like others have pointed out before and I suggest you take heed..You are trying to do the job of the Operating System...if thats the case why are you even using one? Why not just write your own OS that more secure than every other OS out there. Its the job of the OS to virtualize memory( with HW support) and to manage swapping to and from a pagfile. Just like its next to impossible for an errant program to write into the memory owned by your program, this also extend to the swap file so whatever security concerns you have are unwarranted.

2 hours ago, myvraccount said:

is because it's a huge security flaw!  If a program encrypts anything before saving

Now I see why you care about this.

You've been asking many questions about security and encryption, attempting to hide your identity by naive routes like the system's ownership information, and failing to understand even basic concepts of how security trust chains function or how you cannot trust anything about the system, even its own memory.

As discussed, the solution you jumped to is flat-out wrong. Disabling the page file is a terrible idea.  

 

There is a flag you can set to encrypt the page file if you want, although it comes with an added serious performance penalty for any program that uses the page file and already suffers a performance penalty for that, too. The same is true on Linux and other systems. You can enable an encrypted swap/page system if you want, but it comes with a serious performance hit.

Using encrypted swap files is something the system administrators -- not you as a program developer --- decide to do.

And if you cannot trust the swap file on your system then you also cannot trust memory on your system. At that point your system is already compromised and nothing you do can save you.

3 hours ago, jpetrie said:

If you trust the user, you should trust them to take the appropriate precautions correctly. If you don't trust the user, you're already mostly screwed because they can get the secure (decrypted) information via a number of easy ways and distribute it, circumventing all your attempts to hide it. Because it's on their computer, where they have full control.

Let me put it this way.  I trust the user's intentions, but not necessarily their ability to follow directions when it comes to technical issues, so I'd rather have those things automated.

3 hours ago, jpetrie said:

I don't mean monetarily. By forcing them to disable the page file, you are potentially forcing them to make their computer act significantly slower or underperform in a variety of ways. Similarly by forcing them to use a secure delete on any disk, you're doing a similar thing. You're trying to force them to make particular choices for options with a larger global impact. This might be acceptable for a closed computing environment, but it's usually not for general-purpose software.

I don't see how disabling the paging will make programs run slower.  Frankly, if everything ran just in RAM, it would be a lot quicker.  And you can get a ton of RAM cheaply these days, so to me paging seems sort of antiquated anyway, unless you're going to run programs that have HUGE amounts of data.

And this isn't for general-purpose software.  It's for software that I'm developing for specific people, not to distribute to the general population, if that's what you're implying.

I think you've got your answer then.  This is becoming abusive, so stopping it now before it gets worse.

There is no flag to detect presence of virtual memory because that is always a thing on your platform and cannot be adjusted.  There is no flag to indicate paging files. If you want to make changes to your page files or swap files, such as encrypting them or removing them completely, then those changes must be done by a system administrator completely outside your program.

 

So people are physically seizing your associates hard-drives to forensically extract encrypted information. You're writing software to thwart this, and it has to be idiot proof...

So you're working for a crime/sex/terrorism cell and are hiding from the police? What the fuck does this have to do with Game Dev?

This topic is closed to new replies.

Advertisement