On the Spread of the Capability Approach

[Bill Tulloh]

Ever since reading a draft of the "Capability Myths Demolished" paper,
I became interested in how these ideas have evolved and have been
gathering information from time to time on the various systems and
people involved. My interest is more from the sociology of the spread
of ideas and technologies than just the evolution of system
architecture, but given the questions that Jed has been raising lately
on this list it seems like a good time to share some of what I've
found.

My intent has been to try to pull this information together and write
it up for the erights website or something when time allowed, but
since I haven't found that time yet I'll give an outline here. I want
to be clear that this is preliminary and therefore incomplete and
likely to contain inaccuracies. I should also note that I have no
personal knowledge of these people and systems unlike some on the
list. I mostly have gathered this information from various published
sources I have found on the web or printed on dead trees.

Early capability systems and the year the project started (as best I can tell).

1966: Dennis & Van Horn paper - MIT
1967: PDP-1 Supervisor - MIT
1967: Magic Number Machine - University of Chicago
1968: CAL-TSS - Berkeley
1969: System 250 - Plessey Corporation
1970: CAP - Cambridge University
1971: Project SUE - University of Toronto
1971: Hydra - Carnegie Mellon
1972: RATS - Lawrence Livermore
1973: Actors - MIT
1973: PSOS - SRI
1975: StarOS - Carnegie Mellon
1975: GNOSIS/KeyKOS - Tymshare
1976: Monads - Monash University
1978: System/38 - IBM
1978: NLTSS - Lawrence Livermore
1980: SWARD - IBM
1980: PDP 11 operating system - University of Texas
1981: Amoeba - Free University Amsterdam
1982: iAPX 432 - Intel
1982: Password-Capability System - Monash University

If we date the origins of capabilities from the Dennis and Van Horn
work, ignoring related earlier work by Burroughs and Iliffe, then it
raises the interesting question that Jed has been asking, namely how
does this relate to the Multics design that was occurring at the same
place and roughly the same time. The mystery being why Multics emerged
as an ACL system and not a capability system. Unfortunately, I don't
have much to contribute to this question.

The first direct follow-on work to the DVH paper seems to be the PDP-1
Supervisor talked about in the Ackerman and Plummer paper, and the
design for the Chicago Magic Number machine at the University of
Chicago. There is not much published information on the Chicago system
that I know of except in the Levy book. Robert Fabry is the key
person. He had been at MIT where he may have had direct exposure to
these ideas, although the capability work was done at University of
Chicago while he was getting his PhD under Victor Yngve a
computational linguist and early machine translation proponent, who
had also been at MIT until 1965. This system was never built and the
only descriptions are in some working papers from the Institute for
Computer Research at the University of Chicago, which are often cited
but which I haven't found. The system did get written up by Maurice
Wilkes in his book on Time-Sharing Computer Systems published in 1968.

In fact if there was a "Mr. Capability" in these early days it would
seem to be Fabry. Wilkes met Yngve at a conference in 1967 which got
him interested in capabilities. He then went to visit with Fabry at
Chicago several times. Wilkes became enthusiastic and convinced
Plessey Corporation, where he was a consultant, to implement the Fabry
design in their new system. He also convinced Roger Needham to make
capabilities the new focus of their research at Cambridge leading to
the CAP project.

After getting his PhD, Fabry became a professor at Berkeley where he
became part of the active capability research that was occurring
there. It does not appear that he was directly involved in the CAL-TSS
system started by Lampson and continued by Sturgis but he had a lot of
indirect influence not least of which by serving as Dave Redell's
thesis supervisor, the thesis which presented the caretaker pattern
for revocation.

Another early system that Fabry influenced was the PSOS system
developed by Peter Neumann at SRI -- Fabry is thanked by Neumann for
his consultation on the early design of the system. Peter Neumann had
previously been involved in the Multics design at MIT.

I'm not sure how Lampson became interested in capabilities but he was
also an early adopter. He started the CAL-TSS project and was one of
the key designers. His involvement didn't last too long however
because he left to form the Berkeley Computer Corporation, later to
join Xerox PARC when BCC failed. I'm not sure if BCC's system was
capability-based or not. Howard Sturgis was the other key designer of
CAL TSS and wrote his dissertation on the experience. Others invovled
included Jim Gray, Dave Redell, Bruce Lindsay, Paul McJones, Vance
Vaughn, and Charles Simonyi. Paul McJones has an archive of most of
the CAL-TSS documentation and source code online.

Project SUE was a capability-based operating system project at the
University of Toronto, which involved James Horning and Dennis
Tsichritzis among others. I don't know too much about this project but
it seems to have kicked off in 1971.

The Hydra project at Carnegie Mellon was a very influential project
that started around the same time under the leadership of William
Wulf. Others involved included Anita Jones, Ellis Cohen, Roy Levin,
Bill Corwin and Fred Pollack. One could argue that this was the first
true object capability system. Their work influenced a number of
subsequent projects including KeyKOS, StarOS, IBM System/38, and the
Intel 432, not to mention the whole take-grant approach to modeling
capabilities.

Charlie and Jed can do a better job of explaining the RATS, DCCS, and
NLTSS work done at Lawrence Livermore than I can.

The Actors work of Hewitt is a bit of an outlier in that it is a
programming language and not an operating system, but it was
influenced by the capabilities work and recognized the granovetter
property. I'm not sure the direct source of influence but Henry Baker
was apparently part of Dennis' Computational Structure Group at MIT.

My apologies to the Australian's on the list because I haven't sorted
through the rich capabilities tradition that emerged from there. J.
Leslie Keedy's work on the Monads project begun in 1976 seems to have
been a major source. This continued in numerous projects in Australia
and elsewhere such as the Password-Capability system of Anderson, Pose
and Wallace, the Mungi system, Opal, and SpeedOS.

The Amoeba Distributed Operating System was another (albeit different)
password capability system that seems to have gotten started around
1981. Andrew Tannenbaum is the main player.

IBM may also have been an early adopter of capability design with
their FS (Future System) design that was supposed to replace the 360
system. This project began in 1971 and was cancelled in 1975 because
it was seen as too complex and the 360 had already become a standard
that could not be easily abandoned. Emerson Pugh in his book, Building
IBM, refers to the FS design as an object-oriented system and notes
that the System 38 incorporated many of its advanced features. The
Sward project occurred later and built on the System 38 design.

There are some other systems that came later than 1982 such as
Rashid's Mach kernel that are capability based but this seems like a
good place to stop.

If I were to give a high-level overview of the history of capabilities
it would go something like this:

1966: capability design first articulated, at roughly the same time
the ACL paradigm emerged in Multics. Numerous capability-based system
design projects were started; much progress made in working out the
kinks.

1976: represents something of a high water mark for capabilities:
where capabilities were, if not necessarily the dominant design, at
least a widely proposed one. See for example the articles by Peter
Denning on "Fault Tolerant Computing" and by Theodore Linden on
"Operating System Structures to Support Security and Reliable
Software" that appeared in the same issue of Computing Surveys that
year.

1986: represents something of a low water mark for capabilities. By
this time much of the work on capability had stopped or as in the case
of KeyKOS was struggling for survival. One can look at the articles
published in Operating Systems Review as one example where as late as
the October  1985 issue there were several articles on capabilities,
including one on KeyKOS. However after that issue, one is hard-pressed
to find such articles.

1996: one starts to see a renewed interest in capability ideas. In
addition to the work evolving from KeyKOS (EROS and E). There is
Jonathan Ree's thesis on W7, the work at Cornel on J-Kernel, and work
on capabilities at the University of Oveida in Spain. All of which
started to appear in the second half of the 1990s.

2006 -  perhaps this is the decade when real progress is finally made :-)

If I had to account for the decline in fortunes from 1976 to 1986, I
would attribute to it to three things: the success of Unix, the view
that capabilities couldn't solve the military requirements for
multi-level security, and the rise of the PC. The first two are both
direct legacies of the Multics path. Unix, of course, was a direct
descendant of Multics. What may be less well known is that it was
Robert Fabry who was responsible for bringing it to Berkeley leading
to BSD Unix. This marked an end of the capability research at
Berkeley. One suspects the adoption had more to do with the unique
open source licensing and flexibility that Unix offered rather than
Unix's security properties.

Multics also had a major influence on the DOD approach to security.
Roger Schell, an air force Major at the time, got his Ph.D. at MIT
working on the Multics project. He was influential in defining the
resource monitor/security kernel view of security that appeared in the
Ware report. His group at the Air Force was later instrumental in
implementing those ideas, all with a heavy Multics flavor. He led the
tiger team that successfully attacked Multics, directed the Bell and
La Padula work at Mitre, and supported the efforts to build a secure
kernel for Multics. Besides Schell there is Boebert who was head of
the Multics project at Honeywell. All of this fed into a Multics
influenced view of trusted systems enshrined in the Orange Book. This
thread remained sceptical/hostile to the capabilities approach.

Probably the most important factor however was the rise of the
personal computer around this time. PC's, like the early batch
processing systems, were too resource constrained and disconnected to
pose much of a security issue. Their rapid adoption also put the nail
in the coffin of the time-sharing industry, depriving us of KeyKOS. It
wasn't until the issues that KeyKOS was designed to solve started
reemerging in wake of the web explosion that people started becoming
interested in capability approaches again.

Well that is more than enough for now. Perhaps it would be worthwhile
to create a wiki or blog where I can post more of this information and
others can contribute.

Bill
_______________________________________________
cap-talk mailing list
cap-talk@...
http://www.eros-os.org/mailman/listinfo/cap-talk

[Nigel Williams-2]

"Bill Tulloh" <btulloh@...> wrote in
message news:9d64e32d0608012314r2dfbb44bnd15d1034fa684eeb@......
> 1982: iAPX 432 - Intel

Your project is timely for me. I have been recently dredging the internet
for information about the iAPX 432 and have corresponded with the
defacto-custodian Eric Smith
(http://www.brouhaha.com/~eric/retrocomputing/intel/iapx432/) regarding
documentation. My curiosity was focused around why the team included
capabilities in the design and whether any of those involved continued their
advocacy of the capability model.

> Perhaps it would be worthwhile
> to create a wiki or blog where I can post more of this information and
> others can contribute.
>
> Bill

I was intending to place my findings somewhere in here:

http://en.wikipedia.org/wiki/Capability-based_security
http://en.wikipedia.org/wiki/Intel_iAPX_432

nigwil



_______________________________________________
cap-talk mailing list
cap-talk@...
http://www.eros-os.org/mailman/listinfo/cap-talk

[Jed at Webstart]

At 11:14 PM 8/1/2006, Bill Tulloh wrote:

<a delightful summary of early capability development.  I'm doing some
work on the sides to help fill in parts that I have some knowledge of.
I just include a few notes here>

>...
>In fact if there was a "Mr. Capability" in these early days it would
>seem to be Fabry.

I was always a bit puzzled by Fabry's position on capabilities.
As you say he seemed to be an early adopter, but then had little
involvement in later capability developments.  I would be very
interested to hear his thoughts on capabilities generally
and approaches to POLA.

>I'm not sure how Lampson became interested in capabilities but he was
>also an early adopter. He started the CAL-TSS project and was one of
>the key designers.

And of course there is his famous negative comment about
capability based systems, "Capability based systems are the
way of the future—and they always will be."

I've always taken the above comment as something of sour
grapes.  He couldn't make a capability system work (Cal TSS),
and so became negative on then - somewhat deriding the efforts
of others.  I'd be interested to hear Lampson's current position
regarding POLA, ambient authority, etc.  Because of Lampson's
influence, I think his move away from capabilities and his negative
comments influenced the field significantly.  In some ways I'd
say it validated the sorts of ambient authority approaches that
one sees in Unix and Windows.

About Cal TSS Lampson says:

"Cal TSS (1968-71): This was the first working
capability based operating system, and for many
years the only one done for a large computer [7,
15]. With Howard Sturgis and others I did the
design, though I did not write any code. Many of
the ideas in the Hydra system for C.mmp and its
descendants are identical to those in Cal, though
usually derived independently several years
later. This system ran successfully at Berkeley
for about a year, and then was abandoned for a
combination of technical and political reasons."

which is of course untrue as the PDP-1 supervisor
clearly preceded it.  He might have been doing
some filtering by size - considering the PDP-1
system as insignificant - but I really don't think the
Cal TSS system got enough users to put in into another category.

>His involvement didn't last too long however
>because he left to form the Berkeley Computer Corporation, later to
>join Xerox PARC when BCC failed. I'm not sure if BCC's system was
>capability-based or not.

It was not.  The whole idea of BCC was to have a micro programmed
computer that could emulate other computer systems.  Then it would
sell time on any type of system for any organization that needed additional
capacity.  Very ambitious, doomed to failure.  Particularly when they wouldn't
accept defense money on principal.  I worked for some time for Bob Abbott
who worked at BCC and I often heard discussions about what happened
there.  I've been in contact with Bob Abbott (Charlie Landau also worked
for him) recently, though I don't think Bob has
much of a role in capabilities -
except supporting Charlie's work on RATS and perhaps providing a great
environment for me to flourish in the computer area and to go on to work
on NLTSS and LINCS.

BCC was agnostic about operating systems. It would run the OS that
came with the system on its micro programmed emulation of the hardware.

The only emulations that were completed were one for the SDS 940 and a
native one - that ran at the University of Hawaii for some years.  One
interesting aspect of that system is that, at least after it got to Hawaii,
they were never able to rebuild the system from source.  They always
had to patch it to make changes.  Mel Pirtle was also a principle in
BCC and then went on to be a major player in the Illiac IV development.

>Howard Sturgis was the other key designer of
>CAL TSS and wrote his dissertation on the experience. Others invovled
>included Jim Gray, Dave Redell, Bruce Lindsay, Paul McJones, Vance
>Vaughn, and Charles Simonyi. Paul McJones has an archive of most of
>the CAL-TSS documentation and source code online.

I guess you mean this PDF file:

http://www.mcjones.org/CalTSS/CalTSS.pdf

with embedded links to Cal TSS documentation.  Hot stuff!  I'll try to find
some time to take a look through there as I'm quite interested to learn more
about that system.

Sigh.  I guess I should scan and post more of the NLTSS documentation.

>The Hydra project at Carnegie Mellon was a very influential project
>that started around the same time under the leadership of William
>Wulf. Others involved included Anita Jones, Ellis Cohen, Roy Levin,
>Bill Corwin and Fred Pollack. One could argue that this was the first
>true object capability system. Their work influenced a number of
>subsequent projects including KeyKOS, StarOS, IBM System/38, and the
>Intel 432, not to mention the whole take-grant approach to modeling
>capabilities.

With all these projects going on at about the same time, one wonders
what could have happened regarding collaboration if the communication
infrastructure of the time was richer.  I read quite a bit about Hydra in
those days.  I also happened to room with Roy Levin at an ARPA grad
students conference in Asilomar - perhaps in 1975?  I've had recent
contact with Roy who worked for Digital Research and now for Microsoft
Research.  Of course Hydra was a multiprocessor effort to a large extent.
I don't really remember enough about the capability architecture of Hydra
to comment.

>Charlie and Jed can do a better job of explaining the RATS, DCCS, and
>NLTSS work done at Lawrence Livermore than I can.

At a high level RATS was a port of the PDP-1 supervisor with some
improvements.  I was technical liaison for the LLL ARPA Network site
in those days and was involved to some extent in protocol design, e.g.
early Telnet and FTP.  I got excited by the ability to extend RATS through
the entry mechanism in juxtaposition with the ARPA network work and
one evening had a "brain storm" imaging the DCCS mechanism.  I then
fleshed out the details and wrote the paper:

http://www.webstart.com/jed/papers/DCCS/

with some discussion with Charlie.  We considered implementing that
system, but it turned out that one critical resource, the file resource in
RATS could not be extended (emulated through the entry mechanism)
as has been discussed elsewhere on this list - because of the way
virtual memory was mapped in RATS as an invocation on a file rather
than on a process (remember, this is high level).  I don't know if we
would have had time/inclination to implement something like the DCCS
on RATS without that problem - likely not, as many other things were
happening at that time and we had no funding for such work.

I wrote up a summary of "Capability Computing at LLNL" here:

http://www.computer-history.info/Page4.dir/pages/LTSS.NLTSS.dir/pages/cap-livermore.html

that describes how we got to NLTSS.  There was an independent thread
that came to LLL through some early Multics papers that John Fletcher
interpreted as a capability architecture.  John
implemented the Elephant storage
system at LLL and the "Gator" operating system
using that capability architecture.

I'm going off on a bit of a tangent to get more information about that thread.

There is also a wikipedia writeup on NLTSS that I wrote:

http://en.wikipedia.org/wiki/NLTSS

That might be a good hook for some more documentation on NLTSS.
There is also a student paper that describes NLTSS:

http://www.computer-history.info/Page4.dir/pages/LTSS.NLTSS.dir/pages/NLTSS.pdf

>There are some other systems that came later than 1982 such as
>Rashid's Mach kernel that are capability based but this seems like a
>good place to stop.

I think the Mach work should be included as in some sense I see it
as the last of the OS development of that era.

Also you don't mention Demos:

http://portal.acm.org/citation.cfm?id=806544&coll=portal&dl=ACM

Since that work happened at Los Alamos (in some ways LANL's
effort to get into the OS business - compete with LTSS and NLTSS
from LLL) I probably know more about it than most.  At LLL we
even picked up their "Model" language (Pascal with some OO
additions) that we had to support for many, many years after
Los Alamos abandoned it because most of NLTSS was written
in Model (a mistake in hind sight).

Demos was yet another system that had a mechanism to block
delegation.  It was as explicit as a "do not delegate" bit in their
capability equivalent - "port"s.

>If I were to give a high-level overview of the history of capabilities
>it would go something like this:
>
>1966: capability design first articulated, at roughly the same time
>the ACL paradigm emerged in Multics. Numerous capability-based system
>design projects were started; much progress made in working out the
>kinks.
>
>1976: represents something of a high water mark for capabilities:
>where capabilities were, if not necessarily the dominant design, at
>least a widely proposed one. See for example the articles by Peter
>Denning on "Fault Tolerant Computing" and by Theodore Linden on
>"Operating System Structures to Support Security and Reliable
>Software" that appeared in the same issue of Computing Surveys that
>year.
>
>1986: represents something of a low water mark for capabilities. By
>this time much of the work on capability had stopped or as in the case
>of KeyKOS was struggling for survival. One can look at the articles
>published in Operating Systems Review as one example where as late as
>the October  1985 issue there were several articles on capabilities,
>including one on KeyKOS. However after that issue, one is hard-pressed
>to find such articles.
>
>1996: one starts to see a renewed interest in capability ideas. In
>addition to the work evolving from KeyKOS (EROS and E). There is
>Jonathan Ree's thesis on W7, the work at Cornel on J-Kernel, and work
>on capabilities at the University of Oveida in Spain. All of which
>started to appear in the second half of the 1990s.
>
>2006 -  perhaps this is the decade when real progress is finally made :-)
>
>If I had to account for the decline in fortunes from 1976 to 1986, I
>would attribute to it to three things: the success of Unix, the view
>that capabilities couldn't solve the military requirements for
>multi-level security, and the rise of the PC. The first two are both
>direct legacies of the Multics path. Unix, of course, was a direct
>descendant of Multics. What may be less well known is that it was
>Robert Fabry who was responsible for bringing it to Berkeley leading
>to BSD Unix. This marked an end of the capability research at
>Berkeley. One suspects the adoption had more to do with the unique
>open source licensing and flexibility that Unix offered rather than
>Unix's security properties.

Though I expect that, like Lampson, Fabry saw little practical appeal
in capabilities and considered them an architecture of the past.

One question one must ask is what compelling problem is there
that needs solving for which capabilities are the answer?  In my
opinion that problem (one might say a "killer ap" for capabilities)
is malware.  Mutual suspicion has been a technical issue for
many, many years (at least since the Michael Shroeder thesis),
but I don't believe it has been a serious practical problem until
the rise of the Internet/web.

One thing that struck me about the above history is that it seems in
many ways to parallel the history of the development of virtual
machine monitors.  I haven't looked into this thoroughly, but
I think virtual machine mechanisms started a bit later, in the
very late 1960s or early 1970s, peaked during the 70s with
VM370 and some PDP-11 work and perhaps other (?), and
then gradually died out.  Perhaps in a similar way the rise
of the PC and having computers more available and the lack
of a compelling requirement lead to the gradual falling to the
wayside of virtual machine technology.

Now virtual machines are at least on the rise again.

I wonder if there are other computer technologies that
had a similar rise, fall during the computer middle ages
(when money grew on trees and a monkey could program),
and then are on the rise again?

>Multics also had a major influence on the DOD approach to security.
>Roger Schell, an air force Major at the time, got his Ph.D. at MIT
>working on the Multics project. He was influential in defining the
>resource monitor/security kernel view of security that appeared in the
>Ware report. His group at the Air Force was later instrumental in
>implementing those ideas, all with a heavy Multics flavor. He led the
>tiger team that successfully attacked Multics, directed the Bell and
>La Padula work at Mitre,

Ah, that's an interesting connection for me.  As we (Charlie Landau
and I and others) were working in the RISOS (Research Into the Security
of Operating Systems) at LLNL in the early 1970s Roger Shell's name
came up a number of times.

>and supported the efforts to build a secure
>kernel for Multics. Besides Schell there is Boebert who was head of
>the Multics project at Honeywell. All of this fed into a Multics
>influenced view of trusted systems enshrined in the Orange Book. This
>thread remained sceptical/hostile to the capabilities approach.

Quite true.

>Probably the most important factor however was the rise of the
>personal computer around this time. PC's, like the early batch
>processing systems, were too resource constrained and disconnected to
>pose much of a security issue. Their rapid adoption also put the nail
>in the coffin of the time-sharing industry, depriving us of KeyKOS. It
>wasn't until the issues that KeyKOS was designed to solve started
>reemerging in wake of the web explosion that people started becoming
>interested in capability approaches again.
>
>Well that is more than enough for now. Perhaps it would be worthwhile
>to create a wiki or blog where I can post more of this information and
>others can contribute.
>
>Bill

Thanks for the review Bill.  Quite helpful.

--Jed http://www.webstart.com/jed/ 



_______________________________________________
cap-talk mailing list
cap-talk@...
http://www.eros-os.org/mailman/listinfo/cap-talk

[Karp, Alan H]

Joanna Rutkowska is the name I've seen associated with this attack,
which is frequently called Blue Pill, from the Matrix.  She has
demonstrated a running version on Vista x64 and is presenting at Black
Hat today.  According to reports, she was able to install the rootkit on
a running system, no reboot required.
http://www.eweek.com/article2/0,1895,1983037,00.asp is a news article on
the subject.

The key point is that you're both right.  You are safer if you use a
virtual machine to run Windows.  However, if your base system gets
infected, virtualizability assures that there is no mechanism by which
the OS can detect the attack.  

_________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
[phone], fax [phone]
https://ecardfile.com/id/Alan_Karp
http://www.hpl.hp.com/personal/Alan_Karp/
 

[Karp, Alan H.vcf]

---

BEGIN:VCARD
VERSION:2.1
N:Karp;Alan
FN:Karp, Alan H
ORG:Hewlett-Packard Co;Advanced Architecture
TEL;WORK;VOICE:[phone]
ADR;WORK:;PAL03:H37;1501 Page Mill Rd.;Palo Alto;California;94304-1100;United States
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:PAL03:H37=0D=0A1501 Page Mill Rd.=0D=0APalo Alto, California 94304-1100=0D=
=0AUnited States
EMAIL;PREF;INTERNET:alan.karp@...
REV:20060509T161609Z
END:VCARD

---

_______________________________________________
cap-talk mailing list
cap-talk@...
http://www.eros-os.org/mailman/listinfo/cap-talk

[David Hopwood]

Karp, Alan H wrote:

> Joanna Rutkowska is the name I've seen associated with this attack,
> which is frequently called Blue Pill, from the Matrix.  She has
> demonstrated a running version on Vista x64 and is presenting at Black
> Hat today.  According to reports, she was able to install the rootkit on
> a running system, no reboot required.
> http://www.eweek.com/article2/0,1895,1983037,00.asp is a news article on
> the subject.
>
> The key point is that you're both right.  You are safer if you use a
> virtual machine to run Windows.  However, if your base system gets
> infected, virtualizability assures that there is no mechanism by which
> the OS can detect the attack.

That's not quite accurate; most VMMs are detectable, and AFAIK all VMMs
that run on x86 hardware (VT, Pacifica or otherwise) are detectable.

It is true to say that a guest OS cannot reliably detect a VMM in a
way that is useful to prevent this kind of rootkit attack, in general.
After all, we don't want guest OSes to refuse to run under any VMM;
that would be more counterproductive than helpful. Also, such a
detection mechanism could be circumvented, if the attacker writes
his/her code after the defender (and I believe this to be more practical
than Jed does).

--
David Hopwood <david.nospam.hopwood@...>


_______________________________________________
cap-talk mailing list
cap-talk@...
http://www.eros-os.org/mailman/listinfo/cap-talk

[Karp, Alan H]

David Hopwood wrote:
>
> That's not quite accurate; most VMMs are detectable, and
> AFAIK all VMMs
> that run on x86 hardware (VT, Pacifica or otherwise) are detectable.
>
That's because x86 is not fully virtualizable.  Rutkowska is working on
architectures that are.

_________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
[phone], fax [phone]
https://ecardfile.com/id/Alan_Karp
http://www.hpl.hp.com/personal/Alan_Karp/
 

[Karp, Alan H.vcf]

---

BEGIN:VCARD
VERSION:2.1
N:Karp;Alan
FN:Karp, Alan H
ORG:Hewlett-Packard Co;Advanced Architecture
TEL;WORK;VOICE:[phone]
ADR;WORK:;PAL03:H37;1501 Page Mill Rd.;Palo Alto;California;94304-1100;United States
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:PAL03:H37=0D=0A1501 Page Mill Rd.=0D=0APalo Alto, California 94304-1100=0D=
=0AUnited States
EMAIL;PREF;INTERNET:alan.karp@...
REV:20060509T161609Z
END:VCARD

---

_______________________________________________
cap-talk mailing list
cap-talk@...
http://www.eros-os.org/mailman/listinfo/cap-talk

[Jed at Webstart]

At 09:31 AM 8/3/2006, Karp, Alan H wrote:
>Joanna Rutkowska is the name I've seen associated with this attack,
>which is frequently called Blue Pill, from the Matrix.  She has
>demonstrated a running version on Vista x64 and is presenting at Black
>Hat today.  According to reports, she was able to install the rootkit on
>a running system, no reboot required.
>http://www.eweek.com/article2/0,1895,1983037,00.asp is a news article on
>the subject.

<still going on with the VMBR discussion not focused on capabilities.
Other lists or suggestions to move or stay gratefully accepted>

I should have mentioned in my initial message that I've seen some of
the Blue Pill discussion.  I'm a bit uncomfortable with what I've seen about
it so far, e.g. (from the article you mentioned Alan):

"Blue Pill is being developed exclusively for COSEINC Research and will
not be available for download. However, Rutkowska said the company is
planning to organize trainings about Blue Pill and other technologies
where the source code would be made available."

There seems to me to be a bit too much notoriety and profit motive in
what I've seen about this work so far.  I'll take it more seriously when it
gets "out there" and generally worked over in the academic and
general open source software communities.

>The key point is that you're both right.  You are safer if you use a
>virtual machine to run Windows.

Or any other guest OS.  Certainly true.

>However, if your base system gets
>infected, virtualizability assures that there is no mechanism by which
>the OS can detect the attack.

I think the above is an overstatement.  Even if there was no way for an OS to
detect that it's running under a VMM (which there is - no VMM is completely
undetectable), there are other detection mechanisms.  For example one can
power cycle the system, come up on clean media (e.g. a CD) and run an
analysis on the hard drive(s) - e.g. as discussed in the SubVirt paper.  This
assumes that the BIOS hasn't been corrupted - which gets into another set
of issues independent of VMMs.  You seem to be referring to detection
mechanisms in the guest OS. Even in the guest OS there are possibilities
(e.g. see the King paper), but that is where the purity of the VM comes
into play.

Regarding:

At 10:11 AM 8/3/2006, David Hopwood wrote:
>It is true to say that a guest OS cannot reliably detect a VMM in a
>way that is useful to prevent this kind of rootkit attack, in general.
>After all, we don't want guest OSes to refuse to run under any VMM;
>that would be more counterproductive than helpful.

I think this is what I was agreeing to above.  However, regarding:

>Also, such a
>detection mechanism could be circumvented, if the attacker writes
>his/her code after the defender (and I believe this to be more practical
>than Jed does).

I don't recall saying anything about the above (the relative timing of
the attacker and defender writing code) and thinking about it just now
I don't have an opinion on it.  Is there something I wrote that leads you
to think my view on this differs from yours?  Are you referring to this:

Jed:
_____________
I think there are a couple of points in the paper where the authors
got a bit enamored with their technology and seemed to suggest that it
could do things that I believe are difficult to impossible.  For example,
when they were referring to efforts to detect a VMBR they said:

"...even if the target system did see something amiss, the VMBR could
tamper with the execution of the detector and force it to report incorrect
results."

While I agree this is theoretically possible, I think in practice
it's very unlikely to ever be achieved.
_______________

?  That is, a situation where the VMBR detects the execution of
rootkit detection software running in the guest OS and modifies
it's behavior in such a was as to render it ineffective in detecting
the VMBR or in reporting it's detection?   If so then when you
consider the attacker writing their code after the defender you
must certainly consider the usual case that the "defender" code
will be regularly updated to detect new attackers.  You might then
believe that this would be some sort of horse race, with the attacker
trying to keep updating the VMBR (presumably over the network -
which can of course be detected off the box, but never mind that) in
order to keep falsifying results for the defender.  I believe even this
underestimates the difficulty for the attacker.  It doesn't suffice for
the attacker to simply maintain the functioning of the virtual machine
and to reach into the guest OS's VM to modify the behavior of the
defender so as to appear invisible, it must also either:

1.  not be detectable to the defender.  This is a little like
stealth technology - where shared resources must be
used invisibly.  I don't believe it's possible.  Just for example,
the guest OS can assume it's running on the bare metal.
It can run randomized loops (e.g. with interrupts disabled)
where it should know exactly the number of cycles used and
be able to make counts of repeatable behavior.  If the
behavior changes, it detects the VMBR.

or

2.  even if the defender detects the VMBR, the VMBR will
reach into the guest OS and modify the detectors behavior
in such a way as to make it appear that the VMBR wasn't
detected and more generally no problem was detected.  I
believe this would be quite difficult to accomplish.  One thing
to keep in mind is that the detection software has the user
on it's side.  It can set up some simple user interaction
that will help assure that it is operating unhindered.
The VMBR can't, for example, simply stop the detection
software from running and output what seems to it to be
nominally reassuring output.

I generally just feel that this is a situation that favors
the defense.  I also don't think it's much impacted by
the effectiveness of the VM assist features in the hardware.
I know it's fashionable to be macho on the side of the
attacker in situations like this.  I think there is ample
opportunity for a bit of macho on the side of the defender
in this situation.

Hey, I wonder if this is one of those sorts of situations where
a concrete enough bet could be set up to be meaningful?
For example, I could bet that the majority of commodity
processors sold in the year, say, 2011, will be virtualizable.
That is, all privileged operations will trap in user mode,
as with the current Intel VT and AMD Pacifica, so VMMs
can be run for unmodified OSs.   Given the current state of
the art that seems a rather brash and, from my perspective,
hopeful position to take, but it might be fun to have a bet out
there to keep an eye on.  Anybody have any thoughts on
such a bet, e.g. how to tighten it up or whether it seems a
reasonable bet?  Certainly if virtualizability comes to be seen
as a negative feature because it makes systems more subject
to being invisibly rooted, then one would expect virtualizability
to die out or at least be compromised in some way.

Regarding:

>At 03:13 PM 8/3/2006, Karp, Alan H wrote:
>David Hopwood wrote:
> >
> > That's not quite accurate; most VMMs are detectable, and
> > AFAIK all VMMs
> > that run on x86 hardware (VT, Pacifica or otherwise) are detectable.
> >
>That's because x86 is not fully virtualizable.  Rutkowska is working on
>architectures that are.

Huh?  I thought the VT and Pacifica versions of "x86" are fully
virtualizable.  Is that not true?  My understanding is that all it
takes to be "fully virtualizable" is to have all privileged operations
trap in "user" mode.  Perhaps I misread this, but I thought
Rutkowska was working with Pacifica.  Not?

--Jed http://www.webstart.com/jed/ 

_______________________________________________
cap-talk mailing list
cap-talk@...
http://www.eros-os.org/mailman/listinfo/cap-talk

[Norman Hardy]

On Aug 2, 2006, at 7:53 PM, Jed at Webstart wrote:

> cap-talk,
>
> I realize this topic is a bit off our capability focus.  I hope
> somebody will point me
> to a more focused list if they know of one.  Given the sorts of
> topics we discuss on
> this list, this one seems generally relevant to me.
>
> I found this paper:
>
> http://www.eecs.umich.edu/~pmchen/papers/king06.pdf
>
> quite interesting reading.  It contains a description of some work  
> done
> on Virtual Machine Based Rootkits (VMBRs).
>
> Some have taken this work to suggest that the work that has recently
> gone into processor design to make virtual machine support transparent
> may backfire in some way to make rootkits like the above more  
> difficult
> to detect and therefore more prevalent.
>
> I don't agree with this position.  I would like to get a full  
> discussion
> happening lest such an understand (if indeed it is incorrect) gain
> wide acceptance and another generation of virtual machine support
> goes down the tubes.

I agree with you Jed. It is a matter of degree.
I enjoyed the paper but was annoyed that they didn't spend even a  
sentence acknowledging that this problem was once solved by operating  
systems that did not run unknown code in privileged mode.
I think there were actually such OSes at one time.
I understand the box that MS is in and how they got there.
They need a broader perspective than Windows.
What sort of security is it that depends on discovering privileged  
malware already in place and then tries to ‘recover’?
Certainly not the sort we propose on this mail list.
See more comments on paper and a brief rant at <http://cap-lore.com/ 
CapTheory/SubVirt.html>.

> Here are some comments I had on the paper:
>
> It appears that all the work (the test
> systems with VMWare and VirtualPC) were done on machines without  
> the new
> generation of virtual machine support processors:
>
> "We expect future enhancements to the x86 platform
> to reduce these perturbations. Upcoming virtualization
> support from Intel [45] and AMD [7] will enable
> more efficient virtualization."
>
> so it's clear that one doesn't need such virtualization features to  
> implement
> such Virtual Machine Based Rootkits.  Still, one could argue that  
> such features
> make their life easier.  I don't believe the authors were suggesting
> that, though
> some have suggested that in email.  I believe the authors  
> appropriately placed
> the issue in the context of an escalating battle.  They pointed out  
> some ways
> in which virtualizability can enhance protection (e.g. run a secure  
> VMM on the
> base system and detect rootkits in VMs).
>
> I believe such virtualization support makes it considerably easier  
> to protect
> against rootkits.  I do think running relatively vulnerable systems  
> (e.g.
> systems where you run commercial or downloaded software, systems
> that are network facing, etc.) under a VM makes protection easier.  
> I'd
> very much like to get a network monitor for my VMM.  I know that in  
> some
> sense it's safer to monitor the network externally.  Still doing so  
> is less
> convenient.  I thing such monitoring from a base VMM could be quite
> helpful.

\

> I think there are a couple of points in the paper where the authors
> got a bit enamored with their technology and seemed to suggest that it
> could do things that I believe are difficult to impossible.  For  
> example,
> when they were referring to efforts to detect a VMBR they said:
>
> "...even if the target system did see something amiss, the VMBR could
> tamper with the execution of the detector and force it to report  
> incorrect
> results."
>
> While I agree this is theoretically possible, I think in practice
> it's very unlikely to ever be achieved.

It is not so hard if the attacker has seen the code that he is trying  
to subvert.
It is nearly impossible otherwise.
This is why it is a never-ending sequence of blow and counter-blow in  
which the defender has no advantage.

>  From what I've read so far it seems that having better support for
> virtual machine monitors supports efforts at protection and
> detection more than it supports attacks.  I will personally feel
> more comfortable if I'm able to run my network facing Windows
> system under a virtual machine monitor.  E.g. one that can look
> for boot record changes, can monitor network traffic, etc.  One
> where I can take the system easily back to an initial state
> (e.g. base build, base software installed) and easily add my
> relevant files and some few new applications.
>
> --Jed http://www.webstart.com/jed/
>
>
> _______________________________________________
> cap-talk mailing list
> cap-talk@...
> http://www.eros-os.org/mailman/listinfo/cap-talk

_______________________________________________
cap-talk mailing list
cap-talk@...
http://www.eros-os.org/mailman/listinfo/cap-talk

[Jed Donnelley]

At 08:01 PM 8/3/2006, Norman Hardy wrote:

>On Aug 2, 2006, at 7:53 PM, Jed at Webstart wrote:
>...
> > when they were referring to efforts to detect a VMBR they said:
> >
> > "...even if the target system did see something amiss, the VMBR could
> > tamper with the execution of the detector and force it to report
> > incorrect
> > results."
> >
> > While I agree this is theoretically possible, I think in practice
> > it's very unlikely to ever be achieved.
>
>It is not so hard if the attacker has seen the code that he is trying
>to subvert.
>It is nearly impossible otherwise.
>This is why it is a never-ending sequence of blow and counter-blow in
>which the defender has no advantage.

I believe that the defender has some significant advantages:

1.  The ability to take the high ground with a reset to
clean media (issues with BIOS infection, etc. discussed
elsewhere), and

2.  Cooperation of the user of the system - even while running
the detection software (as I mentioned in my other message), and

3.  Hiding while consuming resources is not technically easy,
while noticing consumed resources (e.g. my bare metal discussion)
is fairly straight forward, and

4.  The attacker must constantly respond to asynchronous updates
in the detection software, while the detector need only detect the
attacker once (until the next independent infection).

I think in many ways detecting a VMBR is easier than detecting
an ordinary rootkit.  I wouldn't be surprised to see the "VMBR"
approach devolve to a situation where something more or less
like an ordinary rootkit is run in the guest OS to make detection
less likely for the VMBR.  It seems to me that techniques that
have been used for ordinary rootkits have some advantages over
the VMBR approach.  Both have the "high ground" (unless a security
VMM is running above the attacking VMBR), but in the ordinary
rootkit situation the control can be embedded deeper into the
OS, libraries, applications, etc.  The pure VMBR needs to be very
careful to avoid any machine detectable use of shared resources -
which defeats some of the purpose.  With an ordinary rootkit it seems
to me there is less concern with shared resources as detection
applications have to assume such sharing in general.  The main
concern with shared resources with ordinary rootkits is avoiding
detection by a human user - who is generally less sensitive and
more willing to gloss over apparent degradation in performance.

I believe there's a bit of sensationalism and hacker bravado in the
current VMBR discussions that won't stand the test of time.
We'll see.

--Jed http://www.webstart.com/jed/ 

_______________________________________________
cap-talk mailing list
cap-talk@...
http://www.eros-os.org/mailman/listinfo/cap-talk

[Norman Hardy]

On Aug 3, 2006, at 10:11 AM, David Hopwood wrote:

> Karp, Alan H wrote:
>> Joanna Rutkowska is the name I've seen associated with this attack,
>> which is frequently called Blue Pill, from the Matrix.  She has
>> demonstrated a running version on Vista x64 and is presenting at  
>> Black
>> Hat today.  According to reports, she was able to install the  
>> rootkit on
>> a running system, no reboot required.
>> http://www.eweek.com/article2/0,1895,1983037,00.asp is a news  
>> article on
>> the subject.
>>
>> The key point is that you're both right.  You are safer if you use a
>> virtual machine to run Windows.  However, if your base system gets
>> infected, virtualizability assures that there is no mechanism by  
>> which
>> the OS can detect the attack.
>
> That's not quite accurate; most VMMs are detectable, and AFAIK all  
> VMMs
> that run on x86 hardware (VT, Pacifica or otherwise) are detectable.
>
> It is true to say that a guest OS cannot reliably detect a VMM in a
> way that is useful to prevent this kind of rootkit attack, in general.
> After all, we don't want guest OSes to refuse to run under any VMM;
> that would be more counterproductive than helpful. Also, such a
> detection mechanism could be circumvented, if the attacker writes
> his/her code after the defender (and I believe this to be more  
> practical
> than Jed does).

It may be that
for every attack there is a defense workaround and
for every defense there is an attack workaround.
This is in contrast to the situation where you can debug a fixed set  
of privileged code.
(the design has got to be right too.)

> --
> David Hopwood <david.nospam.hopwood@...>
>
>
> _______________________________________________
> cap-talk mailing list
> cap-talk@...
> http://www.eros-os.org/mailman/listinfo/cap-talk

_______________________________________________
cap-talk mailing list
cap-talk@...
http://www.eros-os.org/mailman/listinfo/cap-talk

[David Hopwood]

Jed at Webstart wrote:
>>At 03:13 PM 8/3/2006, Karp, Alan H wrote:
>>David Hopwood wrote:
>>
>>>That's not quite accurate; most VMMs are detectable, and
>>>AFAIK all VMMs that run on x86 hardware (VT, Pacifica or otherwise)
>>>are detectable.
>>
>>That's because x86 is not fully virtualizable.

No, it isn't just because of that. Most VMMs are detectable regardless of
whether the architecture is fully virtualizable or not.

An architecture is a specification, with some aspects that are nondeterministic
or unspecified. As long as the machine provided by the VMM meets the
specification (or at least, the parts of it relied on by supported guest
OSes and their user programs), then it works sufficiently well as a VMM,
regardless of whether it can be distinguished from a hardware implementation.

There is usually no attempt to make a VMM work *exactly* like the hardware.
Even if it were possible, what would be the point? Different hardware
implementations of an architecture (even just different steppings of
essentially the same chip) are distinguishable from each other, so why should
software implementations not be distinguishable?

So, if a malware writer wants to create a VMM that will not be detected,
they cannot rely on any existing VMM implementation being *undetectable*.
Rather, they will have to make assumptions about what detection methods
are likely to be used, and try to circumvent those.

>>Rutkowska is working on architectures that are.
>
> Huh?  I thought the VT and Pacifica versions of "x86" are fully
> virtualizable.  Is that not true? My understanding is that all it
> takes to be "fully virtualizable" is to have all privileged operations
> trap in "user" mode.

That is the definition of "fully virtualizable", yes. However, despite
the name, "full" virtualizability is a rather weak property -- because
it does not imply that the processor behaves in a way that would be most
useful to a VMM when executing code in user mode. In principle, the same
code may behave quite differently in user mode than in kernel mode, so
that it is difficult for the former to emulate the latter, even though
the architecture is strictly speaking "fully virtualizable". Also, there
could be hardware features that are inherently difficult to emulate even
if the VMM is able to trap on them. If these are deprecated or very
uncommonly used features, a VMM writer might reasonably decide not to
implement them.

There are some x86 features that VT and Pacifica provide little or no
help in virtualizing. One of these is "V86 mode" (the mode used by a
protected-mode OS to run old 16-bit programs): a VMM must emulate this
mode "the hard way", using an interpreter or dynamic compiler. Another
is the VT/Pacifica-specific features themselves -- there was no
attempt (and it would have been much more complex) to make these
architectures *recursively* virtualizable.

--
David Hopwood <david.nospam.hopwood@...>


_______________________________________________
cap-talk mailing list
cap-talk@...
http://www.eros-os.org/mailman/listinfo/cap-talk

[Karp, Alan H]

Jed wrote:

> >That's because x86 is not fully virtualizable.  Rutkowska is
> working on
> >architectures that are.
>
> Huh?  I thought the VT and Pacifica versions of "x86" are fully
> virtualizable.  Is that not true?  My understanding is that all it
> takes to be "fully virtualizable" is to have all privileged operations
> trap in "user" mode.  Perhaps I misread this, but I thought
> Rutkowska was working with Pacifica.  Not?
>

My understanding is that all the papers that have shown how the OS can

detect that it has been virtualized, including VMBR, refer to less than
perfectly virtualizable hardware.  I'm not expert enough to evaluate
Rutkowska's claims.

_________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
[phone], fax [phone]
https://ecardfile.com/id/Alan_Karp
http://www.hpl.hp.com/personal/Alan_Karp/
 

[Karp, Alan H.vcf]

---

BEGIN:VCARD
VERSION:2.1
N:Karp;Alan
FN:Karp, Alan H
ORG:Hewlett-Packard Co;Advanced Architecture
TEL;WORK;VOICE:[phone]
ADR;WORK:;PAL03:H37;1501 Page Mill Rd.;Palo Alto;California;94304-1100;United States
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:PAL03:H37=0D=0A1501 Page Mill Rd.=0D=0APalo Alto, California 94304-1100=0D=
=0AUnited States
EMAIL;PREF;INTERNET:alan.karp@...
REV:20060509T161609Z
END:VCARD

---

_______________________________________________
cap-talk mailing list
cap-talk@...
http://www.eros-os.org/mailman/listinfo/cap-talk

[Jed at Webstart]

At 12:58 PM 8/4/2006, David Hopwood wrote:
>...Another is the VT/Pacifica-specific features themselves -- there was no
>attempt (and it would have been much more complex) to make these
>architectures *recursively* virtualizable.

That's interesting.  That would seem to suggest that if you're running
a VMM and some cracker tried to install a VNBR by coming in through
a guest OS, then they wouldn't be able to make use of the virtualizability
features of VT or Pacifica in any case.  Then even if they were somehow
able to break through to the hardware level and install their VMBR, it
would seem that their doing so would mess up you're running your
own VMM - making their VMBR quite visible indeed.

I'm not sure where the truth lies here, but this thought that building
virtualizable processors will somehow make them more vulnerable
to rootkits seems vastly oversold to me at this point.

Perhaps Norm remembers this technical point.  I seem to recall that
some of the IBM 370 computers came with virtual machine assist that
deliberately did provide for recursive virtualizability.  Do you recall
that Norm?  Does anyone know if there are still VM370 systems
running VMMs?

--Jed http://www.webstart.com/jed/ 

_______________________________________________
cap-talk mailing list
cap-talk@...
http://www.eros-os.org/mailman/listinfo/cap-talk

[David Mercer-2]

On 8/4/06, Jed at Webstart <donnelley1@...> wrote:
> Perhaps Norm remembers this technical point.  I seem to recall that
> some of the IBM 370 computers came with virtual machine assist that
> deliberately did provide for recursive virtualizability.  Do you recall
> that Norm?  Does anyone know if there are still VM370 systems
> running VMMs?
>
> --Jed http://www.webstart.com/jed/

See page 14, upper right column of: http://www.vm.ibm.com/library/zvmref08.pdf
VM is still recursively hostable!

-David Mercer
_______________________________________________
cap-talk mailing list
cap-talk@...
http://www.eros-os.org/mailman/listinfo/cap-talk

[Jed at Webstart]

At 03:15 PM 8/4/2006, David Mercer wrote:

>On 8/4/06, Jed at Webstart <donnelley1@...> wrote:
> > Perhaps Norm remembers this technical point.  I seem to recall that
> > some of the IBM 370 computers came with virtual machine assist that
> > deliberately did provide for recursive virtualizability.  Do you recall
> > that Norm?  Does anyone know if there are still VM370 systems
> > running VMMs?
> >
> > --Jed http://www.webstart.com/jed/
>
>See page 14, upper right column of: http://www.vm.ibm.com/library/zvmref08.pdf
>VM is still recursively hostable!
>
>-David Mercer

Amazing!  Thanks for sharing that David!  I guess I should connect to my
buds working on IBM systems if I really want to do some work with VMs.
It seems I'm not likely to be able to afford one of those System z servers:

http://www-03.ibm.com/systems/z/hardware/

for my home though, even if it does run Linux ;-)  Here's a note on Linux/390:

http://linas.org/linux/i370.html

that points to this VM (like Klenex, no need to say "IBM") paper:

http://vm.marist.edu/~mvmuajs/vmoutlook/
(last updated 11/99)

This quote from the paper is somewhat telling:
_____________________________________________
IBM has always had an ambivalent attitude towards VM. One of VM's
problems for IBM has been that it's just too efficient; IBM would
much rather that customers use a "strategic" platform that just
happens to require much more expensive iron to run. In later sections
of this paper I'll discuss IBM's attempts to move customers to
inappropriate, and often inferior technology.

As a result, IBM has always had an element that wished VM would
disappear. and predicted VM's imminent demise many times in VM's
25-year history. These predictions turned out to be foolish, and VM
has outlived many of its detractors within IBM. This has also had the
effect of alienating many IBM customers, and reducing IBM's credibility.

Incidents of IBM staff telling customers that "VM is dead" have been
reported since VM's early days. I don't think IBM realizes that
insulting parts of its product line damages its entire brand
reputation. This type of unprofessional behavior does not help
convince me to buy anything from IBM. Fortunately, this type of
self-inflicted wound seems to happen less frequently now, though a
lot of damage was done. If you see an IBM person badmouthing VM,
report it to the VM management team, and they'll see that it is dealt
with appropriately.
______________________________________________

I guess I was one of those fooled into thinking VM was dead.  This is
a good one, "...new use of VM, most notably VM web serving...".  I
can see how it would make some sense.

I love this (from the above), "Some people say VM is dead. Other
people say MVS is dead, OS/2 is dead, DOS (the mainframe variety) is
dead, DOS (the PC variety) is dead, Apple is dead, and even Unix is
dead. Some of these statements may be true. Well, OS/2 is definitely dead."

Heh ;-)     Also, "IBM's lack of marketing support for VM ensured
that only people who think for themselves would run VM. The result
was to 'select' VM customers for lack of docility."

Isn't amazing some of the techno/cultural niches we can get into as
computer people!?!

--Jed http://www.webstart.com/jed/ 

_______________________________________________
cap-talk mailing list
cap-talk@...
http://www.eros-os.org/mailman/listinfo/cap-talk

[David Mercer-2]

On 8/4/06, Jed at Webstart <donnelley1@...> wrote:

> At 03:15 PM 8/4/2006, David Mercer wrote:
> >On 8/4/06, Jed at Webstart <donnelley1@...> wrote:
> > > Perhaps Norm remembers this technical point.  I seem to recall that
> > > some of the IBM 370 computers came with virtual machine assist that
> > > deliberately did provide for recursive virtualizability.  Do you recall
> > > that Norm?  Does anyone know if there are still VM370 systems
> > > running VMMs?
> > >
> > > --Jed http://www.webstart.com/jed/
> >
> >See page 14, upper right column of: http://www.vm.ibm.com/library/zvmref08.pdf
> >VM is still recursively hostable!
> >
> >-David Mercer
>
> Amazing!  Thanks for sharing that David!  I guess I should connect to my
> buds working on IBM systems if I really want to do some work with VMs.
> It seems I'm not likely to be able to afford one of those System z servers:
>
> http://www-03.ibm.com/systems/z/hardware/
>
> for my home though, even if it does run Linux ;-)

If you wanna play with LInux/s390, you can get a login to your very
own linux VM for free over at:
http://www-03.ibm.com/servers/enable/site/testdrive/zseries/index.html

I've ported/validated some different open source packages on
Linux/s390 for the sheer hell of it before, it's pretty much like any
other linux.  I have no idea if they have any VM/CMS sessions
available for use by developers (for love or money).  They charge
(gasp!) $2000+/MONTH for use of a z/OS virtual system (MVS by a new
name).

-David Mercer
_______________________________________________
cap-talk mailing list
cap-talk@...
http://www.eros-os.org/mailman/listinfo/cap-talk

[Norman Hardy]

On Aug 4, 2006, at 2:32 PM, Jed at Webstart wrote:

> At 12:58 PM 8/4/2006, David Hopwood wrote:
>> ...Another is the VT/Pacifica-specific features themselves --  
>> there was no
>> attempt (and it would have been much more complex) to make these
>> architectures *recursively* virtualizable.
>
> That's interesting.  That would seem to suggest that if you're running
> a VMM and some cracker tried to install a VNBR by coming in through
> a guest OS, then they wouldn't be able to make use of the  
> virtualizability
> features of VT or Pacifica in any case.  Then even if they were  
> somehow
> able to break through to the hardware level and install their VMBR, it
> would seem that their doing so would mess up you're running your
> own VMM - making their VMBR quite visible indeed.
>
> I'm not sure where the truth lies here, but this thought that building
> virtualizable processors will somehow make them more vulnerable
> to rootkits seems vastly oversold to me at this point.

Seems right

> Perhaps Norm remembers this technical point.  I seem to recall that
> some of the IBM 370 computers came with virtual machine assist that
> deliberately did provide for recursive virtualizability.  Do you  
> recall
> that Norm?  Does anyone know if there are still VM370 systems
> running VMMs?

Long story. There were versions of VM/370 that could run several deep.
IBM first added VM-assist which was an option the CP could select that
caused the hardware to 'do the right thing' with certain simple frequent
privileged instructions. CP would select this option when running
virtually privileged code.
Different models of 370 could virtualize different subsets of the  
privileged
functions and CP retained the ability to interpret all priv-ops.
I think that the virtual machines lacked VM-assist.
Later IBM introduced SIE (Start Interpretive Execution).
They released an incomplete specification of this instruction, but  
changed
their mind and never released the complete specs.
Roughly SIE virtualized the entire privileged mode except for I/O.
The memory operand of the SIE pointed to a memory area where
images of virtual special registers were kept.
I think it was never documented completely for public consumption.
SIE was a privileged instruction for no reason that IBM would reveal.
There was no reason that CP could not have emulated SIE as it emulated
other priv-ops but I think that it did not.
We (Tymshare) stopped using VM/370 when IBM ceased delivering
the source code.
SIE was subsequent to that.


> --Jed http://www.webstart.com/jed/
>
> _______________________________________________
> cap-talk mailing list
> cap-talk@...
> http://www.eros-os.org/mailman/listinfo/cap-talk

_______________________________________________
cap-talk mailing list
cap-talk@...
http://www.eros-os.org/mailman/listinfo/cap-talk

[Norman Hardy]

On Aug 4, 2006, at 3:15 PM, David Mercer wrote:

> On 8/4/06, Jed at Webstart <donnelley1@...> wrote:
>> Perhaps Norm remembers this technical point.  I seem to recall that
>> some of the IBM 370 computers came with virtual machine assist that
>> deliberately did provide for recursive virtualizability.  Do you  
>> recall
>> that Norm?  Does anyone know if there are still VM370 systems
>> running VMMs?
>>
>> --Jed http://www.webstart.com/jed/
>
> See page 14, upper right column of: http://www.vm.ibm.com/library/ 
> zvmref08.pdf
> VM is still recursively hostable!

Thanks for finding that link.
As David Hopwood says, there is much variability in what features a  
real system has and I suspect that higher level virtual zSeries  
machines become simpler on this axis.
There is amazing smoke and mirrors under the cover in the zSeries.
Depending on the model it bottoms out in an x86 running code from  
Fundamental software <http://www.funsoft.com/>,
A power PC with special features, or an honest to goodness 64 bit  
implementation of the greatly enhanced 370 instruction set.

>
> -David Mercer
> _______________________________________________
> cap-talk mailing list
> cap-talk@...
> http://www.eros-os.org/mailman/listinfo/cap-talk

_______________________________________________
cap-talk mailing list
cap-talk@...
http://www.eros-os.org/mailman/listinfo/cap-talk

[Karp, Alan H]

David Hopwood wrote:
> >                                   My understanding is that all it
> > takes to be "fully virtualizable" is to have all privileged
> operations
> > trap in "user" mode.
>
> That is the definition of "fully virtualizable", yes.

My understanding is that these systems don't trap the privileged
instructions in user mode.  Instead they run the OS in Ring 1 and the
rootkit in Ring 1.
 
_________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
[phone], fax [phone]
https://ecardfile.com/id/Alan_Karp
http://www.hpl.hp.com/personal/Alan_Karp/
 

[Karp, Alan H.vcf]

---

BEGIN:VCARD
VERSION:2.1
N:Karp;Alan
FN:Karp, Alan H
ORG:Hewlett-Packard Co;Advanced Architecture
TEL;WORK;VOICE:[phone]
ADR;WORK:;PAL03:H37;1501 Page Mill Rd.;Palo Alto;California;94304-1100;United States
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:PAL03:H37=0D=0A1501 Page Mill Rd.=0D=0APalo Alto, California 94304-1100=0D=
=0AUnited States
EMAIL;PREF;INTERNET:alan.karp@...
REV:20060509T161609Z
END:VCARD

---

_______________________________________________
cap-talk mailing list
cap-talk@...
http://www.eros-os.org/mailman/listinfo/cap-talk

[David Hopwood]

Karp, Alan H wrote:

> David Hopwood wrote:
>
>>>                                  My understanding is that all it
>>>takes to be "fully virtualizable" is to have all privileged
>>>operations trap in "user" mode.
>>
>>That is the definition of "fully virtualizable", yes.
>
> My understanding is that these systems don't trap the privileged
> instructions in user mode.  Instead they run the OS in Ring 1 and the
> rootkit in Ring 1.

In architectures with multiple privilege rings, the definition above should
be interpreted as "there exists a privilege ring in which all privileged
operations trap". Which specific ring is used in any case may differ between
VMMs.

--
David Hopwood <david.nospam.hopwood@...>


_______________________________________________
cap-talk mailing list
cap-talk@...
http://www.eros-os.org/mailman/listinfo/cap-talk