Virtual memory and memory protection

Dear all, I went through one good tutorial on virtual memory in this website:

formatting link

The article says that virtual memory can help in protecting memory of the applications process.That means each individual process running in the CPUs memory can be protected. I am not able to realise how this could help in protection?AFAIK,MMUs are the ones which help in memory protection and that too MMUS are implemented in Hardware where you could set some registers to prevent the processes from crossing boundaries and hence they can protect it. First of all is my understanding regarding MMUs correct>? I am not able to understand relation between Virtual memory and memory protection.Can some one throw some light on this?

I am not from computer science back ground so these things are new to me.So pardon my ignorance.

Looking farward for all your replys and advanced thanks for the same, Regards, s.subbarayan

Reply to
ssubbarayan
Loading thread data ...

As stated, that's nonsense. It would be more correct to state that virtual memory management and memory protection require so very similar features of the memory interface of a CPU that they almost always are implemented together, i.e. they're either both present in a given CPU, or both lacking. The device that enables both these things is customarily called an MMU.

In a nutshell, an MMU is a unit that sits between real memory and the rest of the CPU. It is programmed to know which addresses the currently running program is allowed to access, how, and will generate a special signal to the CPU if these restrictions are violated: the "segmentation fault", or "page fault". Virtual memory is then implemented by handling this interrupt and copying memory contents from secondary storage into RAM; protection by killing the program if it oversteps its boundaries completely.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

In article , "ssubbarayan" writes: |> Dear all, |> I went through one good tutorial on virtual memory in this website: |>

formatting link
|> |> The article says that virtual memory can help in protecting memory of |> the applications process.That means each individual process running in |> the CPUs memory can be protected. |> I am not able to realise how this could help in protection?AFAIK,MMUs |> are the ones which help in memory protection and that too MMUS are |> implemented in Hardware where you could set some registers to prevent |> the processes from crossing boundaries and hence they can protect it. |> First of all is my understanding regarding MMUs correct>? |> I am not able to understand relation between Virtual memory and memory |> protection.Can some one throw some light on this?

Essentially, yes, but you are still very confused. However, that page doesn't help because it is factually incorrect in several important respects - many of which are precisely on your point.

At the most fundamental level, virtual memory and memory protection are two separate and largely orthogonal concepts. There have been systems with all four possibilities (neither, each one and both). And, in a system with no virtual memory but memory protection, it is indeed done by the MMU. The System/360 was one such system.

What IS true is that nowadays memory protection IS done by the virtual memory mechanism. I.e. the protection is done as a side- effect of looking up the physical address. But that is not the only way to do it.

Regards, Nick Maclaren.

Reply to
Nick Maclaren

class assignment?

standard 360s (in the 60s) were real memory (no virtual memory) and offered store protect & fetch protect feature.

they also offered supervisor state and problem state ... supervisor state allowed execution of all instructions (including state change control and memory ptotect specification). problem state only allowed execution of a subset of instructions.

store protect feature typically prevented applications from storing into areas that they weren't allowed to ... like kernel code and/or other applications.

fetch protect prevented applications from even looking/fetching regions they weren't suppose to (fetch protect also implied store protect).

360 model 67 also offerred virtual memory support, it was used to separate things into totally different domains. not only could applications be prevented from fetching or storing data into areas they weren't suppose to (outside of their virtual address space) ... but they possibly weren't even aware that such areas existed. this was also used to implement virtual machines. recent reference to some early virtual machine work in the 60s:
formatting link
Robert Creasy, RIP

some number of virtual address space architectures also support r/o segment protection ... i.e. virtual address space ranges that an application can't store into. the original 370 virtual memory hardware was supposed to include r/o segment protect. vm370 was going to use this to protect common instructions and data areas that could be shared across multiple different virtual address spaces (only needing one physical copy of the virtual pages shared across large number of different application address spaces but still protected). when r/o segment protect was dropped before product announce ... vm370 had to fall back to a hack using (360) store protect ... to protect shared pages. the original relational/sql database implementation was done on vm370 and made use of various kinds of shared segments

formatting link

a "no-execute" feature has been added to some hardware recently. this is attempting to address the massive number of buffer overruns vulnerabilities typically associated with c-language implemented applications. attackers have malicuous executable code introduced via various kinds of data transfers and then contrive to have execution transfered to the malicuous code. system facilities use hardware features to mark pure data areas regions as "no-execute". Areas of (virtual address space) memory that are marked non-executable can be fetched &/or stored ... but the hardware instruction fetch will interrupt if instructions are fetched from such a area.

some past postings mentioning "no-execute"

formatting link
[Lit.] Buffer overruns
formatting link
[Lit.] Buffer overruns
formatting link
[Lit.] Buffer overruns
formatting link
[Lit.] Buffer overruns
formatting link
[Lit.] Buffer overruns
formatting link
8086 memory space [was: The Soul of Barb's New Machine]
formatting link
360POO
formatting link
[Lit.] Buffer overruns
formatting link
[Lit.] Buffer overruns
formatting link
[Lit.] Buffer overruns
formatting link
[Lit.] Buffer overruns
formatting link
[Lit.] Buffer overruns
formatting link
[Lit.] Buffer overruns
formatting link
[Lit.] Buffer overruns
formatting link
[Lit.] Buffer overruns

some postings mentioning 360 store/fetch protect feature:

formatting link
[Lit.] Buffer overruns
formatting link
[Lit.] Buffer overruns
formatting link
[Lit.] Buffer overruns
formatting link
Hardware glitches, designed in and otherwise
formatting link
A Dark Day
formatting link
[Lit.] Buffer overruns
formatting link
[Lit.] Buffer overruns
formatting link
[Lit.] Buffer overruns
formatting link
Exceptions at basic block boundaries
formatting link
Exceptions at basic block boundaries
formatting link
A second look at memory access alignment
formatting link
A second look at memory access alignment
formatting link
A second look at memory access alignment
formatting link
How does this make you feel?

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Reply to
Anne & Lynn Wheeler

Nor the best or most effective ;-)

dk

Reply to
Dan Koren

On 19 Aug 2005 05:02:51 -0700, "ssubbarayan" wrote, in part:

It certainly does seem odd, at first sight.

After all, if a computer has hardware bounds registers, or hardware identifiers (the "memory key" of the 360), associated with memory, these things would not apply to the data from memory stored on a disk.

But on the other hand, if a computer had _no_ hardware to assist in protecting memory, the operating system could *swap out all memory associated with other processes* while one program is running. Assuming access to disk files can also be controlled and limited, this _would_ protect memory.

John Savard

formatting link
Usenet Zone Free Binaries Usenet Server More than 140,000 groups Unlimited download
formatting link
to open account

Reply to
John Savard

There was memory protection before there was virtual memory. When virtual memory started showing up, one big problem I remember was correctly faulting, then restarting instructions which included a memory reference to something which wasn't (currently) present. Early instances of this were auto-growing the PDP-11 stack (V7 UNIX)--I remember processor model specific code to handle various tricky instructions.

Andy Valencia

Reply to
Andy Valencia

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.