This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Signed int overflow behaviour in the security context

Robert Dewar wrote:
>> I don't see why that demand would prevent register allocation.  Maybe
>> you can explain that to me.
> Probably the best thing is to refer you to a good compiler book, such
> as the dragon book. It really is necessary to understand compiler
> technology to understand this kind of thing, you can't understand
> it just from a user point of view.

Believe me, I understand a thing or two about compilers, I've been
maintaining one for ten years now.  It's just not a C compiler, so some
of the subtleties of specific aspects of that simply escape me.  That's
why I ask for an example.  You can expect me to understand any technical

The argument I'm seeing so far is one that claims that uninitialized
memory allocated are more likely to contain zero than a
register-allocated variable.  I don't think that's particularly strong,
or relevant to my demand.

>> My point essentially is that it's not a good idea to have "x-y" mean
>> something different in different parts of the code.  That's just too
>> hard for the user to understand and deal with properly.
> if x or y is undefined, it fdoes not mean something different in
> different parts, it means undefined in both cases.

I'm exactly talking about the semantics of "undefined" here.  It would
be immensely reassuring if a compiler would at least interpret this as
"unspecified, but consistent".  Even better would be a defined and
documented semantics for everything left undefined by the standard.

I once talked to one of the authors of the C standard about the security
dangers of writing software in C.  He rightfully pointed out that the
language standard leaves the result of an out of bounds array access
undefined, so a compiler is free to implement automated bounds checks.

>> Oh, the last formally security-critical application I've been working on
>> (FIPS 140-2 certification pending) *was* compiled with -O2, because the
>> resources on the embedded target device were scarce.
> Very unusual, because it's so much harder to establish source-object
> traceability.

But unavoidable, given the constraints.  I have no insight into the
complete audit process they do, but I bet it includes binary audits.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]