Johnny Billquist wrote:
Might be, but I can't figure out when. But I
guess if you wanted to
map something else into memory as well (such as a shared library),
which wasn't position independent, and which expected to be at APR7...
I just mentioned it since it's technically no difference between any
of the APRs for a user program.
Jerome Fine replies:
I agree as well. The point is that splitting the available memory into two
or more sections never helps as far as I have ever found.
But you do mention an important point. I once had to deal with a device
driver that mapped the IOPAGE registers to APR5 (120000 - 137776)
since it had to use APR6 and APR7 addresses (140000 - 177776) to
access a shared library. It was very strange to see the CSR for a serial
port referenced as 136500. It was even worse to debug the code since
every debug software package assumed that the IOPAGE was correctly
located in APR7 addresses. Hardware ODT was about the only way!
Anyway, the overhead of mapping in the I/O page is a
one time cost.
Which is acceptable!
However, with normal privileged programs, the I/O page
is always
present at APR7 even if you don't do anything.
Also VERY helpful. However, if so, then would there be any reason
why APR7 could not be mapped to user memory in the normal manner so
that the user program has a full 65536 bytes of address space, but
then the PREVIOUS DATA space is mapped to KERNEL providing the user
with complete access to the IOPAGE registers via that 2 instruction
example that I gave at the beginning? I can't see that there would
be any greater loss of security since being able to change the IOPAGE
registers either directly or indirectly is just as damaging!
Please comment?
You can have a privileged program that isn't mapped to the I/O page.
The problem is that the kernel sets the PSW at various times for you,
so you cannot expect to be able to keep control of the previous mode
field of the PSW from your program. RSX is multitasking. Things can
change between one instruction and the next in your task. One typical
mistake people might do is to manipulate the APR registers themself,
just because they are accessible, and the program is privileged. This
won't work, since a contect switch can occur at any time, and the APR
registers are not preserved between context switches. Instead, they
are recreated from scratch, based on your mapping context every time
the task is selected to run.
So in that case, it fails not because of security considerations, but
because of system design. You need to have the I/O page mapped in
properly.
Put another way: RSX makes sure the previous mode field is set to user
at every occasion the system have executed in kernel mode and goes
back to user mode. That is a security design. To make this different
for privileged programs would incur extra costs everywhere, whithout
any real gain. Privileged programs can get around this "problem"
anyway, but not by running in user mode and expecting the previous
mode field to be set to kernel.
Thank you for this information on RSX-11. This aspect of RSX-11 certainly
precludes using the PREVIOUS DATA mode bits in the PSW.
Under RT-11, the operating system can be relied upon to behave in a
completely reliable manner, i.e. after an EMT request, the PSW bits
for the PREVIOUS DATA mode are unchanged.
Since security is not an aspect of RT-11 (after all, the resident monitor
code and data are normally in the user space), allowing the user access
to the KERNEL via PREVIOUS DATA space doesn't seem to have
caused any concern. Likewise with the IOPAGE registers.
In addition,
if an operating system caches the blocks in a file, the
same speed is achieved.
Not really. By using a ram disk, you don't need to run through the
various layers of the operating system to deal with the system call
and the device handling, even if that ends up just accessing a disk cache.
Doesn't seem to make a measurable difference in E11. The time to
copy 65536 blocks of a RAM: disk is the same as the time to copy
a 65536 block disk in cache memory. The first time takes a bit longer,
but after those 32 MB are in cache, the time is the same. NOTE that
this is under RT-11 under E11 under W98SE on a Pentium III with
768 MB of physical memory.
The copy time for an MSCP device of 32 MB is just over 2 seconds.
The copy time for E11's HD: device is about 1 second using a device
driver and about 1/2 second if the subroutines are in user space - the
overhead of an EMT request is not needed.
It is just a
bit more complicated since the memory address can be
anywhere in the 4 MB of emulated PDP-11 memory. So 22 bit address is
required > - which can be determined during initialization. The even
better aspect is that the code (only about a dozen instructions which
set up the 6 IOPAGE registers) can be in user space which avoids the
overhead of a system call.
Why limit yourself to 4 MB?
If you have a device that gives you the storage, you can basically let
if be of any size you want to.
I was referring to the 4 MB of "emulated PDP-11 memory", not the
disk storage. Since the 4 MB requires a 22 bit address, 2 IOPAGE
registers must be set - in addition to the disk storage block number
which can be 32 bits (don't have that much storage quite yet, but soon),
the number of bytes in the I/O "transfer", the transfer direction (read or
write) and the physical unit number of the device.
Sincerely yours,
Jerome Fine
--
If you attempted to send a reply and the original e-mail
address has been discontinued due a high volume of junk
e-mail, then the semi-permanent e-mail address can be
obtained by replacing the four characters preceding the
'at' with the four digits of the current year.