Saw the following paper noted on Slashdot today:
http://www.cs.princeton.edu/~sudhakar/papers/memerr.pdf
I wonder if this could be a foot in the door for dynamic type checking,
since often we don't compile away all that good checking...
Kent M Pitman <······@world.std.com> wrote in message news:<···············@shell01.TheWorld.com>...
> Saw the following paper noted on Slashdot today:
>
> http://www.cs.princeton.edu/~sudhakar/papers/memerr.pdf
>
> I wonder if this could be a foot in the door for dynamic type checking,
> since often we don't compile away all that good checking...
If it were the case, it would be a good reason to use LISP in space probes, Erann ?
Igor.
From: Erann Gat
Subject: Re: space probes ? Re: Slashdot: Using Memory Errors to Attack a Virtual Machine
Date:
Message-ID: <gat-1703030800510001@192.168.1.51>
In article <···························@posting.google.com>,
··········@yahoo.com (Igor Carron) wrote:
> Kent M Pitman <······@world.std.com> wrote in message
news:<···············@shell01.TheWorld.com>...
> > Saw the following paper noted on Slashdot today:
> >
> > http://www.cs.princeton.edu/~sudhakar/papers/memerr.pdf
> >
> > I wonder if this could be a foot in the door for dynamic type checking,
> > since often we don't compile away all that good checking...
>
> If it were the case, it would be a good reason to use LISP in space
> probes, Erann ?
I haven't read the paper (yet), but (1) most space probes use rad-hard
error-correcting RAM, and (2) a lack of good reasons has never been the
limiting factor in using Lisp in space probes (or anywhere else for that
matter). See http://www.flownet.com/gat/jpl-lisp.html
:-(
E.
In article <···························@posting.google.com>,
··········@yahoo.com (Igor Carron) wrote:
> Kent M Pitman <······@world.std.com> wrote in message
news:<···············@shell01.TheWorld.com>...
> > Saw the following paper noted on Slashdot today:
> >
> > http://www.cs.princeton.edu/~sudhakar/papers/memerr.pdf
> >
> > I wonder if this could be a foot in the door for dynamic type checking,
> > since often we don't compile away all that good checking...
>
> If it were the case, it would be a good reason to use LISP in space
probes, Erann ?
>
> Igor.
I have now read this paper, and my take is that Lisp is at least as
vulnerable to this sort of problem as Java, if not more so.
In fact, Lisp seems to have nothing at all to say about security. (No
significant Lisp development has happened since the advent of the
Internet.) This is but one example of how the non-Lisp world is pulling
ahead, and why IMO Lisp needs to change or die.
E.
From: Tim Bradshaw
Subject: Re: space probes ? Re: Slashdot: Using Memory Errors to Attack a Virtual Machine
Date:
Message-ID: <ey3r895oksc.fsf@cley.com>
* Erann Gat wrote:
> I have now read this paper, and my take is that Lisp is at least as
> vulnerable to this sort of problem as Java, if not more so.
Yes, but isn't `this problem' `deploying systems with no memory error
protection at all'. The solution to this problem is `don't *do* that
then'[1]: ECC is not exactly unheard of technology, and is widely used in
non-toy machines (like: the machine I'm typing this on, which cost
~L3,000 in 1998 has it).
--tim
Footnotes:
[1] And that is the solution they recommend, too
In article <···············@cley.com>, Tim Bradshaw <···@cley.com> wrote:
> * Erann Gat wrote:
>
> > I have now read this paper, and my take is that Lisp is at least as
> > vulnerable to this sort of problem as Java, if not more so.
>
> Yes, but isn't `this problem' `deploying systems with no memory error
> protection at all'.
I'd say that ultimately "this problem" is how to deploy systems that can
run outside code securely and efficiently. ECC RAM is part of the
solution to the problem, but it is not the whole solution. Lisp running
on an ECC RAM system is much further from being a solution to the problem
of secure, efficient systems than Java running on an ECC RAM system is.
E.
From: Tim Bradshaw
Subject: Re: space probes ? Re: Slashdot: Using Memory Errors to Attack a Virtual Machine
Date:
Message-ID: <ey365qhof0j.fsf@cley.com>
* Erann Gat wrote:
> I'd say that ultimately "this problem" is how to deploy systems that
> can run outside code securely and efficiently.
Well, the paper is about what happens in the case of undetected memory
errors. You seem want to talk about something much more general, but
I think it's not right to tangle the general issues up with this
rather specific (and basically silly) one.
I can kind of see why you might want to talk about something more
general: the paper is a pretty strange unless you know the sad history
of computing - why would anyone *care* about such a stupid problem
since the fix is so well known[1]? Well, of course, because you can save
a few dollars by not bothering with the hardware checks you need to
detect (with very high probability) these errors. In the context of
space, I *really* hope people don't fly systems without very extensive
HW error protection, detection and correction.
--tim
Footnotes:
[1] It's like a paper in some nuclear engineering journal discussing
which type of reactor is safest, if you don't use any shielding.
In article <···············@cley.com>, Tim Bradshaw <···@cley.com> wrote:
> * Erann Gat wrote:
> > I'd say that ultimately "this problem" is how to deploy systems that
> > can run outside code securely and efficiently.
>
> Well, the paper is about what happens in the case of undetected memory
> errors.
It's a little more specific than that: the paper is about how memory
errors can undermine a particular security scheme. Since Lisp does not
(currently) provide security according to that scheme, the whole issue is
moot, except insofar as people consider security important nowadays, and
Lisp ought to have something to say about it if it wants to play in this
niche.
> You seem want to talk about something much more general, but
> I think it's not right to tangle the general issues up with this
> rather specific (and basically silly) one.
I don't think it's silly at all (though it is mostly irrelevant to
c.l.l.). People are actually relying on the security that Java claims to
provide.
> I can kind of see why you might want to talk about something more
> general: the paper is a pretty strange unless you know the sad history
> of computing - why would anyone *care* about such a stupid problem
> since the fix is so well known[1]? Well, of course, because you can save
> a few dollars by not bothering with the hardware checks you need to
> detect (with very high probability) these errors.
A few dollars can mean the difference between profit and loss in the
hardware industry nowadays.
> In the context of
> space, I *really* hope people don't fly systems without very extensive
> HW error protection, detection and correction.
Yes, of course we fly error correcting hardware. This paper is not
relevant to space flight. It is, however, indirectly relevant to the
issue of creating viable commercial markets for Lisp because it points out
that 1) security matters and 2) it's hard to come up with a security
scheme that really works.
E.
From: Tim Bradshaw
Subject: Re: space probes ? Re: Slashdot: Using Memory Errors to Attack a Virtual Machine
Date:
Message-ID: <ey38yvdk0y3.fsf@cley.com>
* Erann Gat wrote:
> It's a little more specific than that: the paper is about how memory
> errors can undermine a particular security scheme. Since Lisp does
> not (currently) provide security according to that scheme, the whole
> issue is moot, except insofar as people consider security important
> nowadays, and Lisp ought to have something to say about it if it
> wants to play in this niche.
Well, I guess my take on this is if you can't be bothered using error
detection (let alone correction) in your HW then how much do you
actually care about security? It seems strangely screwed up to say `I
really care a lot about security' on the one hand and `but not enough
to pay some small premium for it' on the other, doesn't it?
--tim
From: Fred Gilham
Subject: Re: space probes ? Re: Slashdot: Using Memory Errors to Attack a Virtual Machine
Date:
Message-ID: <u7r8945q1d.fsf@snapdragon.csl.sri.com>
> Well, I guess my take on this is if you can't be bothered using
> error detection (let alone correction) in your HW then how much do
> you actually care about security? It seems strangely screwed up to
> say `I really care a lot about security' on the one hand and `but
> not enough to pay some small premium for it' on the other, doesn't
> it?
I guess it's the unexpectedness of it. You figure that if the memory
malfunctions you might get inexplicable bugs and mysterious crashes,
but you don't *expect* to see someone taking over your computer
because of some cosmic ray. The invention of a method for doing so is
what makes the paper interesting (and, I suppose, scary).
--
Fred Gilham ······@csl.sri.com
The amazing thing is, back when I was a C++ programmer, I thought that
[Design Patterns] was SUCH a great book. And I guess it was, in a
way: it made it possible to use C++ and get something done. In the
long run, of course, that may have been a disservice... - Alain Picard
From: Tim Bradshaw
Subject: Re: space probes ? Re: Slashdot: Using Memory Errors to Attack a Virtual Machine
Date:
Message-ID: <ey3smtkfj5r.fsf@cley.com>
* Fred Gilham wrote:
> I guess it's the unexpectedness of it. You figure that if the memory
> malfunctions you might get inexplicable bugs and mysterious crashes,
> but you don't *expect* to see someone taking over your computer
> because of some cosmic ray. The invention of a method for doing so is
> what makes the paper interesting (and, I suppose, scary).
Yes, this is obviously where I fail to be normal. I expect *anything*
from a computer with no HW error detection or correction which gets HW
errors.
--tim
Man, I'm a sucker for getting in the middle of arguments :)
···@jpl.nasa.gov (Erann Gat) writes:
> In article <···············@cley.com>, Tim Bradshaw <···@cley.com> wrote:
>
> > * Erann Gat wrote:
> > > I'd say that ultimately "this problem" is how to deploy systems that
> > > can run outside code securely and efficiently.
> >
> > Well, the paper is about what happens in the case of undetected memory
> > errors.
>
> It's a little more specific than that: the paper is about how memory
> errors can undermine a particular security scheme. Since Lisp does not
> (currently) provide security according to that scheme, the whole issue is
> moot, except insofar as people consider security important nowadays, and
> Lisp ought to have something to say about it if it wants to play in this
> niche.
I'm not sure anyone besides Sun wants that "security" niche. When you
need a complete sandbox VM to provide "security" because you're
running untrusted binaries from who knows where, it is time to get a
dictionary and look up the word oxymoron (I wish English had a better
word for this situation - anyone know of one?). If you really need to
do something like that, this should be generalized at the OS level per
process (look at FreeBSD's jail for example).
I don't think this mode of security (it is probably more accuratly
labeled as 'trust') is wanted in any but a few cases, but it's price
is quite high (both in terms of processor time and extra complexity
added to the spec). The security that does matter is actual program
correctness (this is probably the single reason behind the relatively
(huge) success of OpenBSD as a secure OS).
On the other hand, it is interesting to see how dynamically typed/late
binding (call it whatever you will) schemes will stand up to this. I
went trolling on Slashdot about this story, and Sudhakar responded (of
course stupid me had to bite my tongue and make more work for myself
by saying I'd try the experiment - at least then we'll know). I think
I pointed out some key issues (you'll have to excuse my ignorance) -
one of them being the inlining and type optimizations that CL
compilers do (safety and speed aren't always compatible, and I like my
Lisp fast).
http://slashdot.org/comments.pl?sid=57165&threshold=1&commentsort=0&tid=172&mode=thread&cid=5521587
Vladimir
From: Tim Bradshaw
Subject: Re: space probes ? Re: Slashdot: Using Memory Errors to Attack a Virtual Machine
Date:
Message-ID: <ey3el5322cn.fsf@cley.com>
* Vlad S wrote:
> I don't think this mode of security (it is probably more accuratly
> labeled as 'trust') is wanted in any but a few cases, but it's price
> is quite high (both in terms of processor time and extra complexity
> added to the spec). The security that does matter is actual program
> correctness (this is probably the single reason behind the relatively
> (huge) success of OpenBSD as a secure OS).
Well, I think the point is that if you take your `probably correct'
system and run it on a machine which does not protect itself against
even the most trivial kinds of HW error, then you get what you paid
for, namely not much.
--tim