[Cryptography] Secure erasure - Ada may be a solution.

[Ray Dillinger]

>At 03:48 PM 9/12/2016, Watson Ladd wrote:
>> If only there was a widely used embedded language designed by the
>> DoD with built-in bounds checks, widespread compiler support on
>> different architectures, and in GCC.

>> Maybe it's even named after a woman.

I want to thank you - from the bottom of my heart, truly! for
pointing that out.  The spec writers appear to have declared war
on undefined behavior, which was just a curiosity back when but
has become something we desperately need. And I had literally
forgotten that Ada actually has the kind of control that C
compilers have been taking away and which we need for that
1% of bit-groveling code that is all about plugging the tiniest
little leaks. I wasn't in need of those things back when I
actually used Ada (for 2 semesters in college) so they didn't
make much of an impression.

On 09/12/2016 08:44 PM, Henry Baker wrote:

> What's the point of having a garbage collector (in some versions
> of Ada), if you can't control fine details enough to make sure
> that it isn't going to ruin your real-time performance?

I used Ada, half a lifetime ago - I remember it being a lot
like a more stringently type checked Modula with a bunch of
specified error checking behavior which seemed silly and
overspecified at the time but doesn't seem at ALL silly now.

Plus a lot of bolt-on code verification features I wasn't
interested in at the time but am much more interested in now.
It has a lot of stuff to do things like specify binary layout
at the bit-grinding level, etc, which I didn't appreciate at
the time because C and Pascal implementations were doing all
that stuff very reliably without the added verbosity.  Which,
AGAIN, don't seem at all silly now.

I've been having a go at the language spec and tutorials and
firing up gnat.  There's a lot of this I'm really hazy about
remembering, but it's familiar....

There is noise in the Ada spec about being amenable to either
garbage collection or conventional (for the time) allocate-
and-free memory management, but I don't think I ever actually
attempted to use garbage collection back in the day and I'm
not terribly interested in it right now.  Maybe later.

Now I'm looking at it again, and finding - HOT DAMN!!! - here
is a language that supports volatile locations where it won't
EVER under any circumstances elide a write!!!  All this time
I've been using C for security stuff mostly for that reason
alone! And it has atomic operations I can use to counter race
conditions without locks that open timing attacks!  And it has
representation pragmas - standard, not as compiler extensions
of unreliable availability - that allow to eliminate gaps in
structures where data or state could exfiltrate.  AND absolute
layout control so I can code it to directly accept calls from
C or directly call C code - OR NATIVE LIBRARIES - via targeting
a specific ABI in code that is spec-compliant and ISN'T
implementation-dependent on the Ada compiler!!  And even
absolute addressing with mmap and munmap-like facilities!
You could write _device_drivers_ with this, even in an OS
whose ABI is based on a different language!

All that grotty low-level stuff that "modern" languages got
rid of, which has kept me writing in a flying-hooks-and-bloody-
blades language in order to control!  It's all here!  And it's
here in such a way that you can IGNORE it if that grotty
low-level stuff isn't what you're doing!  And it's here in a
language that DOESN'T ignore error-checking!


> More to the point of this thread, what's the point of having a
> more array bounds checking if you can't control carefully enough
> what happens when an array index does go out of bounds?

Ada throws a CONSTRAINT_ERROR exception when an array index
goes out of bounds.  The default error handler halts the
program.  That alone would be FAR better at least for security
purposes than most of the things that out-of-range array indexing
has been used to do in C. Crashes are bad but not as bad as
breakins, botnets, rootkits, trojans, and stolen data.

But if you don't like crashes you can catch the CONSTRAINT_ERROR
with an error handling routine that does something else.  Finally
the error handler isn't global; you can set different ones for
different record types or control modules.

The runtime bounds check is parallelized (by gnat) or eliminated
(at least by the gnat compiler) when static checks indicate it
won't ever fail, and can be deliberately suppressed by the
programmer (in standard compliant code!  No compiler-dependent
pragmas required!) if the programmer is micro-optimizing
(inadvisable) and has determined via other means that it will
never fail.

> In my experience with Ada, I spent most of my time fighting the
> implementation, and after all that effort, the performance was
> dismal.

I'm with you on fighting the implementation; its type checking
is finicky and hard to satisfy. But I've been doing this level
of checking, with less consistent tools, forever, so Ada isn't
significantly a bigger fight.  All it means is that I wouldn't
be using cppcheck, frama-c, scan-build, lint, and splint so
much, and the equivalent of the -Wall -Werror I've been compiling
with is on by default.

Ada compilation was slower than C compilation in 1988 but doesn't
seem noticeably slower today.  It's about the same speed as compiling
C++ and that's reasonable because it has equally-expressive OO
features including templates, generics, and interfaces.  It's
definitely faster than I can get equivalent typechecking using
external static analyzers.

On several benchmarks, I do not experience the compiled
code being slower at runtime.

> Bottom line: Ada was PL/I with slightly more modern syntax, but
> not nearly as high quality compilers and run-time systems.

Bottom line:  looks and acts superior so far, has all the things
I need for writing grotty bit-groveling code including device
drivers and security code, appears to also be amenable to higher-
level programming, has WAY better error checking, is (and can be
FORCED to be) ABI compatible with anything, gnat appears equal
in quality to gcc, and performance is identical unless I specify
something definitely suboptimal like packed arrays of 6-bit
units.

All that 'extra' stuff is about ensuring correctness.  That's
not at all the kind of meaningless, redundant and undirected fluff
that got into PL/1.  Instead, I'd say it's a big dose of exactly
what we have come to need.

It's no more complex than C++ (he said, praising it with faint
damnation) and far less gotcha-ridden (in the sense that most of
the 'gotchas' either throw exceptions you can't ignore but can
decide what to do with, are easy and reliable to detect at runtime,
or halt compilation).


				Bear


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20160913/65865600/attachment.sig>