[Cryptography] Use Linux for its security

Ron Garret ron at flownet.com
Sun Oct 2 17:14:21 EDT 2016


On Oct 2, 2016, at 6:07 AM, Florian Weimer <fw at deneb.enyo.de> wrote:

>> One can do more than hope.  AFAIK there is not a single CL
>> implementation where this is not the case.
> 
> Again, then why wasn't it standardized, along with a suitable error
> condition?

Because AI winter happened and there was no funding available to continue the work.

>>> The language rules even say that if a
>>> supposedly-safe function is called from a function compiled without
>>> safety checks, the safety checks in the called functions do have to be
>>> performed (so safety is not modular).
>> 
>> What???  Where does it say that?
> 
> It appears that safe code is only safe if it is evaluated as part of a
> safe call.

That is not an answer.  I asked *where* in the “language rules” it says what you claim it says.

I suspect that you are looking at section 3.5.1.1 in the spec, “Safe and unsafe function calls.”  But note that this is a sub-section of 3.5.1 “Argument mismatch detection”.  This has to do only with making sure that a call has the correct *number* of arguments.  AFAIK the spec says nothing about when array bounds checking must happen (except that it obviously has to happen in the computation of array-in-bounds-p).

> 
>>> The main difference to C is that Common Lisp arrays have an explicit
>>> length, which makes bounds checks easy to implement, either manually
>>> or automatically by the compiler.
>> 
>> What actually matters is that Lisp does not have first-class pointers,
>> so it is *possible* to do automatic bounds checking, which makes code
>> significantly safer.  In C this is not possible.
> 
> Address Sanitizer almost does it for C.

When it comes to security, almost isn’t good enough.  Doing array bounds verification in C requires solving the halting problem:

T x[10];
T y[100];
T* f() { return goldbach_conjecture_is_true() ? &x : &y; }
f()[20];

rg



More information about the cryptography mailing list