Re: Lisp and low-level operating system development

Eli Gottlieb wrote:
> Nathan Baum wrote:
> > Shocking. Why don't we just start programming in assembly again? I had
> > thought that the lessons of the past would have been learned by most
> > people by now.
>
> Why should we start programming in C# now?

I don't know. I didn't say we should.

> > Firstly, it isn't only bad programmers who forget what they did with
> > memory. Or are you claiming that you've _never_ lost a pointer in a
> > language which doesn't do automated garbage collection?
>
> I don't think I've done that much memory leaking in my time, but a lot
> more writing to memory that isn't allocated by accident.

But you would _still_ object if your language, environment and software
conspired to make it impossible for you to write to memory that isn't
allocated?

> > Secondly, you've completely overlooked the far more significant issue in
> > modern software design: that of security. A very small class of
> > exploits can be defeated by ensuring that memory is never both
> > executable and writable. But there are a great many exploits which do
> > not depend upon injecting executable code into an application -- and are
> > therefore generally immune to memory protection -- but would not be
> > immune to other security features.
>
> What do you want, the Trusted Computing Platform?

This appears to be an argument of the form "you want X, Y gives you X,
Y also gives you Z, you don't want Z, therefore you don't want X." In
this case X = security, Y = TCP and Z = draconian digital rights
management.

You're right in implying that I don't want TCP. But TCP isn't the only
hardware solution to security issues, so it's not really relevant, is
it?

> Security can be had by /writing secure software/.

If it was as simple as that, then all software would be secure. The
truth is that writing secure software is _hard_. Even people who _know_
people will try to find exploits in their software cannot always make
it secure.

Some kinds of security holes are errors of logic which no environment
could resolve. By demanding that programmers should deal with _both_
the problems the environment cannot _and_ the ones it can, you're
making programmers do extra work: extra work they shouldn't have to do.

> If you start putting in VM features to check code or whatnot people just
> start writing exploits for those VM features.

Of course they will. But the "VM" will be designed from the ground up
for security.

It isn't an software virtual machine in the way you're envisioning.
It's a physical architecture which provides sophisticated
virtualisation, protection and memory management facilities. Its design
will be _informed by_ existing emulated virtual machines.

Physical machines appear to have a good track record for security. I've
never heard of anybody exploiting a weakness in the IA-32 instruction
set to gain control over a computer. It seems reasonable to assume that
if such a weakness existed, then nobody would bother finding ways to
elevate their priviledges.

Even for a software virtual machine, there is the significant advantage
of the number of programmers available to debug it. A large company
might be able to assign hundreds of programmers to fixing bugs in the
SVM, and if the source code is available for public review, thousands
more could detect and fix bugs.

.

Relevant Pages

  • RE: Deny access to copy files
    ... VMs are not a security device. ... then allow the access to the code only via the virtual machine. ... I think its more frustrating for programmers to know that they have to ... AK> clueless, How can I restrict web based emails like hotmail, gmail, ...
    (Security-Basics)
  • Re: Forcing data into RAM memory only?
    ... Programmers often ask for help with a solution to a problem instead of ... security issue that will get a better answer in the security newsgroup. ... locking memory is a bad one, but I am not a security specialist. ... to disk unless the program wants to write it. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Thou shalt have no other gods before the ANSI C standard
    ... >> are sold a year, then guess how many embedded systems are sold a year. ... > When's the last time someone tried to exploit a security hole in the ... Too many programmers are hearing about buffer ...
    (sci.crypt)
  • Re: [Full-Disclosure] DCOM RPC exploit (dcom.c)
    ... Information Security Engineer ... > IMHO it is TIME to sue corporations like microsoft for their stupidity ... they're sending all their programmers ... interpreted languages, meaning .net. ...
    (Full-Disclosure)
  • Re: HardBound and SoftBound (was "The State of Software")
    ... We need to find places, bottlenecks if you will, that all or most codes pass through, where security constraints can be enforced. ... The compiler / JIT / run-time is an incomplete gateway. ... programmers to use them, instead of beating themselves up with largely ...
    (comp.arch)