On 2023-08-16 11:06, Alexander Monakov wrote:
No I understood the distinction you're trying to make, I just wanted to point
out that the effect isn't all that different. The intent of the wording is
not to prescribe a solution, but to describe what the compiler cannot do and
hence, users must find a way to do this. I think we have a consensus on this
part of the wording though because we're not really responsible for the
prescription here and I'm happy with just asking users to sandbox.
Nice!
I suppose it's kinda like saying "don't try this at home". You know many will
and some will break their leg while others will come out of it feeling
invincible. Our job is to let them know that they will likely break their leg
:)
Continuing this analogy, I was protesting against doing our job by telling
users "when trying this at home, make sure to wear vibranium shielding"
while knowing for sure that nobody can, in fact, obtain said shielding,
making our statement not helpful and rather tautological.
:)
How about this in the last section titled "Security features implemented in
GCC", since that's where we also deal with security hardening.
Similarly, GCC may transform code in a way that the correctness of
the expressed algorithm is preserved but supplementary properties
that are observable only outside the program or through a
vulnerability in the program, may not be preserved. This is not a
security issue in GCC and in such cases, the vulnerability that
caused exposure of the supplementary properties must be fixed.
Yeah, indicating scenarios that fall outside of intended guarantees should
be helpful. I feel the exact text quoted above will be hard to decipher
without knowing the discussion that led to it. Some sort of supplementary
section with examples might help there.
Ah, so I had started out by listing examples but dropped them before
emailing. How about:
Similarly, GCC may transform code in a way that the correctness of
the expressed algorithm is preserved but supplementary properties
that are observable only outside the program or through a
vulnerability in the program, may not be preserved. Examples
of such supplementary properties could be the state of memory after
it is no longer in use, performance and timing characteristics of a
program, state of the CPU cache, etc. Such issues are not security
vulnerabilities in GCC and in such cases, the vulnerability that
caused exposure of the supplementary properties must be fixed.
In any case, I hope further discussion, clarification and wordsmithing
goes productively for you both here on the list and during the Cauldron.
Thanks!
Sid
