1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

Virtual memory and memory protection

Discussion in 'Embedded' started by ssubbarayan, Aug 19, 2005.

  1. ssubbarayan

    ssubbarayan Guest

    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
     
    ssubbarayan, Aug 19, 2005
    #1
    1. Advertisements

  2. 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, Aug 19, 2005
    #2
    1. Advertisements

  3. |> 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.
     
    Nick Maclaren, Aug 19, 2005
    #3
  4. 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, Aug 19, 2005
    #4
  5. ssubbarayan

    Dan Koren Guest


    Nor the best or most effective ;-)



    dk
     
    Dan Koren, Aug 19, 2005
    #5
  6. ssubbarayan

    drizzle Guest

    Hi,
    Any examples of embedded systems with memory protection hardware
    but no virtual memory ? Or the other way ?
     
    drizzle, Aug 20, 2005
    #6
  7. 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.
     
    vipin.sachdeva, Aug 20, 2005
    #7
  8. and this is not in reference to the question about embedded systems but
    related to the 360 remark :)
     
    vipin.sachdeva, Aug 20, 2005
    #8
  9. 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.
     
    Nick Maclaren, Aug 20, 2005
    #9
  10. The PPC440 core in Blue Gene has virtual memory. What it doesn't have is
    cache coherence.
     
    =?ISO-8859-1?Q?Niels_J=F8rgen_Kruse?=, Aug 20, 2005
    #10
  11. The 8086 had a very primitive "memory protection" system, since the
    memory could only be accessed directly through 4 segment registers
    (CS, DS, SS and ES), thus only up to 256 KiB could be corrupted of the
    total 1 MiB address space at any time, which gave some kind of
    protection for runaway programs. Of course, you still could
    deliberately load the segment registers.

    IIRC, the 80286 in protected mode limited what the user could do with
    the segment registers but did not yet support virtual memory.

    In practice, any processor using the segmentation model would use
    memory protection without virtual memory.

    For instance the PDP-11 mapped the 64 KiB program address space to the
    256 KiB or 4 MiB physical memory using 8 (or 16 for I/D space) memory
    base and segment size registers that were not normally visible to the
    user. Any reference outside the mapped address range (or a write
    access to read-only segment) would be trapped.

    In order to avoid the discussion is PDP-11 an embedded processor :),
    these features were available on the K-11 chip set as well as on the
    J-11 chip.
    If someone implements the virtual memory features (including page
    tables and instruction suspension and/or restart), it would be foolish
    not to implement the memory protection.

    Paul
     
    Paul Keinanen, Aug 20, 2005
    #11
  12. ssubbarayan

    Tauno Voipio Guest

    The 80286 System Programmers Reference showed a way to
    provide virtual memory using the segmentation mechanism,
    but AFAIK nobody has implemented it as such. The segment-
    based virtual memory makes it pretty difficult to avoid
    memory fragmentation (both real and virtual memory).
     
    Tauno Voipio, Aug 20, 2005
    #12
  13. Any hardware, that is capable of detecting non-existent memory
    references or unsupported op-codes by trapping can be used to
    implement some kind of virtual memory. The unsupported op-code
    trapping can be used to emulate non-existent instructions (such as
    floating point) and the non-existent address to load the missing
    page/segment.

    However, when emulating missing op-codes or addresses, it is essential
    to be able to continue from the middle of instruction at the point it
    was interrupted on undo any modifications (such as pointer
    autoincrements) done by the first part of the instruction. If there is
    no hardware support for this, quite a lot of software will be
    required, before the instruction can be completed.

    One other very desirable feature of a virtual memory processor is the
    hardware implementation of the "dirty bit" and recently accessed page
    concept or you end up in similar implementations as in WinNT (which in
    those days supported multiple architectures), in which pages were
    randomly moved to the output queue to be written to the page file.
    Heavily used pages were often page faulted back from the output queue
    back to the working set before it was written to the page file. Thus
    frequently used pages remained in memory, while seldom used pages
    reached the end of the queue and were written to the page file, thus
    implementing some kind of the LRU (Least Recently Used) algorithm:).
    Is it any better for paged virtual memory systems (at least for the
    virtual memory) ? Try to allocate 1MiB of contiguous virtual memory
    from the WinNT e.g. for a memory mapped file ...

    Paul
     
    Paul Keinanen, Aug 20, 2005
    #13
  14. ssubbarayan

    Tauno Voipio Guest

    No - that was the reason a Windows-based monitoring system
    run short of available (virtual) memory in 13 +/- 1 days
    when run 24h/day.

    The paged system solves the fragmentation problem at
    the real memory level: a page fits any page frame.

    However, the fragmentation problem stays there for
    the logical addresses (virtual memory). For a system
    with plenty of processes the remaining fragmentation
    problem is only in the process itself - not system-
    wide as the real memory fragmentation.
     
    Tauno Voipio, Aug 20, 2005
    #14
  15. ssubbarayan

    CBFalconer Guest

    Why? As long as the segment registers are not visible to the user,
    and include limits, the OS can move contents about freely when a
    segment allocation fails for lack of a large enough free space. If
    combined with virtual memory it only needs to save the moved
    segment when it is dirty. When combined with page tables things
    become even easier.

    The advantage of proper segments with limits, privileges etc. is
    that it is much easier to detect erroneous addresses.
     
    CBFalconer, Aug 20, 2005
    #15
  16. ssubbarayan

    John Savard Guest

    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
    http://www.quadibloc.com/index.html
    _________________________________________
    Usenet Zone Free Binaries Usenet Server
    More than 140,000 groups
    Unlimited download
    http://www.usenetzone.com to open account
     
    John Savard, Aug 20, 2005
    #16
  17. 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
     
    Andy Valencia, Aug 20, 2005
    #17
  18. ssubbarayan

    dlharmon Guest

    Analog Devices Blackfin DSP has memory protection hardware, but no
    vitual memory.

    Darrell Harmon
    http://dlharmon.com/dspcard
     
    dlharmon, Aug 21, 2005
    #18
  19. vipin.sachdeva, Aug 21, 2005
    #19
  20. If you google for "Memory Protection Unit", you get quite a few hits,
    including some from Atmel, STMicroelectronics, ARM, Samsung, to name a few.
    So this seems to be a popular concept in embedded systems.

    And this makes sense, since it is mostly protection that embedded
    systems need:

    - Swapping, as enabled by virtual memory, is usually out of the question
    because an embedded system is designed to have just the physical resources
    it needs to perform its job, even under worst-case conditions. There is
    no "overcommitment" as in Unix and therefore there is no use for a backing
    store to help out, should the system be requested to fulfil the promises
    it has made earlier ;-)

    - MMU address translation could be helpful to handle memory fragmentation,
    but embedded systems have dealt with this for ages by just avoiding run-time
    allocations alltogether: It is common pratice to have all resources assigned
    during bootstrap. Some RTOS approaches (e.g. OSEK) even enforce this
    strategy.

    Memory protection, however, does help to protect applications from
    each other (one program corrupting, or even spying another program's
    memory), which is very useful, especially with the ever-increasing
    complexity of embedded systems, i.e. multiple programs from different
    vendors running in one system.
    As others have said: if you already have virtual memory, it would be
    silly not to implement protection. However, most virtual memory systems
    do have functions to selectively circumvent protection (better known by
    the name of "shared memory").

    Rob
     
    Robert Kaiser, Aug 22, 2005
    #20
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.