Here is Chris Quirke's reply via email:
At 04:39 1/8/2008, you (I Dan -- added to minimize confusion)
wrote: >Here is the latest reply from Kerry Brown:>> >
What you (as a user or customer) wants to avoid, is an arms race.> > But an
arms race may suit your vendors just fine.>>>
I think we are already involved in this arms race. Yep. The cat's been left
out of the bag so long, with so much easygarbage around to eat, that it's
grown into a mighty lion. >Finding a way to stop it Why stop what
drives sales and vendor dependency? >I think that given the future
of "cloud" computing ... That is to be led by what you want, not what is
possible.
But sanity-check against what is likely to work safely; then maybe not
>...the network stack needs to be at a very low level in the OS>and
completely protected from all other processes OK, but IMO it would be a
mistake to weld it *into* the OS. IOW, yes; itshould be hidden inside the OS
as a "black box" with a small, generalizedand well-coded API that pulls data
into managed shapes (e.g. if a buffer isX bytes long, pull up to X bytes and
not until data-defined delimiter reached). But no, it should not be so
integrated into the OS that the difference betweenlocal and networked
operations are seamless and thus lost. It's tempting to make that mistake
("write once, re-use everywhere!") andsuch a design may be appropriate for
the managed-network crowd who driveMS's development. But it would be
repeating previous mistakes (RPC, LSASS;why were these ever exposed to the
Internet?) for free stand-alone consumers. >A new code base is probably
needed for this. The opportunities are 64-bit PC code and IPv6. I'm not sure
if these havebeen seized firmly enough to deliver on this; a full kernel
re-design wouldbe beyond the Vista and Windows 7 time frames, and we need
64-bit now. So I think we'll monkey around with the arms race for another 3-7
years,allowing exploitability to escalate into a crisis that we can then cure
withthe distasteful medicine of a new OS that breaks a lot of compatibility.
>I see a very minimal hypervisor based OS with hardware support,>including
networking, and not much else. Everything else would run>in virtual machines.
Each application would have it's own virtual machine>and only talk to other
applications and the OS through strictly enforced>communications channels. A
bit like the way 9x ran DOS apps, eh? Except those had no API totalk to each
other, given that DOS pre-dated 9x and 9x didn't pool theDOS environment
variables across the separated DOS sessions. >Applications could also have
their own virtual file system completely>inaccessible to other applications
if they wanted. Hardware is advancing>at a pace that this will be be possible
in the near future if not already. We>are currently using OS's that have
security and other problems because>they were designed to make the most of
minimal hardware. We are already consuming hardware gains in order to make
softwaremore reliable, if not safer - e.g. the move from tight assembler or C
codingto higher-level languages, 8-bit ASCII to 16-bit Unicode, yy to yyyy,
there-use of ever-larger code blocks as "black boxes" with the attendantbloat
of overall software size, code duplication via SxS, etc. We have to do that
to maintain an acceptable overall error rate. Let's sayyou'd tolerate 10 bugs
per application, and an application is now made ofa million lines of code,
rather than a thousand. Your error rate now has toimprove from 1% to 0.001%,
and the stress of double-checking my mathswill indicate how painful that is
likely to be
What's changed, is that errors are now likely to be exploited. We canfix
that by keeping errors away from exposed surfaces and better isolatingsystems
so they can be recovered more effectively. But as we're headingin the
opposite direction - glomming everything into one huge networkedmess - we
will more likely attempt to forge new artificial scopes betweenwhat we need
to isolate for safety. That hasn't worked too well, so far. It has spawned a
huge industry - whichdwarfs the dev and field-tech resources allocated to
consumeralnd - in theattempt to scope between user accounts. That massive
resource allocationhas not ended the game, but drags on as an escalating arms
race - which isgreat for the US (what else does that economy offer the rest
of the world thesedays, other than pulp entertainment?) but doesn't solve our
problem. Reminds me of the old communist rhetoric, i.e. it's always
"towards..." thisand "an approach to..." that, without ever any deliverables.
>We need an OS that is aware that things exist "out there somewhere">but it's
core is isolated by hardware means. Don't under-estimate the impact of this;
it will soak up hardware resourceslike you would not believe.
For example, to be useful to consumers, youcould extend the current "user
accounts rights" model to treat every appas a separate user; that would bring
to bear the richly-mature world ofmanaged permissions on the safety problems
we face ITW. But that blows out on scalability, i.e. wherever you bind "a
few" new thingsto a huge unbounded number of instances Expect to have 1M
permissionsfor a 10k data file, 3 out of 4 cores dedicated to navel-gazing
what shouldbe allowed to do what, only partly offset by look-up tables that
need RAM. This is still a house of cards that could fail spectacularly at any
time, shouldanything drill below these levels of abstraction (i.e. attain
"Matrix-vision", ifyou will).
That's because the lower levels of abstraction may be as easy towork with,
in their own terms, as the top level (after all, it was created by thesame
level of computing power, i.e. human enterprise). We've already learned how
meaningless "an attacker would have to..."mitigations are in the real world,
when difficult exploits become just anotherfreely-available re-usable "black
box" code object. As long as the defended and attacker are made of the same
stuff, you'll havean arms race, and as long as attackers have easier goals,
the attackers willbe held back only by available resources. The more revenue
the attackerscan generate, the more resources become available... malware may
alreadybe the bulk of the computing industry, in some places. Going back on
topic; right now, MS is the primary provider of system codefor most of us,
and I'm sure MS would want to keep it that way - so the Qbecomes: Do we need
a new source code for the future? For medium-term values of "future", e.g.
beyond Windows 7, I'd say yes...and the challenge is how to design this so we
don't make mistakes weare still making right now.
We need to scope between contexts effectively, separating what needsto be
separated, while pooling seamlessly that which we see as unwantedbarriers to
functionality. The mistake to avoid is to forget about scopes wehaven't
needed until now, because natural barriers did the same thing. We need to
minimize code exposure, accepting that code will always beimperfect,
exploitable, and thus untrustworthy. Scopes do that, but wealso need
"pointed" surfaces that first expose logic that is trivial enoughto be free
of bugs (obverse of "any non-trivial code has bugs"), and thenfrom there,
progressively expands the surface, sanity-checking all the way. We need to
recognize both human users and code processes as activeplayers. Both have to
be managed in terms of what they are allowed todo, and both need accurate
safety info that is enforced by the OS.
For example, code should be aware that material to fill a buffer must
besmaller than X, should determine material is X at that code. In the same way,
users need to see what an object would do if it wereto be "opened", and
material that tries to act in other ways should becrunched by the OS. Neither
code nor user should be spoofed intotaking greater risks than code design or
user intention. We need to recognize the rights of free users to be in full
control overtheir homes, which includes the virtual homes of their computers.
Wehave learned the hard way that "to compromise freedom for security isto
attain neither"; bring that lesson to consumerland, and stop designingour OSs
to allow remote admin, hidden code, DRM, embedded payloadsthat leverage
vendor interests over our own, etc. to trump our control. Anything short of
that, is not "trustworthy computing".
----------------------------------------------------------------------- end
of reply---------
"Kerry Brown" wrote:
> >
> > What you (as a user or customer) wants to avoid, is an arms race.
> >
> > But an arms race may suit your vendors just fine.
>
>
> I think we are already involved in this arms race. Finding a way to stop it
> will be very hard at this point.
>
> To get back to the original topic. I think that given the future of "cloud"
> computing or whatever you want to call it the network stack needs to be at a
> very low level in the OS and completely protected from all other processes
> including security software. A new code base is probably needed for this. I
> see a very minimal hypervisor based OS with hardware support, including
> networking, and not much else. Everything else would run in virtual
> machines. Each application would have it's own virtual machine and only talk
> to other applications and the OS through strictly enforced communications
> channels. The application would be free to supply it's own higher level OS,
> UI, or whatever you want to call it for it's own virtual machine.
> Applications could also have their own virtual file system completely
> inaccessible to other applications if they wanted. Hardware is advancing at
> a pace that this will be be possible in the near future if not already. We
> are currently using OS's that have security and other problems because they
> were designed to make the most of minimal hardware. Many compromises were
> made to get acceptable speed. We need an OS that is aware that things exist
> "out there somewhere" but it's core is isolated by hardware means. It's like
> having someone isolated in a missile silo with only a telephone line for
> communications. You also need a well guarded elevator to get a replacement
> operator and food in (updates) but this elevator is a physical mechanism
> that is well guarded and can be shut down in an emergency. All normal
> communications are done only through the phone line.
>
> --
> Kerry Brown
> MS-MVP - Windows Desktop Experience: Systems Administration
>
http://www.vistahelp.ca/phpBB2/
>
http://vistahelpca.blogspot.com/
>
>
>
>
>
