ebergman@isis.cs.du.edu (Eric Bergman-Terrell) (05/25/91)
I understand that an UAE is raised when (among other conditions), a program has written to an address outside of its address space. How is this detected? Furthermore, is every "wild write" caught in this manner? If no, what sort of mayhem goes undetected? Terrell
ed@odi.com (Ed Schwalenberg) (05/28/91)
In article <1991May25.054957.1151@mnemosyne.cs.du.edu> ebergman@isis.cs.du.edu (Eric Bergman-Terrell) writes:
I understand that an UAE is raised when (among other conditions), a program
has written to an address outside of its address space.
How is this detected? Furthermore, is every "wild write" caught in this
manner? If no, what sort of mayhem goes undetected?
In protected mode (standard or enhanced mode) addresses consist of a
selector number and an offset. A selector number is an index into a
hardware table (called the Local Descriptor Table or LDT, if you want
to Read The Intel Manual) of 8192 "segment descriptors". For the
purposes of this explanation, the segment descriptors contain 3 items
of information: whether the segment is currently valid, the length of
the segment in bytes, and whether it's a code segment or a data segment.
Now for The Rules:
1. Whenever you use a selector, it must be valid. In other words, it
must be something Windows gave you and has not taken away, not a
random 16-bit number. Further, you may not put a random 16-bit
number into a segment register like ES, even if you never use it to
reference memory. (Zero is special in this regard: you can put 0 in
a segment register but you can't reference memory with it.)
2. You may not access data beyond the length of the segment, code or data.
3. You may not execute code in a data segment.
4. You may not write to a code segment.
All of these things (and many others) cause the processor to generate
interrupt #13, General Protection Violation, which (along with other
similar errors) Windows translates into UAE. For the gory details, read
the 386 processor manual.
All of your Windows programs use the same LDT, which means that if you
get "lucky", a wild write can clobber some data belonging to another
program, including Windows or DOS itself. A wild write will do one of three
things: clobber your own data, clobber someone else's, or generate a UAE.
It's extremely difficult (but not impossible) to trash a code segment.
One of the selectors maps the LDT itself; if you manage to write over
it you can really lose big!
Each DOS box has its own LDT, so a DOS app generally can't bash the Windows
world and vice versa.bonneau@hyper.hyper.com (Paul Bonneau) (05/29/91)
In article <1991May25.054957.1151@mnemosyne.cs.du.edu> ebergman@isis.cs.du.edu (Eric Bergman-Terrell) writes: > >I understand that an UAE is raised when (among other conditions), a program >has written to an address outside of its address space. > >How is this detected? Furthermore, is every "wild write" caught in this >manner? If no, what sort of mayhem goes undetected? > I think I can answer for the 386 in enhanced mode. Not so sure about 286 or standard mode. Anyway... The "wild write" you speak of will generate an interrupt 13, Generae Protection exception. It is generated by the memory management hardware in the chip. The interrupt handler for this will generate the UAE MessageBox and terminate the app. Only thos writes outside the bounds of a selector can be detected. Once we have win32 (now called Windows 4 apparently) where an application will have a virtual address space of several gigabytes, wild writes will be much harder to detect. One of the (few) benefits of the 386's segmented architecture is that it *does* make memory trashing easier to find. cheers - Paul Bonneau.
pena@brainware.fi (Olli-Matti Penttinen) (05/29/91)
In article <1991May28.173139.8139@hyper.hyper.com> bonneau@hyper.hyper.com (Paul Bonneau) writes:
Once we have win32 (now called Windows 4
apparently) where an application will have a virtual address
space of several gigabytes, wild writes will be much harder
to detect.
cheers - Paul Bonneau.
Quite the opposite, I think. In Windows 3.0 all applications except
for DOS boxes share the same address space, thus allowing an
application to merrily overwrite any data, including Windows' itself.
With a full 386 addressing scheme, this becomes impossible. By the
same token, a 32 bit virtual address space DOES NOT mean that all
addresses are valid. You can only use memory that the operating
system gave you and none else. Think about it: virtual memory is not
endless, either. For a virtual address to be valid, the page must be
in RAM or stored in the swappping/paging device. I doubt very many
machines have the luxury of being able to allocate 4 GB RAM/diskspace
for each task :-)
==pena
--
Olli-Matti Penttinen <pena@brainware.fi> | "When in doubt, use brute force."
Brainware Oy | --Ken Thompson
P.O.Box 330 +----------------------------------
02151 ESPOO, Finland Tel. +358 0 4354 2565 Fax. +358 0 461 617ed@odi.com (Ed Schwalenberg) (05/29/91)
In article <1991May28.173139.8139@hyper.hyper.com> bonneau@hyper.hyper.com (Paul Bonneau) writes:
Only thos writes outside the bounds of a selector can be
detected. Once we have win32 (now called Windows 4
apparently) where an application will have a virtual address
space of several gigabytes, wild writes will be much harder
to detect. One of the (few) benefits of the 386's segmented
architecture is that it *does* make memory trashing easier
to find.
It is possible to use the page-protection features of the 386
architecture to implement much finer-grained memory protection,
both between applications and within a single application. This
will let the programmer have the best of both worlds: a uniform
address space and a high degree of protection against misbehaved
programs.
Whether the developers of future PC systems like Win32 or OS2 3.0
actually take advantage of the power of the chip architecture
remains to be seen.barry@gpu.utcs.utoronto.ca (Barry Lay) (05/30/91)
In article <1991May29.164121.27600@odi.com> ed@odi.com (Ed Schwalenberg) writes:
#
# Whether the developers of future PC systems like Win32 or OS2 3.0
# actually take advantage of the power of the chip architecture
# remains to be seen.
They won't have any choice, if Alistair Banks' statements are correct. In
order for Win32 or NT or whatever it is called to get B2-level certification,
"The TCB shall maintain a domain for its own execution that protects it from
external interference or tampering ... Features in hardware, such as
segmentation, shall be used to support logically distinct storage objects
with separate attributes (namely: readable, writeable)." (from DOD 5200.28-STD,
3.2.3.1.1 System Architecture). Now that we have the official mumbo-jumbo,
does anybody out there who is familiar with the Orange Book care to comment
on how useful a B2 rating will be on the limited set of functions that will
be supported by NT? Is it going to prevent downgrades via the clipboard?
Enforce security labels on printed output?
Just curious.
Barryalistair@microsoft.UUCP (Alistair BANKS) (05/31/91)
In article <1991May29.164121.27600@odi.com> ed@odi.com (Ed Schwalenberg) writes: >In article <1991May28.173139.8139@hyper.hyper.com> bonneau@hyper.hyper.com (Paul Bonneau) writes: >> space of several gigabytes, wild writes will be much harder >> to detect. One of the (few) benefits of the 386's segmented > >It is possible to use the page-protection features of the 386 >architecture to implement much finer-grained memory protection, >both between applications and within a single application. This >will let the programmer have the best of both worlds: a uniform >address space and a high degree of protection against misbehaved >programs. Indeed, as pointed out by Ed Schwalenberg, we will be using page protection for all 32-bit Windows processes on all implementations of Win32, including Dos implementations. All 16-bit Windows apps, for compatibility, will continue to run in one thread of one process. Thus they will share the same address space, and be non-preemptive with respect to each other, while being pre-emptive w.r.t the system and any win32 app. Alistair Banks Systems Division, Microsoft.