VMS
Maxim S. Shatskih
(sorry for noting lots of things obvious for many - this is a crosspost to 3 NGs, where people have experience in different
areas).
What are the main architectural differences between VMS and UNIX or NT?
Any stdin/stdout notion in VMS? Pipes?
ability to run the command lines in the background as UNIX's "& at tail"?
Any /dev in VMS? Or in-memory table like \?? in NT? (note that latest NTs keep this table per-session).
/proc?
The file IO syscalls? Are the same syscalls used for _all_ kinds of IO as in UNIX?
Native filesystem support for database ISAM (not treating some kinds of files as byte stream, but as an indexed tables instead)?
MS wants to do this in NT now.
mmap()?
environment variables?
fork()?
threads?
async IO as in NT or UNIX's "aio"?
services/daemons?
division of address space to 2 parts - kernel (same for all processes) and per-process user (in fact, NT is already away a bit
from this division due to session space where the GUI server is loaded, the boundary between the GUI code and the kernel is strict,
though not enforced in hardware as kernel/user boundary)?
preemptive kernel?
pageable kernel?
overlaid EXEs as in RSX-11 or late DOS or flat EXEs as in Win32 and UNIX?
DLLs?
mandatory system DLLs which are lower then C runtime and loaded to any process? NT uses such.
binary registry or text config files?
is X11 used for GUI or some Digital's proprietary thing?
ACLs on everything as in NT?
SMP support?
kernel module unload feature as in NT or new UNIXen?
several different filesystems?
software RAID?
system support for command line parsing? It was in RT-11 (?CSI-xxx error messages for bad syntax), but not in UNIX and not in
NT, UNIX uses "getopt" GNU library instead.
I saw VMS only once per 2-3 hours while being a student, and remember directories on disk, the "ps" like command, version
numbers on files, and RSX-11 emulator. Is this emulator like NTVDM? I mean - can VAX CPU support PDP-11 compatible mode as x86
supports real
mode? Or was the PDP-11 code emulated?
What amount of RAM is needed to run VMS decently? What CPU power VAXen had? I remember the statement that the most powerful VAX
CPU was equal to ~Pentium 90. Is it so?
What are the main features (in 2 lines of text) of VMS clustering? The disk shared sectorwise with the filesystem able to run on
a shared disk? Or something more? Was this clustering for fault tolerance only (as MS's WolfPack seems to be) or for scalability
too? How the cluster looked in the hardware? Several boxes connected to the single disk via the SCSI bus or some other way?
DECNet protocol. Is it routable? Can it be run over Ethernet or it requires the Digital's special hardware at MAC/physical
layers?
--
Maxim Shatskih
StorageCraft Corporation
ma...@storagecraft.com
http://www.storagecraft.com
Bart Zorn
> Can somebody describe the VMS OS? Just interesting.
> (sorry for noting lots of things obvious for many - this is a crosspost to 3 NGs, where people have experience in different
> areas).
>
You forgot the most obvious ng: comp.os.vms. Repost your question there
and I'm sure you get (lots of) answers
Bart Zorn
Bill Todd
"Maxim S. Shatskih" <ma...@storagecraft.com> wrote in message
news:aams2b$sv7$1...@gavrilo.mtu.ru...
> Can somebody describe the VMS OS? Just interesting.
Last I knew, the full VMS doc set (or at least a great deal of it) was on
line. Check http://www.openvms.compaq.com
> (sorry for noting lots of things obvious for many - this is a
crosspost to 3 NGs, where people have experience in different
> areas).
But none of them are comp.os.vms...
>
> What are the main architectural differences between VMS and UNIX or
NT?
VMS has an architecture, a design, and an implementation that are actually
consistent with each other :)
> Any stdin/stdout notion in VMS?
Nope, though equivalent facilities exist (and are used by the C run-time
system to support stdin/out).
Pipes?
Might well have been added (most of my experience dates back about 15
years). The native 'mailbox' facility is at least somewhat similar.
> ability to run the command lines in the background as UNIX's "& at
tail"?
Full batch-style mechanisms, but whether you can just prefix an
interactively-entered command that way I don't know.
> Any /dev in VMS? Or in-memory table like \?? in NT? (note that latest
NTs keep this table per-session).
> /proc?
VMS doesn't maintain such information in pseudo-file entities: you need to
use system calls or utility programs to access it.
> The file IO syscalls? Are the same syscalls used for _all_ kinds of IO
as in UNIX?
No, though the system low-level 'QIO' interface is in fact quite similar for
similar operations across a wide variety of devices, and the Record
Management Services (RMS) interface also makes varied devices seem to work
(just about) the same. In general, VMS facilities are both richer and more
complex than Unix's: it would be interesting to see whether the richness
could be preserved but the complexity (at least in typical use) be
decreased.
> Native filesystem support for database ISAM (not treating some kinds
of files as byte stream, but as an indexed tables instead)?
Yes. Multi-key. With journaling (effectively, user-level transactions).
Though it's just a record manager, not a full database: if you want to run
things like SQL against it, you need to add (in the SQL layer) things like
joins, views, etc.
> MS wants to do this in NT now.
My impression was that they wanted to make SQL Server the 'file system'.
Bad idea.
> mmap()?
An equivalent.
> environment variables?
Hmmm. The comprehensive VMS 'logical name' facility probably encompasses
this.
> fork()?
No, but it's reportedly being added for COE support.
> threads?
Yes.
> async IO as in NT or UNIX's "aio"?
Yes: where do you think NT and Unix got it from?
> services/daemons?
Yes, but uses better mechanisms where possible.
> division of address space to 2 parts - kernel (same for all processes)
and per-process user (in fact, NT is already away a bit
> from this division due to session space where the GUI server is loaded,
the boundary between the GUI code and the kernel is strict,
> though not enforced in hardware as kernel/user boundary)?
> preemptive kernel?
> pageable kernel?
Yes, yes, yes - again, where do you think NT got such things?
> overlaid EXEs as in RSX-11 or late DOS or flat EXEs as in Win32 and
UNIX?
Yes (both), though virtually everything uses flat .EXEs.
> DLLs?
Yes.
> mandatory system DLLs which are lower then C runtime and loaded to any
process? NT uses such.
Not familiar with them.
> binary registry or text config files?
Most system data is binary.
> is X11 used for GUI or some Digital's proprietary thing?
X11, regrettably (DECwindows I think is no more). Though, as with Unix,
command-line processing remains typical.
> ACLs on everything as in NT?
Certainly on files, but VMS long predates the idea of using them on all
system objects (and I can't remember what alternatives it uses).
> SMP support?
And NUMA as well (since the Alpha GS series are NUMA).
> kernel module unload feature as in NT or new UNIXen?
Possibly (don't know), but probably less need for it.
> several different filesystems?
Potentially, but (again) little call for them.
> software RAID?
Yes, including mirroring on a distant server.
> system support for command line parsing? It was in RT-11 (?CSI-xxx
error messages for bad syntax), but not in UNIX and not in
> NT, UNIX uses "getopt" GNU library instead.
Standard Digital Command Language (DCL) interpreter support.
>
> I saw VMS only once per 2-3 hours while being a student, and remember
directories on disk, the "ps" like command, version
> numbers on files, and RSX-11 emulator. Is this emulator like NTVDM? I
mean - can VAX CPU support PDP-11 compatible mode as x86
> supports real
> mode? Or was the PDP-11 code emulated?
Both. Originally via hardware that executed the PDP-11 instruction set,
later (as demand for it decreased) in software.
>
> What amount of RAM is needed to run VMS decently?
Far less than NT. The minimum VMS V1.0 configuration was 256 KB (and IIRC
60 MB of disk), but that was *very* tight. I'm pretty sure that today's VMS
would run decently (on a desktop, of course, not a mega-server) with as
little as 32 MB of RAM, and quite possibly as little as 16 MB. Then again,
it doesn't have to run MS Office...
What CPU power VAXen had? I remember the statement that the most powerful
VAX
> CPU was equal to ~Pentium 90. Is it so?
Could be: the last big VAX design was in the late '80s. Of course, most
VMS systems today run on Alphas, which aren't exactly slow (and on systems
with up to 32 of them).
>
> What are the main features (in 2 lines of text) of VMS clustering?
Just about everything that any other cluster implementation can offer, plus
a good deal that they cannot: VMS has, after all, been improving its
clustering for almost 20 years now.
The disk shared sectorwise with the filesystem able to run on
> a shared disk? Or something more?
Real shared disks (and arrays). Virtual shared disks (private disks or
arrays exported as if they were directly accessible by others). Other
shared cluster resources (e.g., printers). Full distributed lock management
available to applications to coordinate their own cluster-aware activity.
Fully-distributed record management (with record-level, not page-level,
distributed locking).
Was this clustering for fault tolerance only (as MS's WolfPack seems to be)
or for scalability
> too?
Both. And since it allows real concurrent resource sharing, without the
kludgey 'fail-over chain' scripting that most current Unix clusters need to
specify who inherits a failed node's resources.
How the cluster looked in the hardware? Several boxes connected to the
single disk via the SCSI bus or some other way?
Up to a total of 96 (supported; users have successfully used hundreds) hosts
and smart storage devices (arrays) connected in a SAN (at first, DEC's
'Cluster Interconnect' - CI; later FDDI, Ethernet, Fibre Channel, Memory
Channel, and, yes, even SCSI for low-end use).
>
> DECNet protocol. Is it routable?
Yes. DECnet formed the basis for the OSI standards in many areas.
Unfortunately, IP (a noticeably inferior protocol in several ways) got
substituted for similar DECnet mechanisms fairly late in the game.
Can it be run over Ethernet or it requires the Digital's special hardware
at MAC/physical
> layers?
DECnet can run over just about anything except a string stretched between
two tin cans.
- bill
Maxim S. Shatskih
One point:
> > MS wants to do this in NT now.
>
> My impression was that they wanted to make SQL Server the 'file system'.
> Bad idea.
No. From what is described on the web, MS wants to move the _ISAM record engine + logging_ of SQL Server to the kernel, making a
filesystem with non-byte-stream files and custom attributes of it.
NTFS emulator over it is planned, MSSQLServer is planned to be a user-mode SQL layer over this ISAM, Exchange Server will use this
ISAM too.
Max
Bill Todd
> Thanks for great answer, Bill!
>
> One point:
>
> > > MS wants to do this in NT now.
> >
> > My impression was that they wanted to make SQL Server the 'file system'.
> > Bad idea.
>
> No. From what is described on the web,
I've seen almost nothing: any pointers available?
MS wants to move the _ISAM record engine + logging_ of SQL Server to the
kernel, making a
> filesystem with non-byte-stream files and custom attributes of it.
Now *that's* something I could relate to - though it's really difficult to
imagine that those ancient SQL Server innards are anywhere nearly optimal
(then again, they do more or less work...) - and, as I said elsewhere, I
suspect they're nowhere nearly as scalable as a new approach could be (thus
leaving the traditional server bottleneck in place for the next major change
to handle, rather than possibly eliminating the need for that next change).
> NTFS emulator over it is planned, MSSQLServer is planned to be a user-mode
SQL layer over this ISAM,
I've believed for close to two decades that this is the ideal way to layer a
system. Among other things, it defines a standard record-level
representation that programs can use to access shared data - even data in
databases that other programs access at that higher level (though
lower-level accessors probably shouldn't be able to update it) - while
providing a far lighter-weight access mechanism than a full-blown database
for applications that don't need the latter.
- bill
Brian Catlin
Structures" book, by Ruth Goldenberg (ISBN: 1-55558-120-X). It was originally
published by Digital Press, but that division was sold, I believe to
Butterfield. I just searched for Ruth's name on Amazon, and found the book,
although it is in limited availability; you might try Compaq's web site. It is
the gold standard on how to document the internals of an operating system. It
is 1672 pages, including a 150 page index.
-Brian
"Maxim S. Shatskih" <ma...@storagecraft.com> wrote in message
news:aams2b$sv7$1...@gavrilo.mtu.ru...
> Can somebody describe the VMS OS? Just interesting.
> (sorry for noting lots of things obvious for many - this is a crosspost to
3 NGs, where people have experience in different
> areas).
>
> What are the main architectural differences between VMS and UNIX or NT?
VMS and NT are *very* similar - at least up to Win2K. I haven't used VMS since
the mid 90's, but when I did, I was a driver/internals consultant.
> Any stdin/stdout notion in VMS? Pipes?
Yes, and sort of
> ability to run the command lines in the background as UNIX's "& at tail"?
Yes.
> Any /dev in VMS? Or in-memory table like \?? in NT? (note that latest NTs
keep this table per-session).
> /proc?
Not exactly
> The file IO syscalls? Are the same syscalls used for _all_ kinds of IO as
in UNIX?
Sort of. All I/O requests are generated by calling SYS$QIO[W] (the 'W' version
means 'wait', e.g. synchronous I/O)
> Native filesystem support for database ISAM (not treating some kinds of
files as byte stream, but as an indexed tables instead)?
Not as part of the filesystem, but as an executive service called Record
Management Services (RMS)
> MS wants to do this in NT now.
> mmap()?
Not sure what this is
> environment variables?
VMS has logical names, which are light years beyond environment variables
> fork()?
Yes
> threads?
Yes.
> async IO as in NT or UNIX's "aio"?
Yes, see SYS$QIO above
> services/daemons?
Yes.
> division of address space to 2 parts - kernel (same for all processes) and
per-process user (in fact, NT is already away a bit
> from this division due to session space where the GUI server is loaded, the
boundary between the GUI code and the kernel is strict,
> though not enforced in hardware as kernel/user boundary)?
Yes. Actually into 4 parts, although only 3 are really used (P0, P1, S0)
> preemptive kernel?
Yes.
> pageable kernel?
Yes.
> overlaid EXEs as in RSX-11 or late DOS or flat EXEs as in Win32 and UNIX?
I don't know if it is still supported - its not very useful
> DLLs?
Yes, called Shareable Images
> mandatory system DLLs which are lower then C runtime and loaded to any
process? NT uses such.
I don't remember
> binary registry or text config files?
The last version I use, 5.5, didn't
> is X11 used for GUI or some Digital's proprietary thing?
DECwindows (I don't know what Compaq calls it) sat on top of X11
> ACLs on everything as in NT?
VMS didn't have an object manager. ACLs could certainly be placed on files. I
don't remember if it could be done on devices
> SMP support?
Yes.
> kernel module unload feature as in NT or new UNIXen?
They invented it
> several different filesystems?
When I was using it, they really only had one, called Files-11. That may be
different now
> software RAID?
Yes.
> system support for command line parsing? It was in RT-11 (?CSI-xxx error
messages for bad syntax), but not in UNIX and not in
> NT, UNIX uses "getopt" GNU library instead.
Yes. Very powerful
> I saw VMS only once per 2-3 hours while being a student, and remember
directories on disk, the "ps" like command, version
> numbers on files, and RSX-11 emulator. Is this emulator like NTVDM? I mean -
can VAX CPU support PDP-11 compatible mode as x86
> supports real
> mode? Or was the PDP-11 code emulated?
No, it was done in hardware, and isn't supported anymore
> What amount of RAM is needed to run VMS decently? What CPU power VAXen
had? I remember the statement that the most powerful VAX
> CPU was equal to ~Pentium 90. Is it so?
How much memory it requires depends upon what you're doing, and what type of VAX
you have. The first VAX I used in 1982 ran in 0.25MB. It was a 1 MIP system,
had 8MB of memory, supported probably 20 users, and cost $250,000. The last VAX
built (the 8800 I think) was an enterprise class system, and would support well
over 100 users.
> What are the main features (in 2 lines of text) of VMS clustering?
They *invented* clustering. Multiple systems could not only share disks, but
could boot from the same disk.
> The disk shared sectorwise with the filesystem able to run on
> a shared disk? Or something more?
All VMS disks are block servers. There is a distributed lock manager that is
used by the filesystem to maintain record/file locks
> Was this clustering for fault tolerance only (as MS's WolfPack seems to be) or
for scalability
> too?
Both.
> How the cluster looked in the hardware? Several boxes connected to the single
disk via the SCSI bus or some other way?
Just about everything in VMS is orthogonal. Disks could be shared to the
cluster via *any* supported high-speed network or disk controller.
>
> DECNet protocol. Is it routable? Can it be run over Ethernet or it
requires the Digital's special hardware at MAC/physical
> layers?
DECnet phase 5 was the first true implementation of OSI. I'm not sure what they
use these days. A historical note: In the mid- to late-80's, Digital had the
largest network in the world, comprised of something like 40,000 or 50,000 VAXen
all running DECnet phase 4.
w m r
>
SYS$ERROR. They also have SYS$COMMAND which is supposed to point to
the top-level input device.
Pipes are called mailboxes, but they are record-oriented (and the
kernel will actually tell you what pid wrote the message you are
reading!) I think newer VMS's have stream mailboxes.
> ability to run the command lines in the background as UNIX's "& at tail"?
Yes, there is a SPAWN/NOWAIT command for doing that. But the
shell/app are different in the respect that it works like a 'virtual
machine' model. The shell and app run in the same address space. The
shell runs as ring 2 code and the app runs as ring 3. You can also
create a process that is just ring 3 with no shell included.
> Any /dev in VMS? Or in-memory table like \??
It's an in-memory table, the SHOW DEVICE command will list it out.
> /proc?
There are system services to retrieve just about anything about any
process.
> The file IO syscalls? Are the same syscalls used for _all_ kinds of IO as
in UNIX?
All I/O funneled through a system call, SYS$QIO (queue I/O). Most
drivers support standard Read/Write requests, and many have their own
unique functions.
> Native filesystem support for database ISAM (not treating some kinds of
Yes, each process has ring 1 code (called RMS) that converts record
(indexed or stream, etc) calls to block-i/o calls for SYS$QIO.
> mmap()?
> environment variables?
> fork()?
> threads?
> async IO as in NT or UNIX's "aio"?
> services/daemons?
Of course all of those, VMS is very sophisticated. VMS native I/O is
all asynchronous, it's been that way since RSX (for PDP-11's) early
70's. Original VMS didn't have threads (it's a relatively new
addition), so multi-threaded stuff was done as chains of async I/O
calls (they are sort of a user-level implementation of interrupts).
> division of address space to 2 parts - kernel (same for all processes)
Yes, the VAX hardware even forces this.
> from this division due to session space where the GUI server is loaded, the
GUI is not part of kernel and you don't even need it to run VMS (I
know that's hard for a Windoze person to understand). I don't have it
on mine, I just use telnet screens.
> preemptive kernel?
> pageable kernel?
> DLL's?
Of course, these systems run large corp datacenters, Citicorp and
Goldman Sachs come to mind off the top of my head.
> overlaid EXEs as in RSX-11 or late DOS or flat EXEs as in Win32 and UNIX?
No need for overlays in 32-bit virt memory. But if you do need more
than 32 bits, use an Alpha VMS system.
> mandatory system DLLs
Not sure what you mean. VMS kernel is composed of several 'DLLs'
which get selectively loaded at boot time
> binary registry or text config files?
There is a system config utility, but there isn't one huge database
that every app uses to store stuff in.
> is X11 used for GUI or some Digital's proprietary thing?
They took X and made decwindows out of it. I don't know a lot about
it but I think it is more-or-less compatible with X and Motif.
> ACLs on everything as in NT?
I don't know if they are on everything, but most stuff.
> SMP support?
> kernel module unload feature as in NT or new UNIXen?
yes, yes, of course.
> several different filesystems?
I think there is only one (maybe 2) supported filesystems. Command
line utilities make assumptions about filespec format.
> software RAID?
yes
> system support for command line parsing?
yes, there is even a command line syntax description 'compiler'
> Is this emulator like NTVDM? I mean - can VAX CPU support PDP-11 compatible mode as x86
early VAXes supported PDP-11 in hardware, I don't think any of the
late ones do and Alpha's dont. For the PDP-11 mode, IIRC, there was a
DLL that loaded and provided the RSX-like system calls for the PDP-11
image.
> What amount of RAM is needed to run VMS decently?
Original Vax's had < 1MB. I had a VAX with 3MB in it and it was ok.
My latest VAX (retired) had 24MB. My current Alpha has 128MB but my
older one had 32MB.
> What CPU power VAXen had? I remember the statement that the most powerful VAX
> CPU was equal to ~Pentium 90. Is it so?
Original VAX was 1MPS. I don't know what the latest VAX had. I think
there is a 1GHZ alpha now, think it's a safe bet it runs faster than
Pentium 90.
> What are the main features (in 2 lines of text) of VMS clustering?
Shared filesystems, fault tolerance, load balancing. You can put more
than one cpu on same disk bus (proprietary or scsi). Locking done as
separate protocol on bus or ethernet. (sorry that's 3)
> DECNet protocol. Is it routable? Can it be run over Ethernet or it requires the Digital's special hardware at MAC/physical
> layers?
Decnet ran on almost any physical layer you can think of, including
standard ethernet. It spanned the globe. It was the world's largest
network before the internet grew. Yes, it is routable, ie, it can
pass packets from A through B,C,D,E to get to F. I remember someone
showing me a 'telnet' to some computer in Switzerland from here in
Boston (early 80's) it was amazing at the time.
Mike
eg
The other thing to note, is that when I was managing Vax Systems back in
the early 80's, they used to distribute the OS source on microfiche. You
did have the ability to patch it yourself as well... although this
latter feature was not generally used or required.
It was a very mature and capable OS 20 years ago although I can't speak
for it today (I havent touched VMS since 1985).
E
Bart Zorn
OpenVMS is anything but a blast from the past.
It still *IS* mature and capable. OpenVMS engineering is still improving
OpenVMS every day. A lot of features which are considered normal in
OpenVMSfor 10 years or more are appearing only now in other OS's, for
instance clustering. OpenVMS is invulnerable for all known viruses and
buffer overflow exploits. You can run a webserver (e.g. Apache) on
OpenVMS and be very frustrating for hackers trying to get in.
Source listings are available on CD, although not for free (nor were the
microfiches). Have a look at http://www.openvms.compaq.com
I know this is OT, maybe anyone interested should subscribe to comp.os.vms
Bart Zorn
Bill McKenzie
single
disk via the SCSI bus or some other way?
>Just about everything in VMS is orthogonal. Disks could be shared to the
cluster via *any* supported high-speed network or disk controller.
Impressive, sounds like OS technology hasn't moved anywhere but backwards.
Well, nicer GUIs and such, and MS has moved it all to the little guys. But,
I don't see the next big leap anywhere.
--
Bill McKenzie
"Brian Catlin" <bri...@sannas.org> wrote in message
news:aanre6$19h$1...@slb0.atl.mindspring.net...
Barry Trent
<B.Z...@xs4all.nospam.nl> wrote:
> OpenVMS is invulnerable for all known viruses and
>buffer overflow exploits. You can run a webserver (e.g. Apache) on
>OpenVMS and be very frustrating for hackers trying to get in.
Invulnerable? I find that difficult to swallow. Got any facts to back
up that assertion?
If no one cares enough to target VMS that is hardly a proof of
"invulnerability". To paraphrase a tired old security axiom, "Security
by obscurity is no security at all." It probably keeps the
"script-kiddies" out, but I have a feeling that a serious hacker with
access to the source could find a way in before too long.
I'd love to be convinced, though -- who wouldn't want to run their
servers in an "invulnerable" environment!
Malcolm Weir
>eg wrote:
>> Wow... what a blast from the past.
>OpenVMS is anything but a blast from the past.
Yeah, but it doesn't exactly seem to be Compaq's favorite child, and my
guess is that HP won't love it either.
>It still *IS* mature and capable. OpenVMS engineering is still improving
>OpenVMS every day. A lot of features which are considered normal in
>OpenVMSfor 10 years or more are appearing only now in other OS's, for
>instance clustering. OpenVMS is invulnerable for all known viruses and
>buffer overflow exploits. You can run a webserver (e.g. Apache) on
>OpenVMS and be very frustrating for hackers trying to get in.
I remember a PR1MOS-based application, years ago. The prospective customer
asked the salesman whether the terminals would automatically log-off or lock
if left unattended. Salesman responded that no, they didn't, but it didn't
matter because the system was so complex that an intruder couldn't do
anything harmful.
Security through obscurity is not particularly useful.
And VMS is, today, obscure. This doesn't mean it's not clever, useful, etc.,
but it is obscure.
>Bart Zorn
Malc.
Dan Lanciani
| Wow... what a blast from the past.
|
| The other thing to note, is that when I was managing Vax Systems back in
| the early 80's, they used to distribute the OS source on microfiche. You
| did have the ability to patch it yourself as well... although this
| latter feature was not generally used or required.
And for those really special customizations you could even patch the vax's
microcode. :)
Dan Lanciani
ddl@danlan.*com
Bill Todd
"Malcolm Weir" <ma...@gelt.org> wrote in message
news:FFEE450916CCA821.8093F5CD...@lp.airnews.net...
...
> Security through obscurity is not particularly useful.
Perhaps true, but of no relevance to the post your responded to, because
obscurity is not the reason VMS is secure.
- bill
Bart Zorn
Of course you are right, I don't have proof that OpenVMS is
invulnerable. OTH, since CERT started its work, OpenVMS has had
something like 30 security issues. Several of them came from OpenVMS
Engineering. All of them were promptly solved. I don't have numbers for
Un*x or Weendoze, but they were an order of magnitude larger.
The architecture of both OpenVMS and VAX and Alpha makes it impossible
to exploit the usual techniques for hacking Unix or Windows. Other ways
may exist, but I haven't heard of them.
You may call this "Security by obscurity" but it isn't. If you are used
to Unix shells, then DCL, the command language of OpenVMS, is just as
obscure as the english language.
The serious hacker with access to sources still didn't find his way in.
Most likely because he/she has the sources!
There is a hobbyist license for OpenVMS available. Hardware can be had
for reasonable prices, for instance at eBay. Try it!
Bart Zorn
Thien-Thi Nguyen
> And VMS is, today, obscure. This doesn't mean it's not clever,
> useful, etc., but it is obscure.
given how much info is on the net, obscurity is a matter of not
looking more than anything. vms is secure because its designers
hung out a lot w/ hardware engineers who know how to handle
dont-care cases simply because in good hw design (no small
engineering feat / science) awareness and crafting of handlers
for these cases are required.
(that's why it's called hardware.)
that said, i remember certain baroque approaches in vms of yore
(on vaxen) that did not fare comparably wrt unix. maybe that is
different now. DCL is ok.
i notice this is cross-posted to some usloth group. to me,
separate "kernel-mode" hierarchy indicates the unpleasant
separation between those on the inside and those on the
outside. blech. yo usloth ex-decies, what vampires you've
grown into!
thi
Maxim S. Shatskih
> invulnerable. OTH, since CERT started its work, OpenVMS has had
> something like 30 security issues. Several of them came from OpenVMS
> Engineering. All of them were promptly solved. I don't have numbers for
> Un*x or Weendoze, but they were an order of magnitude larger.
Depends on in what subsystem the issue is. If we take _only the kernel_ - I don't think NT had much more then 30 issues since NT4
release.
If we will take _webservers_ and such - then yes, you're right.
> The architecture of both OpenVMS and VAX and Alpha makes it impossible
> to exploit the usual techniques for hacking Unix or Windows.
What is this architecture namely? "Execute allowed" bit in PTE?
> There is a hobbyist license for OpenVMS available. Hardware can be had
> for reasonable prices, for instance at eBay. Try it!
Great idea!
Max
Scott Neugroschl
"Bart Zorn" <B.Z...@xs4all.nospam.nl> wrote in message
news:3CD0482E...@xs4all.nospam.nl...
Didn't a variant of VMS reach the Holy Grail -- Orange Book A1 security?
Scott Neugroschl
"Dan Lanciani" <ddl@danlan.*com> wrote in message
news:106...@news1.IPSWITCHS.CMM...
Maxim S. Shatskih
What are the requirements for this?
Max
Rob Young
> On Wed, 01 May 2002 21:55:26 +0200, Bart Zorn
> <B.Z...@xs4all.nospam.nl> wrote:
>
>> OpenVMS is invulnerable for all known viruses and
>>buffer overflow exploits. You can run a webserver (e.g. Apache) on
>>OpenVMS and be very frustrating for hackers trying to get in.
>
> Invulnerable? I find that difficult to swallow. Got any facts to back
> up that assertion?
>
As Bart mentioned in his follow-up, "invulnerable" is a poor choice
of wording. I would use instead: "highly unlikely". This horse
has been beaten on several occasions and one of the better summaries
in comp.os.vms is found here:
http://groups.google.com/groups?selm=6ec1251e.0204030914.7143730f%40posting.google.com&output=gplain
From: KeithParr...@yahoo.com (Keith Parris)
Newsgroups: comp.os.vms
Subject: Relative invulnerability of VMS to buffer-overflow attacks
Date: 3 Apr 2002 09:14:30 -0800
Some here have contended that because TCP/IP Services for OpenVMS is
based on Tru64 Unix code, it is thus subject to the same level of risk
of buffer-overflow exploits as any Unix system out there.
After a bit of investigation, I've discovered that VMS on Alpha
appears to be immune to these common smash-the-stack buffer overflow
attacks.
To understand why, first one must understand how common
buffer-overflow attacks work. (A classic paper on such attacks is
"Smashing the Stack for Fun And Profit" written by a hacker who goes
by the name Aleph One. You can read it at
http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/profit.html)
A buffer-overflow exploit is done by passing an argument that is
larger than the buffer size to code which fails to check its size.
The data is all stored, resulting in overwriting some memory beyond
the end of the buffer. Hackers know that C compilers often allocate
data space for buffers on the stack, and part of the data area
overwritten on the stack includes the return address in the call
frame. The hacker writes a return address that points to his own
code, which is also included in the area overwritten on the stack.
The function then returns to his code instead of to the calling
routine. His malicious code then takes some dastardly action, like
starting the Unix shell and executing an arbitrary command.
For a buffer-overflow exploit to succeed, then, the hacker must know
the address size of the the target architecture (for the return
address), the format of the stack frame used by the architecture and
the compiler (to know where to put that return address), the
instruction set of the target architecture (so he can create his small
program), and enough about the innards of the operating system for his
program to be able to do something useful once it is executing.
Attacks most commonly target Windows, or Solaris or other common Unix
variants, and because the attack must be so specific to a platform,
these wouldn't affect VMS, because it has a different instruction set,
stack frame format, and so forth. While that dramatically reduces the
statistical probability of an attack succeeding on VMS in practice,
that alone doesn't rule out the possibility of an attack tailored
specifically for VMS on Alpha.
Here is where excellent and fortuitous engineering design comes to the
rescue. The Alpha memory management architecture provides some bits
in the Page Table Entries (PTEs) that control what type of access is
allowed to memory. For example, a read-only page can be protected by
having the Fault-On-Write bit set, and any attempt to write the page
causes a fault and results in a memory access violation error. Alpha
also has a Fault-On-Execute bit, designed to prevent an errant program
from jumping off into the weeds and trying to execute data as
instructions. On Alpha/VMS, the user stack is mapped with PTEs that
have the Fault-On-Execute bit set, so any attempt to branch into data
area on the stack results in an access violation, and the process
dies.
So Alpha VMS is immune to common stack-smashing buffer-overflow
attacks.
While any code that fails to check data lengths against buffer sizes
is arguably broken, and needs to be fixed, and Compaq has been doing
this to TCP/IP code as buffer-overflow bugs are identified, such bugs
are much less critical on Alpha VMS compared with less-protected
implementations.
---
One thing Keith neglects to mention in his excellent overview is
the almost "mandatory" use of descriptors (at the OS dev level
for sure):
http://groups.google.com/groups?selm=3C23EA72.48874137%40gce.com&output=gplain
One: VMS habitually has used descriptors to pass strings, which have sizes
passed. (Contrast windows NT and successors. Take a look at the ntifs.h and
you will find numerous input arguments which are null terminated strings,
some even which are arrays of such, terminated by a second null.These are
sitting like time bombs waiting to cause trouble, and will not readily
be removed by automated tools pulled from the public domain or internally
written that find gets() and friends. As a rule [NT] input string size is NEVER
available, and many of the APIs are security critical. VMS OTOH must be
searched long and hard to find any such cases, thanks to the insistence
on descriptors. It may have been a pain but it was pain with a payoff.
> If no one cares enough to target VMS that is hardly a proof of
> "invulnerability". To paraphrase a tired old security axiom, "Security
> by obscurity is no security at all." It probably keeps the
> "script-kiddies" out, but I have a feeling that a serious hacker with
> access to the source could find a way in before too long.
>
> I'd love to be convinced, though -- who wouldn't want to run their
> servers in an "invulnerable" environment!
"Invulnerable?" No. Much more secure and much less prone
to hacking exploits than others.
Multiple Solaris vulns reported
We don't even know where to begin
http://www.theregister.co.uk/content/4/25083.html
Damage control:
Solaris 9 to beef up OS, application security
In your shell-like
http://www.theregister.co.uk/content/53/25125.html
Come to DEFCON10 and hack at a VMS box. Maybe someone will
do better than last year. Highly unlikely.
Rob
w m r
>
> Of course you are right, I don't have proof that OpenVMS is
> invulnerable.
Not "proof" but at least one of the versions has a B security rating.
I think B3 but I don't remember for sure, the highest that it can be
without the os being designed as a classified os from the start.
Mike
Bill Todd
...
> > The architecture of both OpenVMS and VAX and Alpha makes it impossible
> > to exploit the usual techniques for hacking Unix or Windows.
>
> What is this architecture namely? "Execute allowed" bit in PTE?
That's good too, but the almost universal use of counted rather than
null-terminated strings (with, of course, accompanying range checks) makes
buffer overflow exploits virtually nonexistent.
- bill
Maxim S. Shatskih
> null-terminated strings (with, of course, accompanying range checks) makes
> buffer overflow exploits virtually nonexistent.
NT kernel does this.
Max
Maxim S. Shatskih
> available
Wrong. The vast majority of kernel functions in NT and all syscalls use UNICODE_STRING, which is counted, and I suspect VMS's
"string handle" to be a similar thing.
Now let's see where NT kernel used zero-terminated strings. All occurences, they are few.
C:\>grep -ni WSTR d:\ddk5\src\filesys\inc\ntifs.h
13120: IN PWSTR ValueName,
typedef NTSTATUS (NTAPI * PRTL_QUERY_REGISTRY_ROUTINE)(
IN PWSTR ValueName,
IN ULONG ValueType,
IN PVOID ValueData,
IN ULONG ValueLength,
IN PVOID Context,
IN PVOID EntryContext
);
- an in-kernel callback, the kernel is trusted to specify the valid zero-terminated string.
13131: PWSTR Name;
typedef struct _RTL_QUERY_REGISTRY_TABLE {
PRTL_QUERY_REGISTRY_ROUTINE QueryRoutine;
ULONG Flags;
PWSTR Name;
PVOID EntryContext;
ULONG DefaultType;
PVOID DefaultData;
ULONG DefaultLength;
- same as the above.
13181: IN PCWSTR Path,
NTSYSAPI
NTSTATUS
NTAPI
RtlQueryRegistryValues(
IN ULONG RelativeTo,
IN PCWSTR Path,
IN PRTL_QUERY_REGISTRY_TABLE QueryTable,
IN PVOID Context,
IN PVOID Environment OPTIONAL
);
- oh yes, this one is vulnerable for a malformed driver, but not for the apps
13192: IN PCWSTR Path,
13193: IN PCWSTR ValueName,
NTSYSAPI
NTSTATUS
NTAPI
RtlWriteRegistryValue(
IN ULONG RelativeTo,
IN PCWSTR Path,
IN PCWSTR ValueName,
IN ULONG ValueType,
IN PVOID ValueData,
IN ULONG ValueLength
);
- same as the above.
13204: IN PCWSTR Path,
13205: IN PCWSTR ValueName
NTSYSAPI
NTSTATUS
NTAPI
RtlDeleteRegistryValue(
IN ULONG RelativeTo,
IN PCWSTR Path,
IN PCWSTR ValueName
);
- same as the above
13215: IN PWSTR Path
NTSYSAPI
NTSTATUS
NTAPI
RtlCreateRegistryKey(
IN ULONG RelativeTo,
IN PWSTR Path
);
- same as the above
13223: IN PWSTR Path
NTSYSAPI
NTSTATUS
NTAPI
RtlCheckRegistryKey(
IN ULONG RelativeTo,
IN PWSTR Path
);
- same as the above
13331: PCWSTR SourceString
NTSYSAPI
VOID
NTAPI
RtlInitUnicodeString(
PUNICODE_STRING DestinationString,
PCWSTR SourceString
);
- again not a syscall. Anyway this function does not touch the string except for length calculation.
13341: IN PCWSTR SourceString
NTSYSAPI
BOOLEAN
NTAPI
RtlCreateUnicodeString(
OUT PUNICODE_STRING DestinationString,
IN PCWSTR SourceString
);
- again not a syscall, but well, this is exactly the function to create a string "handle" from the zero-terminated string.
13545: PCWSTR Source
NTSYSAPI
NTSTATUS
NTAPI
RtlAppendUnicodeToString (
PUNICODE_STRING Destination,
PCWSTR Source
);
- same as the above
13690: PWSTR UnicodeString,
NTSYSAPI
NTSTATUS
NTAPI
RtlMultiByteToUnicodeN(
PWSTR UnicodeString,
ULONG MaxBytesInUnicodeString,
PULONG BytesInUnicodeString,
PCHAR MultiByteString,
ULONG BytesInMultiByteString
);
- length is given as one another parameter
13711: PWSTR UnicodeString,
NTSYSAPI
NTSTATUS
NTAPI
RtlUnicodeToMultiByteSize(
PULONG BytesInMultiByteString,
PWSTR UnicodeString,
ULONG BytesInUnicodeString
);
- same as the above.
13722: PWSTR UnicodeString,
NTSYSAPI
NTSTATUS
NTAPI
RtlUnicodeToMultiByteN(
PCHAR MultiByteString,
ULONG MaxBytesInMultiByteString,
PULONG BytesInMultiByteString,
PWSTR UnicodeString,
ULONG BytesInUnicodeString
);
- same as the above.
13733: PWSTR UnicodeString,
NTSYSAPI
NTSTATUS
NTAPI
RtlUpcaseUnicodeToMultiByteN(
PCHAR MultiByteString,
ULONG MaxBytesInMultiByteString,
PULONG BytesInMultiByteString,
PWSTR UnicodeString,
ULONG BytesInUnicodeString
);
- same as the above
13741: PWSTR UnicodeString,
NTSYSAPI
NTSTATUS
NTAPI
RtlOemToUnicodeN(
PWSTR UnicodeString,
ULONG MaxBytesInUnicodeString,
PULONG BytesInUnicodeString,
PCHAR OemString,
ULONG BytesInOemString
);
- same as the above
13755: PWSTR UnicodeString,
NTSYSAPI
NTSTATUS
NTAPI
RtlUnicodeToOemN(
PCHAR OemString,
ULONG MaxBytesInOemString,
PULONG BytesInOemString,
PWSTR UnicodeString,
ULONG BytesInUnicodeString
);
- same as the above
13766: PWSTR UnicodeString,
NTSYSAPI
NTSTATUS
NTAPI
RtlUpcaseUnicodeToOemN(
PCHAR OemString,
ULONG MaxBytesInOemString,
PULONG BytesInOemString,
PWSTR UnicodeString,
ULONG BytesInUnicodeString
);
- same as the above.
So, the statement of "most NT functions does not use string handles" is just plain wrong.
Max
Malcolm Weir
<ma...@storagecraft.com> caused to appear as if it was written:
>> Didn't a variant of VMS reach the Holy Grail -- Orange Book A1 security?
Not according to the NCSC. Best VMS ever managed was B1 (above which are
B2, B3, and A1). No OS has managed A1.
This isn't surprising, really.
For something to qualify as A1, it needs to be formally proven, which
suggests that it needs to be written in parallel with the proof. Trying to
apply the proof to an extant piece of software would be... hard.
>What are the requirements for this?
See http://www.radium.ncsc.mil/tpep/process/faq.html
> Max
Malc.
Nick Roberts
wrote:
>No OS has managed A1.
This is my understanding also. Of course I suppose such an OS may have
been created, but in secret.
>For something to qualify as A1, it needs to be formally proven, which
>suggests that it needs to be written in parallel with the proof. Trying to
>apply the proof to an extant piece of software would be... hard.
;-)
KVP
When you assume a basic funtion set, with strictly separated modules,
then you can minimzie the work.
Imho, a kernel should contain:
-low level memory management (page alloc/free/remap)
-address space (aka. process) management
-thread control (sheduling)
-ipc (should be implemented as message passing; copy or remap based)
This way, you can make a proof for your kernel. You can specify it
with the exact formulas. It is simple.
The driver level has to be as simple as possible, with as little
access to the hw. as possible. (maybe by sacrificing some speed)
The app. level can be considered as a sandbox model for every
process. No external intervention possible. (this kills the
runtime debug support, but provides isolation) The only way to
do anything outside the current address space should be via
messages. (shared memory should also be forbidden)
Conclusion:
You can write an A1 system, simply by making it simple
enough, and coding everything from scratch, all by yourself.
Viktor
ps:
Currently, I have proof for most of the little code I made.
(this eliminates testing, but slows everything down to a crawl)
w m r
> You can write an A1 system, simply by making it simple
> enough, and coding everything from scratch, all by yourself.
>
> Viktor
Well, ok, maybe you could *write* it yourself.
According to the spec, 3 testers are required.
Mike
10.3 TESTING FOR DIVISION A
10.3.1 Personnel
The security testing team shall consist of at least one individual
with a bachelor's degree in Computer Science or the equivalent and at
least two individuals with masters' degrees in Computer Science or
equivalent. Team members shall be able to follow test plans prepared
by the system developer and suggest additions, shall be conversant
with the "flaw hypothesis" or equivalent security testing methodology,
shall be fluent in the TCB implementation language(s), and shall have
assembly level programming experience. Before testing begins, the team
members shall have functional knowledge of, and shall have completed
the system developer's internals course for, the system being
evaluated. At least one team member shall be familiar enough with the
system hardware to understand the maintenance diagnostic programs and
supporting hardware documentation. At least two team members shall
have previously completed a security test on another system. At least
one team member shall have demonstrated system level programming
competence on the system under test to a level of complexity
equivalent to adding a device driver to the system.
10.3.2 Testing
The team shall have "hands-on" involvement in an independent run of
the test package used by the system developer to test
security-relevant hardware and software. The team shall independently
design and implement at least twenty-five system-specific tests in an
attempt to circumvent the security mechanisms of the system. The
elapsed time devoted to testing shall be at least three months and
need not exceed six months. There shall be no fewer than fifty
hands-on hours per team member spent carrying out system
developer-defined tests and test team-defined tests.
Dan Lanciani
Yes, but it was a somewhat long and complicated process that involved sending
paper to Digital and waiting... :)
By the way, if anyone is interested in the pre-open version of the VAX/VMS
Internals and Data Structures book (5.2) and can't find it, I have a copy
that I might be persuaded to lend out. (My friends' company actually did
the PostScript output for the book; in retrospect I wish I'd acquired a
few extra copies.)
Dan Lanciani
ddl@danlan.*com
Bill McKenzie
* understatement of the year.
> Currently, I have proof for most of the little code I made.
> (this eliminates testing, but slows everything down to a crawl)
Not surprising.
If speed wasn't an issue, we would all be working on A1 level OSes.
--
Bill McKenzie
"KVP" <nosp...@freemail.hu> wrote in message
news:9f459d85.0205...@posting.google.com...
KVP
> >access to the hw. as possible. (maybe by sacrificing some speed)*
> * understatement of the year.
No, it isn't that slow. You just have to put driver code to the
user level, and make a higher priviledged process, that has
full access to the hardware, but only acts as a proxy for the
drivers. (this can be implemented mostly in hw. on an x86)
> > Currently, I have proof for most of the little code I made.
> > (this eliminates testing, but slows everything down to a crawl)
> Not surprising.
> If speed wasn't an issue, we would all be working on A1 level OSes.
For me, speed is an issue, this is why I have been using some of the
techniques of the L4Ka system. My other design goals was full (kernel
level) network transparentcy, and full isolation for all address
spaces. The system is fast, but there are some security proxies in
it, for example:
-resource manager (memory, process and ipc control)
-task manager (sheduling, thread control)
-motherboard manager (i/o proxy, hw. p&p manager)
-security manager (called by all servers above, acts as a database)
-etc...
It isn't as fast as a runtime executive, but much safer than anything
publicly available os... In fact, you can log all syscalls, with a simple
syscall proxy. (currently it dumps everything on the kernel log, which
just goes out to the console)
Viktor
ps:
The security modell slows down device driver development, because
drivers are:
-priviledged processes (like in nt, but with their own address space)
-user mode processes with hw. access (microkernels)
-user mode processes with hw. proxy access (i/o goes through IPC)
The last one can be used to run drivers on remote machines... or to
combine multiple different machines into one system.