Virtual memory and memory protection

In article <1124517549.174484.174640@f14g2000cwb.googlegroups.com>,
	"drizzle" <drizzle76@gmail.com> writes:
>     Any examples of embedded systems with memory protection hardware
> but no virtual memory ?

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.

> Or the other way ?
 
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                     email: rkaiser AT sysgo DOT com
SYSGO AG                          http://www.elinos.com
Klein-Winternheim / Germany       http://www.sysgo.com

drizzle wrote:

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

ARM946 is an example that have MPU and no MMU.
http://www.arm.com/products/CPUs/ARM946E-S.html

Many applications requires only memory protection, but no need for
virtual memory. MMU circuit size is bigger than MPU, and as a result
it consume more power -> not good for battery powered products.
So some of embedded CPU cores only provide MPU but no MMU.

regards
Joe

Tauno Voipio wrote:
> 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).


OS/2 1.x (the 16-bit versions), all implemented segment based virtual
memory on the 286.  So did at least one 286 *nix port.

Compacting real memory to reduce fragmentation is quite
straightforward, the OS can easily move any in-memory segment that is
eligible for paging (which most would be).

On 2005-08-22, robertwessel2@yahoo.com <robertwessel2@yahoo.com> wrote:
>
> Tauno Voipio wrote:
>> 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).
>
>
> OS/2 1.x (the 16-bit versions), all implemented segment based virtual
> memory on the 286.  So did at least one 286 *nix port.

IIRC, the 286 port of Coherent (a v7 clone from Mark Williams
Co.) did segment based VM.  Each process had 64K of text space
and 64K of data/stack space.

> Compacting real memory to reduce fragmentation is quite
> straightforward, the OS can easily move any in-memory segment
> that is eligible for paging (which most would be).

-- 
Grant Edwards                   grante             Yow!  Yow! Are you the
                                  at               self-frying president?
                               visi.com            

Nick Maclaren wrote:

> In article <1124517549.174484.174640@f14g2000cwb.googlegroups.com>,
> drizzle <drizzle76@gmail.com> wrote:

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

Does S/360 qualify as embedded?

> 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.

You can always do protection by marking all pages belonging
to others as invalid.  You do need some kind of system/user mode
bit, though.

> 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.

Standard on many minicomputers...  Well, memory management could
always be done external to the microprocessor.  I am not sure that
the 8086 could decode the address and signal NMI fast enough, though.

The 8086, as far as I remember, was an improved 8080.
It wasn't supposed to be used for all the things people actually
did with it.

-- glen

In article <XOWdnUgHUL1xs5feRVn-1g@comcast.com>,
glen herrmannsfeldt  <gah@ugcs.caltech.edu> wrote:
>
>> 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.
>
>You can always do protection by marking all pages belonging
>to others as invalid.  You do need some kind of system/user mode
>bit, though.

Not at all.  Why should you?

The only reason that you need privilege levels is to protect against
malice; if all you are doing is protecting against error, they are
of marginal use.


Regards,
Nick Maclaren.

Nick Maclaren wrote:
(snip, I wrote)

>>You can always do protection by marking all pages belonging
>>to others as invalid.  You do need some kind of system/user mode
>>bit, though.

> Not at all.  Why should you?

> The only reason that you need privilege levels is to protect against
> malice; if all you are doing is protecting against error, they are
> of marginal use.

If page table are in a different address space (use different
instructions to modify) then I agree.  Otherwise there is the
possibility of accidental modification of page tables.

-- glen

glen herrmannsfeldt wrote:

> The 8086, as far as I remember, was an improved 8080.
> It wasn't supposed to be used for all the things people actually
> did with it.

The 8086 is the base model of current PC processors. The
current Pentiums, Athlons and whatnot all still can
use the basic 8086 instruction set, but they do not
understand about 8080 instructions.

The (slightly) improved 8080 was 8085 (and from a
competitor, the Z80). The main difference was
the IC process and only a 5V power supply instead
of three voltages.

NEC made a twin-mode processor, V80, which could
run in either 8086 or 8080 mode.

-- 

Tauno Voipio
tauno voipio (at) iki fi

In article <WZydnfJQyLKhK5feRVn-hA@comcast.com>,
glen herrmannsfeldt  <gah@ugcs.caltech.edu> wrote:
>
>>>You can always do protection by marking all pages belonging
>>>to others as invalid.  You do need some kind of system/user mode
>>>bit, though.
>
>> Not at all.  Why should you?
>
>> The only reason that you need privilege levels is to protect against
>> malice; if all you are doing is protecting against error, they are
>> of marginal use.
>
>If page table are in a different address space (use different
>instructions to modify) then I agree.  Otherwise there is the
>possibility of accidental modification of page tables.

There are many other solutions to that - even assuming that you
are doing protection by page tables, which is not a given (as there
are many other approaches).  For example, a page table entry can
include a checksum (actually a hash), which will reduce the
probability of that to an arbitrarily low value.

I have implemented precisely that in a C run-time system to protect
'my' data against user corruption.  It works.


Regards,
Nick Maclaren.

On Tue, 23 Aug 2005 06:13:46 GMT, Tauno Voipio
<tauno.voipio@iki.fi.NOSPAM.invalid> wrote:

>glen herrmannsfeldt wrote:
>
>> The 8086, as far as I remember, was an improved 8080.
>> It wasn't supposed to be used for all the things people actually
>> did with it.
>
>The 8086 is the base model of current PC processors. The
>current Pentiums, Athlons and whatnot all still can
>use the basic 8086 instruction set, but they do not
>understand about 8080 instructions.

When the 8086 came out there was a lot of marketing hype about the
compatibility between 8080 and 8086. It was quickly found out that
these are not binary compatible, but that some assembler macros or
some translating software to automatically convert 8080 assembler to
8086 assembler.  However, I have never heard anyone using these
translation tools :-).

Anyway, much of the stupid features from the 8008/8080 were carried to
the 8086 for this "compatibility" issue and again, this tradition went
on with 386 and now even 64 bit processors. It had made much more
sense to design the 8086 instruction set from scratch and include a
mode bit to run the 8080 code as is on the same processor.

Paul