Re: nasm over gas?

["Richard B. Johnson" <root@chaos.analogic.com>]

On Fri, 5 Sep 2003, John Bradford wrote:

> > > Are there any buffer overflows or other security holes?
> > > How can you be sure about it?
> >
> > How can you be sure? Mathematical program verification applies quite badly
> > to assembler.
>
> The point is, if somebody does find a bug they will want to
> re-assemble with Gas after they've fixed it.
>
> > > If your code fails on any one of these questions, forget about it.  If
> > > it survives them, post your results and have someone else verify them.
> >
> > I'm sorry, your critique is too generel to be useful.
>
> It's not, all the time the argument is not against the assembler code,
> but rather against $assembler!=Gas.
>
> John.

All assemblers suck. However, they are exceeding useful. The
code ends up being exactly what you write. Usually one only
needs to learn one assembler per platform. It was a real shock
for me to have to learn GAS, it was "backwards", seemed to
think everything was a '68000, and basically sucked. However,
once I learned how to use it, it became a useful tool. In
a mini-'C' library I wrote for a project, the total sharable
runtime-library size is:

crt.so: ELF 32-bit LSB shared object, Intel 80386, version 1, stripped
-rwxr-xr-x   1 root     root        77896 Aug 20 2000 assembly/crt.so
-rw-r--r--   1 root     root         1448 Aug 20 2000 assembly/start.o

This includes most of the string stuff and the 'C' interface to
Linux.

The test of code that works in the 'real' world is called
regression-testing. Basically, you run the stuff. You execute
all "known" possible execution paths. If it works, it works.
If it doesn't, you fix it until it does. Seeding with faults
to see if your regression test picks it up, as is proposed
by a bunch of different testing methods, is absurd whether it's
written in assembly or C#. It doesn't matter what the
language is. You need to test procedures as "black-boxes" with
specified inputs and outputs. You also have to violate the
input specifications and show that an error, so created, doesn't
propagate. Such an error need not crash or kill the system, but
it must be detected so that invalid output doesn't occur.

Error-checkers like Lint, that use a specific langage such as 'C',
can provide the programmer with a false sense of security. You
end up with 'perfect' code with all the unwanted return-values
cast to "void", but the logic remains wrong and will fail once
the high-bit in an integer is set. So, in some sense, writing
procedures in assembly is "safer". You know what the code will
do before you run it. If you don't, stay away from assembly.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (794.73 BogoMips).
            Note 96.31% of all statistics are fiction.