Virtual memory and memory protection

Dear all,
  I went through one good tutorial on virtual memory in this website:
http://www.cs.umd.edu/class/spring2003/cmsc311/Notes/Memory/virtual.html

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

In comp.arch.embedded ssubbarayan <ssubba@gmail.com> wrote:
> Dear all,
>   I went through one good tutorial on virtual memory in this website:
> http://www.cs.umd.edu/class/spring2003/cmsc311/Notes/Memory/virtual.html

> The article says that virtual memory can help in protecting memory of
> the applications process.

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.

In article <1124452971.089292.157450@g49g2000cwa.googlegroups.com>,
"ssubbarayan" <ssubba@gmail.com> writes:
|> Dear all,
|>   I went through one good tutorial on virtual memory in this website:
|> http://www.cs.umd.edu/class/spring2003/cmsc311/Notes/Memory/virtual.html
|> 
|> 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.

"ssubbarayan" <ssubba@gmail.com> writes:
>   I went through one good tutorial on virtual memory in this website:
> http://www.cs.umd.edu/class/spring2003/cmsc311/Notes/Memory/virtual.html
>
> 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.

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:
http://www.garlic.com/~lynn/2005o.html#4 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
http://www.garlic.com/~lynn/subtopic.html#systemr

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"
http://www.garlic.com/~lynn/2004q.html#82 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005.html#0 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005.html#1 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005.html#3 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005.html#5 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005.html#32 8086 memory space [was: The Soul of Barb's New Machine]
http://www.garlic.com/~lynn/2005b.html#25 360POO
http://www.garlic.com/~lynn/2005b.html#39 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005b.html#66 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005c.html#28 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005c.html#44 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005d.html#53 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005d.html#54 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005d.html#55 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005d.html#65 [Lit.] Buffer overruns


some postings mentioning 360 store/fetch protect feature:
http://www.garlic.com/~lynn/2005.html#3 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005.html#5 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005.html#6 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2002f.html#13 Hardware glitches, designed in and otherwise
http://www.garlic.com/~lynn/2003j.html#27 A Dark Day
http://www.garlic.com/~lynn/2005c.html#18 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005c.html#33 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005c.html#47 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005h.html#9 Exceptions at basic block boundaries
http://www.garlic.com/~lynn/2005h.html#17 Exceptions at basic block boundaries
http://www.garlic.com/~lynn/2005j.html#36 A second look at memory access alignment
http://www.garlic.com/~lynn/2005j.html#37 A second look at memory access alignment
http://www.garlic.com/~lynn/2005j.html#39 A second look at memory access alignment
http://www.garlic.com/~lynn/2005l.html#27 How does this make you feel?

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

"Nick Maclaren" <nmm1@cus.cam.ac.uk> wrote in message 
news:de4jbr$3h$1@gemini.csx.cam.ac.uk...
>
> In article <1124452971.089292.157450@g49g2000cwa.googlegroups.com>,
> "ssubbarayan" <ssubba@gmail.com> writes:
> |> Dear all,
> |>   I went through one good tutorial on virtual memory in this website:
> |> 
> http://www.cs.umd.edu/class/spring2003/cmsc311/Notes/Memory/virtual.html
> |>
> |> 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.
>


Nor the best or most effective ;-)



dk 

ssubbarayan wrote:
> Dear all,
>   I went through one good tutorial on virtual memory in this website:
> http://www.cs.umd.edu/class/spring2003/cmsc311/Notes/Memory/virtual.html
> 
> 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
> 

Virtual memory and memory access protection are, in general,
two different subjects. However, virtual memory can be used to create
an individual address space where a process lives. Memory from other
processes is protected because each process can only access its own
memory, and memory belonging to other processes does not exist in its
address space.

Hi,
    Any examples of embedded systems with memory protection hardware
but no virtual memory ? Or the other way ?

I think the Blue Gene is also only physical memory, but more due to
performance reasons (don't swap to disk and take too long) than
anything else.

and this is not in reference to the question about embedded systems but
related to the 360 remark :-)

In article <1124517549.174484.174640@f14g2000cwb.googlegroups.com>,
drizzle <drizzle76@gmail.com> wrote:
>Hi,
>    Any examples of embedded systems with memory protection hardware
>but no virtual memory ? Or the other way ?

There certainly were quite a lot of the former, and possibly still are.
The latter is implausible, as most embedded systems require real-time
performance, and virtual memory makes that harder to deliver.

As an aside, one of my comments about the incompetence of the 8086 and
MS-DOS was that perhaps the simplest form of memory protection (and
certainly one of the oldest) is a simple write barrier.  I.e. an
address value which could be changed and below which writes simply
fail.  That needs one (1) simple instruction, one (1) register and
one (1) comparator - plus enough wiring to link it into the memory
access and bus error logic.  It would have improved the reliability
of early MS-DOS by a factor of 10, at least.

That sort of protection has always been standard on all except the
crudest embedded designs, though I am not close enough to the area
to know the actual mechanisms used.


Regards,
Nick Maclaren.