[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