svn commit: samba-web r1020 - in trunk/news/articles/low_point: .
deryck at samba.org
deryck at samba.org
Fri Jul 28 15:10:30 GMT 2006
Author: deryck
Date: 2006-07-28 15:10:28 +0000 (Fri, 28 Jul 2006)
New Revision: 1020
WebSVN: http://websvn.samba.org/cgi-bin/viewcvs.cgi?view=rev&root=samba-web&rev=1020
Log:
Add two new columns to Jeremy's column archive.
News story forthcoming.
deryck
Added:
trunk/news/articles/low_point/column15.html
trunk/news/articles/low_point/column16.html
Modified:
trunk/news/articles/low_point/index.html
Changeset:
Added: trunk/news/articles/low_point/column15.html
===================================================================
--- trunk/news/articles/low_point/column15.html 2006-07-25 22:20:56 UTC (rev 1019)
+++ trunk/news/articles/low_point/column15.html 2006-07-28 15:10:28 UTC (rev 1020)
@@ -0,0 +1,117 @@
+<!--#include virtual="/samba/news/header.html" -->
+ <title>The Low Point -- Jeremy Allison Column Archive -- Column 15</title>
+<!--#include virtual="jra_header2.html" -->
+
+<h3>Jeremy Allison Column Archives</h3>
+
+<h2>The Low Point — a View from the Valley — Column 15</h2>
+
+<h3>Embedded in a hospital</h3>
+
+<p>Due to various family ailments and events (some serious but none
+fatal thank goodness) I've had to spend a lot of time visiting hospitals
+recently, both in the UK and the USA. The contrast between the two is
+quite interesting, mainly in the way technology is used in each.
+</p>
+<p>In England the atmosphere is almost entirely anti-technology, from
+the entrance posters warning you to switch off your cell phone as even
+the static electricity in your clothing might cause “SENSITIVE MEDICAL
+EQUIPMENT TO FAIL”, to the beefy hospital orderlies who will rush
+out with claw hammers and smash your phone or laptop into tiny pieces
+should you even make a move toward the power switch inside the hospital.
+The medical care is really good though (even if the food is <em>really</em> bad).
+</p>
+<p>In the hospital I visited in the USA the entrance posters proclaimed
+it “the most wired hospital in the Valley” and I was able to sit
+in a waiting room and patient ward and surf the Internet with my laptop
+and Nokia Linux palmtop and make Skype voice calls from the patient
+bedside via the open wireless network. I must confess, I did check in
+Samba code fixes whilst being there for a family reason. Hey, it's an
+open wireless network, what was I going to do – ignore it ? The Samba
+Team never sleeps you know. The difference between this place and the
+red-brick Sheffield NHS hospital was only evident when you looked at
+the “Poor people please go and die elsewhere” notices posted on
+convenient walls. Still, if you have employer insurance and decent coverage
+and can navigate the baroque billing bureaucracy you will eventually
+get good health care. Prescriptions are extra though, along with extra
+charges (charmingly called “co-pays”) at each visit to a doctors
+surgery. Strangely enough the food there was also <em>really</em> bad. Maybe
+that's a universal law of hospitals. At the cost of a few broken cell
+phones I know which I prefer.</p>
+<p>One thing both hospitals had in common though, was that all the computers
+dealing with medical records and even some of the medical equipment
+with a recognizable PC based interface were all running some version
+of Windows. You could tell by the icons used and the graphical style
+of the interfaces, even when there wasn't a prominently visible “Start”
+button, as was more often the case.</p>
+
+<p>Are the hospital administration and device manufacturers <em>insane</em> ?
+In the litigious USA it should only take one bad virus or security breach
+incident to precipitate a lawsuit that could shut down the “most wired”
+hospital, or at least raise their insurance charges. People have already
+died due to software errors in medical device equipment although in
+all fairness the cases I'm familiar with weren't running Windows. Least
+you think I'm picking an easy target I don't think they should be running
+a Linux variant either.</p>
+<p>Whilst I worked at Sun Microsystems we transferred from the SunView
+SunOS kernel-based graphical windowing system to an X Windows based
+graphical user interface for the operating system. One of the things
+we were warned about was not to recommend or use the software for safety
+critical functions, as one misplaced XGrabPointer() API call (don't
+ask, it's an X Windows thing) can cause other applications to miss critical
+events. Imagine that in an air-traffic control room. Windows today is
+probably only a tenth as reliable as the old SunOS systems we ran in
+the late 1980's, and that wasn't considered reliable enough to run telephone
+equipment, let alone embedded medical devices.</p>
+<p>One of my first paying jobs was designing a small part of the control
+software for a mass-spectrometer. It wasn't safety critical or even
+dealing with secure data but it was still <em>hard</em> to get the thing error
+free and reliable, and this was running on the bare-metal of a very
+simple 6800 (yes, that's sixty-eight hundred, not sixty-eight thousand;
+that should tell you how old I am) based processor without any operating
+system. Choosing Windows for an embedded system that is used in medicine,
+or even a standard off the shelf Linux distribution is playing with
+fire. These generic systems aren't reliable enough for use like this,
+no matter how convenient (and by that I really mean <em>cheap</em>) it is to
+find programmers who understand the graphical tools and can build flashy
+looking interfaces for a device. Personally I wouldn't even run Windows
+for an airline baggage display device, based on the number of blue-screens
+of death I've seen whilst waiting for my luggage at airports.
+</p>
+<p>But the most scary part is the possibility of a monoculture in embedded
+devices. No matter if you believe that Windows is reliable enough for
+this use, the danger is multiplied if most embedded devices are based
+on one common codebase, with one set of errors to be exploited. This
+shouldn't be Windows, Linux, the BSD-of-the-month club or any of the
+commercial off the shelf embedded operating system environments. For
+really safety critical systems the only safe way to design is to have
+one or more backup systems written by a completely different programming
+team. That way if a design flaw allows the primary system to be shut
+down, either by accident or malicious attack, then hopefully the backup
+systems won't be vulnerable to the same flaw. The monoculture danger
+is very real. Microsoft is very effective at leveraging their monopoly
+power to drive their software into inappropriate places. Imagine a device
+that has to display medical video data to a doctor in a world where
+all video is in Windows-media-only format and you'll get the idea of
+how this might end up being done.</p>
+<p>The environments I encountered in hospital reminded me of an idea
+for a parody of a Microsoft Windows advertisement dreamed up by Michael
+Tiemann of Red Hat, when I worked for him at Cygnus Software many years
+ago. He imagined a frustrated office worker late at night working on
+a critical document when the computer crashes with the Windows blue
+screen of death. In a panic he picks up an old paper copy and tries
+to fax it, only to have the fax machine fail in the same way. Picking
+up his cell phone he tries to call his boss only to have the cell phone
+crash with a blue screen. Finally he gives up and turns on the television,
+only to be greeted with a pitch for Microsoft Windows, “and the beauty
+of it is that it works the same way <em>everywhere....</em>”.</p>
+
+<ul style="list-style-type:none;margin:0;padding:0">
+<li>Jeremy Allison,</li>
+<li>Samba Team.</li>
+<li>San Jose, California.</li>
+<li>22nd March 2006.</li>
+</ul>
+
+
+<!--#include virtual="/samba/news/footer.html" -->
Added: trunk/news/articles/low_point/column16.html
===================================================================
--- trunk/news/articles/low_point/column16.html 2006-07-25 22:20:56 UTC (rev 1019)
+++ trunk/news/articles/low_point/column16.html 2006-07-28 15:10:28 UTC (rev 1020)
@@ -0,0 +1,119 @@
+<!--#include virtual="/samba/news/header.html" -->
+ <title>The Low Point -- Jeremy Allison Column Archive -- Column 16</title>
+<!--#include virtual="jra_header2.html" -->
+
+<h3>Jeremy Allison Column Archives</h3>
+
+<h2>The Low Point — a View from the Valley — Column 16</h2>
+
+<h3>“Trusted” Computing</h3>
+
+<p>One of the most disturbing news items of the past few days was watching
+the Chinese President Hu Jintao meeting with Bill Gates at the Gates's
+mansion, even <em>before</em> he met with President George Bush. A smiling Hu
+Jintao mentioned how he used Mr. Gates operating system every day, and
+Bill promised to help him out with technical support.</p>
+<p>But Bill and the Redmond crowd might be helping out with more than
+just technical support, and not to help the Chinese government either.
+Humor me a moment while I take a little diversion back to 1982.
+</p>
+<p>The largest non-nuclear explosion ever recorded by satellite took
+place in Russia in 1982, and was an explosion in the Siberian gas pipeline.
+The shocking, and little-known truth about this catastrophe was that
+it was directly caused by the CIA by deliberately giving the Soviet
+Union modified <em>software</em> (in binary only format of course) that was engineered
+to destroy the pipeline. Lest you think this is a paranoid fantasy (it
+<em>sounds</em> like one, I know) this was documented in the book "At the
+Abyss: An Insider's History of the Cold War", by Thomas C. Reed,
+a former Air Force secretary who served in the National Security Council,
+reported on by the Washington Post in 2004, and even mentioned in a
+1996 article in the CIA journal “Studies in Intelligence”.
+</p>
+<p>This wasn't just an attack on the Soviet Union, but indirectly affected
+Western European gas prices (the pipeline destroyed was designed to
+feed gas to Europe), as a side effect of the US attempt to disrupt Soviet
+hard currency earnings. I wonder if the Chinese are students of this
+particular part of history ? Judging by their eagerness to embrace Windows
+in their infrastructure, and the recent promises by Chinese PC makers
+to include “genuine Windows” on PC's shipped in China, it would
+seem not. This single incident of modified binary-only software causing
+massive economic damage should be required reading for the decision
+makers of any nation that might have conflicting interests to the USA.
+That's everyone else in the world, just in case you were wondering.
+Even that normally docile American pet the UK has balked at accepting
+binary-only control software for the new Joint Strike Fighter aircraft
+and threatened to cancel the order if they don't get access to the source
+code. Maybe the UK isn't so docile after all, as the UK military certainly
+seems to understand the need to control the software in at least some
+critical parts of their own infrastructure.</p>
+
+<p>So who can you trust in computing, and why ? I'd love to say that
+Open Source code companies can be trusted as they give you the source
+code, and proprietary companies can not, as source code isn't available,
+but it's not as simple as that. Microsoft loudly proclaim they already
+make the Windows source code available to China and any other countries
+who complain about the possibility of such binary-only threats. Do you
+imagine that any US Linux distributor would say no to the US government
+if they were <em>requested</em> (politely, of course) to add a back-door to the
+binary Linux images shipped as part of their products ? Who amongst
+us actually uses the source code so helpfully given to us on the extra
+CDs to compile our own version ? With Windows of course there are already
+so many back-doors known and unknown that the US government might not
+have even bothered to ask Microsoft, they may have just found their
+own, ready to exploit at will. What about Intel or AMD and the microcode
+on the processor itself ?</p>
+<p>Even with access to Windows source code, it is still not safe to
+trust it unless you compile that code yourself and only install the
+binary versions you create on your own machines. Having source code
+that claims to match a product proves nothing about the binary version
+of the product you're using unless you've created it yourself. How many
+versions of Windows installed on Chinese government computers were actually
+compiled by the Chinese themselves. None, I'd guess. The same of course
+is true for the UK. What this means is that governments around the world
+who accept binary packaged software from US software companies are at
+the mercy of the US intelligence services who may or may not have decided
+to add just that little “extra” into the code. If you think I'm
+being paranoid about this just ask the Russians.....</p>
+<p>Just for completeness for the truly paranoid even compiling the source
+code yourself actually isn't enough to ensure you're getting “trusted”
+computing. In his landmark 1984 paper “Reflections on trusting trust”
+Ken Thompson, one of the original UNIX authors, tells a tale of how
+he hacked the C compiler on the UNIX system, the software used to create
+new binary code from source code, to add a completely undetectable back-door
+into UNIX. Once set up there was no trace of the back-door he added
+in any of the publicly available UNIX source code, it was cleverly hidden
+in the binaries and was designed to propagate itself into any new binaries
+created on the system. This was a theoretical attack, not something
+he actually did, but something he <em>could</em> have done. At least I hope so,
+but then I'm inclined to trust him. The only way to get trusted code
+is to design the processor yourself (yes there can be back-doors in
+processor microcode as well as ordinary binary code), write your own
+compiler and audit all the Open Source code you create yourself for
+use in your command and control systems. Anything else is trusting the
+untrustworthy.</p>
+<p>I'll leave you with some words from Ken Thompson's paper that are
+just are true today as in 1984.</p>
+
+<blockquote>
+<em>“The moral is obvious. You can't trust code that you did not totally
+create yourself. (Especially code from companies that employ people
+like me.) No amount of source-level verification or scrutiny will protect
+you from using untrusted code. In demonstrating the possibility of this
+kind of attack, I picked on the C compiler. I could have picked on any
+program-handling program such as an assembler, a loader, or even hardware
+microcode. As the level of program gets lower, these bugs will be harder
+and harder to detect. A well installed microcode bug will be almost
+impossible to detect.”</em>
+</blockquote>
+
+
+
+<ul style="list-style-type:none;margin:0;padding:0">
+<li>Jeremy Allison,</li>
+<li>Samba Team.</li>
+<li>San Jose, California.</li>
+<li>24th April 2006.</li>
+</ul>
+
+
+<!--#include virtual="/samba/news/footer.html" -->
Modified: trunk/news/articles/low_point/index.html
===================================================================
--- trunk/news/articles/low_point/index.html 2006-07-25 22:20:56 UTC (rev 1019)
+++ trunk/news/articles/low_point/index.html 2006-07-28 15:10:28 UTC (rev 1020)
@@ -24,6 +24,8 @@
<li><a href="column12.html">Column 12 — We are the champions...</a></li>
<li><a href="column13.html">Column 13 — Unintelligent Design</a></li>
<li><a href="column14.html">Column 14 — Why we fight</a></li>
+ <li><a href="column15.html">Column 15 — Embedded in a hospital</a></li>
+ <li><a href="column16.html">Column 16 — "Trusted" Computing</a></li>
</ul>
<p>The following article was rewritten for publication in
More information about the samba-cvs
mailing list