Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.misc > #81897 > unrolled thread

For those arguing over languages...

Back to article view | Back to comp.os.linux.misc

Contents

  For those arguing over languages... The Natural Philosopher <tnp@invalid.invalid> - 2026-02-10 09:09 +0000
    Re: For those arguing over languages... Richard Kettlewell <invalid@invalid.invalid> - 2026-02-10 13:11 +0000
    Re: For those arguing over languages... Farley Flud <ff@linux.rocks> - 2026-02-10 14:08 +0000
      Re: For those arguing over languages... Marc Haber <mh+usenetspam1118@zugschl.us> - 2026-02-10 15:16 +0100
        Re: For those arguing over languages... Richard Kettlewell <invalid@invalid.invalid> - 2026-02-10 16:19 +0000
          Re: For those arguing over languages... Richard Kettlewell <invalid@invalid.invalid> - 2026-02-10 18:20 +0000
        Re: For those arguing over languages... Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-02-10 11:22 -0500
        Re: For those arguing over languages... John  <john@panix.com> - 2026-02-17 16:23 +0000
          Re: For those arguing over languages... Rich <rich@example.invalid> - 2026-02-19 19:26 +0000
            Re: For those arguing over languages... Richard Kettlewell <invalid@invalid.invalid> - 2026-02-22 09:28 +0000
      Re: For those arguing over languages... John Ames <commodorejohn@gmail.com> - 2026-02-10 08:24 -0800
        Re: For those arguing over languages... Richard Kettlewell <invalid@invalid.invalid> - 2026-02-10 18:16 +0000
    Re: For those arguing over languages... c186282 <c186282@nnada.net> - 2026-02-10 22:34 -0500
      Re: For those arguing over languages... Rich <rich@example.invalid> - 2026-02-11 18:50 +0000
        Re: For those arguing over languages... The Natural Philosopher <tnp@invalid.invalid> - 2026-02-11 19:28 +0000
          Re: For those arguing over languages... Rich <rich@example.invalid> - 2026-02-11 21:27 +0000
            Re: For those arguing over languages... Richard Kettlewell <invalid@invalid.invalid> - 2026-02-12 09:48 +0000
              Re: For those arguing over languages... c186282 <c186282@nnada.net> - 2026-02-12 20:48 -0500
        Re: For those arguing over languages... Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-02-11 16:24 -0500
          Re: For those arguing over languages... Rich <rich@example.invalid> - 2026-02-11 22:45 +0000
            Re: For those arguing over languages... The Natural Philosopher <tnp@invalid.invalid> - 2026-02-12 12:42 +0000
        Re: For those arguing over languages... "Carlos E. R." <robin_listas@es.invalid> - 2026-02-11 23:24 +0100
          Re: For those arguing over languages... Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-11 22:48 +0000
          Re: For those arguing over languages... Rich <rich@example.invalid> - 2026-02-11 22:49 +0000
          Re: For those arguing over languages... Richard Kettlewell <invalid@invalid.invalid> - 2026-02-12 09:55 +0000
            Re: For those arguing over languages... "Carlos E. R." <robin_listas@es.invalid> - 2026-02-12 11:49 +0100
            Re: For those arguing over languages... c186282 <c186282@nnada.net> - 2026-02-12 20:54 -0500
              Re: For those arguing over languages... Rich <rich@example.invalid> - 2026-02-13 03:20 +0000
                Re: For those arguing over languages... c186282 <c186282@nnada.net> - 2026-02-12 23:44 -0500
          Re: For those arguing over languages... The Natural Philosopher <tnp@invalid.invalid> - 2026-02-12 12:38 +0000
            Re: For those arguing over languages... "Carlos E. R." <robin_listas@es.invalid> - 2026-02-12 15:14 +0100
              Re: For those arguing over languages... Rich <rich@example.invalid> - 2026-02-12 17:23 +0000
                Re: For those arguing over languages... "Carlos E. R." <robin_listas@es.invalid> - 2026-02-12 19:52 +0100
                  Re: For those arguing over languages... The Natural Philosopher <tnp@invalid.invalid> - 2026-02-13 10:11 +0000
                    Re: For those arguing over languages... Richard Kettlewell <invalid@invalid.invalid> - 2026-02-13 10:20 +0000
              Re: For those arguing over languages... The Natural Philosopher <tnp@invalid.invalid> - 2026-02-13 10:10 +0000
                Re: For those arguing over languages... c186282 <c186282@nnada.net> - 2026-02-13 19:57 -0500
            Re: For those arguing over languages... c186282 <c186282@nnada.net> - 2026-02-12 20:56 -0500

Page 2 of 2 — ← Prev page 1 [2]

#81981

On 11/02/2026 22:45, Rich wrote:
> Chris Ahlstrom <OFeem1987@teleworm.us> wrote:
>> Rich wrote this post by blinking in Morse code:
>>
>>> c186282 <c186282@nnada.net> wrote:
>>>> On 2/10/26 04:09, The Natural Philosopher wrote:
>>>>> ...more fuel on the fire...
>>>>>
>>>>> https://www.theregister.com/2026/02/09/compilers_undermine_encryption/
>>>>>
>>>>> GCC erases code whose delays obfuscates encryption delays because it
>>>>> doesn't do anything...
>>>>>
>>>>
>>>>    Very interesting ! How 'optimization' sometimes ISN'T.
>>>
>>> Nope.  As Richard Kettlewell has pointed out, what the encryption code
>>> writers want is "constant time execution, regardless of inputs" which
>>> is not a promised output from gcc, no matter the optimization level
>>> chosen.
>>
>> Isn't that something programmer needs to code?
>>
>>      <https://www.chosenplaintext.ca/articles/beginners-guide-constant-time-cryptography.html>
>>
>> ... in asssembler.
> 
> If they wanted to be assured the compiler did not change the intent for
> them, yes.

And given the microcode and caching in the hardware, even that might not 
be enough.

Some kind of device featuring embedded atomic decay might be an 
option.Quantum level effects are to all intents and purpose random at 
the pico level.


-- 
“It is not the truth of Marxism that explains the willingness of 
intellectuals to believe it, but the power that it confers on 
intellectuals, in their attempts to control the world. And since...it is 
futile to reason someone out of a thing that he was not reasoned into, 
we can conclude that Marxism owes its remarkable power to survive every 
criticism to the fact that it is not a truth-directed but a 
power-directed system of thought.”
Sir Roger Scruton

[toc] | [prev] | [next] | [standalone]

#81952

On 2026-02-11 19:50, Rich wrote:
> c186282 <c186282@nnada.net> wrote:
>> On 2/10/26 04:09, The Natural Philosopher wrote:
>>> ...more fuel on the fire...
>>>
>>> https://www.theregister.com/2026/02/09/compilers_undermine_encryption/
>>>
>>> GCC erases code whose delays obfuscates encryption delays because it
>>> doesn't do anything...
>>>
>>
>>    Very interesting ! How 'optimization' sometimes ISN'T.
> 
> Nope.  As Richard Kettlewell has pointed out, what the encryption code
> writers want is "constant time execution, regardless of inputs" which
> is not a promised output from gcc, no matter the optimization level
> chosen.
> 
> The compiler is "properly optimizing" given the meaning of
> "optimization" it uses ("make code run as fast as possible" or "make
> code as small as possible" -- with -Os).  But the compiler was not
> designed to create "constant time execution" code.  The writers were
> expecting a promise the compiler never promised.

In the example posted:

   The user types in a password, which gets checked against
   a database, character by character. Once the first character
   doesn't match, an error message is returned.

...the fault is not of the compiler, but of the programmer. He has to 
examine all characters even if he knows there is no point.


-- 
Cheers,
        Carlos E.R.

[toc] | [prev] | [next] | [standalone]

#81955

On Wed, 11 Feb 2026 23:24:59 +0100, Carlos E. R. wrote:

> In the example posted:
>
>    The user types in a password, which gets checked against a
>    database, character by character. Once the first character
>    doesn't match, an error message is returned.
>
> ...the fault is not of the compiler, but of the programmer. He has
> to examine all characters even if he knows there is no point.

Security is a tricky thing. The term for unexpected information leaks
in unexpected directions is “side-channel attack”.

[toc] | [prev] | [next] | [standalone]

#81956

Carlos E. R. <robin_listas@es.invalid> wrote:
> On 2026-02-11 19:50, Rich wrote:
>> c186282 <c186282@nnada.net> wrote:
>>> On 2/10/26 04:09, The Natural Philosopher wrote:
>>>> ...more fuel on the fire...
>>>>
>>>> https://www.theregister.com/2026/02/09/compilers_undermine_encryption/
>>>>
>>>> GCC erases code whose delays obfuscates encryption delays because it
>>>> doesn't do anything...
>>>>
>>>
>>>    Very interesting ! How 'optimization' sometimes ISN'T.
>> 
>> Nope.  As Richard Kettlewell has pointed out, what the encryption 
>> code writers want is "constant time execution, regardless of inputs" 
>> which is not a promised output from gcc, no matter the optimization 
>> level chosen.
>> 
>> The compiler is "properly optimizing" given the meaning of 
>> "optimization" it uses ("make code run as fast as possible" or "make 
>> code as small as possible" -- with -Os).  But the compiler was not 
>> designed to create "constant time execution" code.  The writers were 
>> expecting a promise the compiler never promised.
> 
> In the example posted:
> 
>   The user types in a password, which gets checked against a 
>   database, character by character.  Once the first character doesn't 
>   match, an error message is returned.
> 
> ...the fault is not of the compiler, but of the programmer. He has to 
> examine all characters even if he knows there is no point.

Richard Kettlewell's example, which was from the talk slides, showed 
that even at -O0 (no optimizations) that the compiler still 
short-circuited (skipped over) the "subsequent checks that have no 
point" once the first one of them failed.

So the C code, read literally, is actually "testing every character, 
even after a failure is noted".  But the compiled code is skipping over 
most of the output CPU intructions once the first "non-equal" character 
is found, creating a timing side-channel.

[toc] | [prev] | [next] | [standalone]

#81974

"Carlos E. R." <robin_listas@es.invalid> writes:
> In the example posted:
>
>   The user types in a password, which gets checked against
>   a database, character by character. Once the first character
>   doesn't match, an error message is returned.
>
> ...the fault is not of the compiler, but of the programmer. He has to
> examine all characters even if he knows there is no point.

Obviously you didn’t read the whole article...

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#81977

On 2026-02-12 10:55, Richard Kettlewell wrote:
> "Carlos E. R." <robin_listas@es.invalid> writes:
>> In the example posted:
>>
>>    The user types in a password, which gets checked against
>>    a database, character by character. Once the first character
>>    doesn't match, an error message is returned.
>>
>> ...the fault is not of the compiler, but of the programmer. He has to
>> examine all characters even if he knows there is no point.
> 
> Obviously you didn’t read the whole article...

I didn't :-)

-- 
Cheers,
        Carlos E.R.

[toc] | [prev] | [next] | [standalone]

#82006

On 2/12/26 04:55, Richard Kettlewell wrote:
> "Carlos E. R." <robin_listas@es.invalid> writes:
>> In the example posted:
>>
>>    The user types in a password, which gets checked against
>>    a database, character by character. Once the first character
>>    doesn't match, an error message is returned.
>>
>> ...the fault is not of the compiler, but of the programmer. He has to
>> examine all characters even if he knows there is no point.
> 
> Obviously you didn’t read the whole article...

   It's "examining" behavior that's the fault :-)

   If you ALWAYS process ALL the characters, and/or try
   to make fake timing so success/fail will use up the
   same amount of CPU time, THEN you're ahead of the game.

   Until they figure out how to detect the fake timing ...

   Olde tyme cracking - brute force or 'clever' - does
   not seem as prevalent as before. There are SO many
   computers, you'd waste far too much time. 'Insider'
   info - either from planted humans or spyware or
   just idiot humans that leave unencrypted databases
   open to the world - seem more 'economical' in most
   cases.

[toc] | [prev] | [next] | [standalone]

#82009

c186282 <c186282@nnada.net> wrote:
> On 2/12/26 04:55, Richard Kettlewell wrote:
>> "Carlos E. R." <robin_listas@es.invalid> writes:
>>> In the example posted:
>>>
>>>    The user types in a password, which gets checked against
>>>    a database, character by character. Once the first character
>>>    doesn't match, an error message is returned.
>>>
>>> ...the fault is not of the compiler, but of the programmer. He has to
>>> examine all characters even if he knows there is no point.
>> 
>> Obviously you didn’t read the whole article...
> 
>   It's "examining" behavior that's the fault :-)
> 
>   If you ALWAYS process ALL the characters, and/or try
>   to make fake timing so success/fail will use up the
>   same amount of CPU time, THEN you're ahead of the game.

Obviously you didn’t read [Richard Kettlewell's posts]

The C code was, if executed literally as written, processing ALL the 
characters.

But in both the optimized state (-O3) and the "do not optimize" state 
(-O0) the GCC output object code was skipping execution of much of the 
object code that needed to be executed for a "constant time" 
comparison.

[toc] | [prev] | [next] | [standalone]

#82010

On 2/12/26 22:20, Rich wrote:
> c186282 <c186282@nnada.net> wrote:
>> On 2/12/26 04:55, Richard Kettlewell wrote:
>>> "Carlos E. R." <robin_listas@es.invalid> writes:
>>>> In the example posted:
>>>>
>>>>     The user types in a password, which gets checked against
>>>>     a database, character by character. Once the first character
>>>>     doesn't match, an error message is returned.
>>>>
>>>> ...the fault is not of the compiler, but of the programmer. He has to
>>>> examine all characters even if he knows there is no point.
>>>
>>> Obviously you didn’t read the whole article...
>>
>>    It's "examining" behavior that's the fault :-)
>>
>>    If you ALWAYS process ALL the characters, and/or try
>>    to make fake timing so success/fail will use up the
>>    same amount of CPU time, THEN you're ahead of the game.
> 
> Obviously you didn’t read [Richard Kettlewell's posts]

   I was reading the Original Source that explained
   the attack method.

> The C code was, if executed literally as written, processing ALL the
> characters.
> 
> But in both the optimized state (-O3) and the "do not optimize" state
> (-O0) the GCC output object code was skipping execution of much of the
> object code that needed to be executed for a "constant time"
> comparison.

   As said before ... 'too smart for its own good' in
   this instance.

   Now lots of people need to update lots of code to
   obfuscate this issue. Expensive.

   Yea yea, we all tend to use the 'high-optimization'
   flags by default ... it's a psych thing. However in
   this case someone has figured out how to use that
   against us all. Either a lot of code had to be
   re-compiled in less-optimized mode or the algos
   have to be changed a bit. The former fix is easier.

[toc] | [prev] | [next] | [standalone]

#81980

On 11/02/2026 22:24, Carlos E. R. wrote:
> On 2026-02-11 19:50, Rich wrote:
>> c186282 <c186282@nnada.net> wrote:
>>> On 2/10/26 04:09, The Natural Philosopher wrote:
>>>> ...more fuel on the fire...
>>>>
>>>> https://www.theregister.com/2026/02/09/compilers_undermine_encryption/
>>>>
>>>> GCC erases code whose delays obfuscates encryption delays because it
>>>> doesn't do anything...
>>>>
>>>
>>>    Very interesting ! How 'optimization' sometimes ISN'T.
>>
>> Nope.  As Richard Kettlewell has pointed out, what the encryption code
>> writers want is "constant time execution, regardless of inputs" which
>> is not a promised output from gcc, no matter the optimization level
>> chosen.
>>
>> The compiler is "properly optimizing" given the meaning of
>> "optimization" it uses ("make code run as fast as possible" or "make
>> code as small as possible" -- with -Os).  But the compiler was not
>> designed to create "constant time execution" code.  The writers were
>> expecting a promise the compiler never promised.
> 
> In the example posted:
> 
>    The user types in a password, which gets checked against
>    a database, character by character. Once the first character
>    doesn't match, an error message is returned.
> 
> ...the fault is not of the compiler, but of the programmer. He has to 
> examine all characters even if he knows there is no point.
> 
> 
I think the point is that the compiler knows that isn't necessary, and 
doesnt bother.

-- 
“It is not the truth of Marxism that explains the willingness of 
intellectuals to believe it, but the power that it confers on 
intellectuals, in their attempts to control the world. And since...it is 
futile to reason someone out of a thing that he was not reasoned into, 
we can conclude that Marxism owes its remarkable power to survive every 
criticism to the fact that it is not a truth-directed but a 
power-directed system of thought.”
Sir Roger Scruton

[toc] | [prev] | [next] | [standalone]

#81985

On 2026-02-12 13:38, The Natural Philosopher wrote:
> On 11/02/2026 22:24, Carlos E. R. wrote:
>> On 2026-02-11 19:50, Rich wrote:
>>> c186282 <c186282@nnada.net> wrote:
>>>> On 2/10/26 04:09, The Natural Philosopher wrote:
>>>>> ...more fuel on the fire...
>>>>>
>>>>> https://www.theregister.com/2026/02/09/compilers_undermine_encryption/
>>>>>
>>>>> GCC erases code whose delays obfuscates encryption delays because it
>>>>> doesn't do anything...
>>>>>
>>>>
>>>>    Very interesting ! How 'optimization' sometimes ISN'T.
>>>
>>> Nope.  As Richard Kettlewell has pointed out, what the encryption code
>>> writers want is "constant time execution, regardless of inputs" which
>>> is not a promised output from gcc, no matter the optimization level
>>> chosen.
>>>
>>> The compiler is "properly optimizing" given the meaning of
>>> "optimization" it uses ("make code run as fast as possible" or "make
>>> code as small as possible" -- with -Os).  But the compiler was not
>>> designed to create "constant time execution" code.  The writers were
>>> expecting a promise the compiler never promised.
>>
>> In the example posted:
>>
>>    The user types in a password, which gets checked against
>>    a database, character by character. Once the first character
>>    doesn't match, an error message is returned.
>>
>> ...the fault is not of the compiler, but of the programmer. He has to 
>> examine all characters even if he knows there is no point.
>>
>>
> I think the point is that the compiler knows that isn't necessary, and 
> doesnt bother.
> 

Then don't optimize. Optimization has always been somewhat problematic. 
Sometimes it introduced bugs that could not be debugged, because 
debugging altered the code, possibly removing the optimizations.

-- 
Cheers,
        Carlos E.R.

[toc] | [prev] | [next] | [standalone]

#81987

Carlos E. R. <robin_listas@es.invalid> wrote:
> On 2026-02-12 13:38, The Natural Philosopher wrote:
>> On 11/02/2026 22:24, Carlos E. R. wrote:
>>> On 2026-02-11 19:50, Rich wrote:
>>>> c186282 <c186282@nnada.net> wrote:
>>>>> On 2/10/26 04:09, The Natural Philosopher wrote:
>>>>>> ...more fuel on the fire...
>>>>>>
>>>>>> https://www.theregister.com/2026/02/09/compilers_undermine_encryption/
>>>>>>
>>>>>> GCC erases code whose delays obfuscates encryption delays because it
>>>>>> doesn't do anything...
>>>>>>
>>>>>
>>>>>    Very interesting ! How 'optimization' sometimes ISN'T.
>>>>
>>>> Nope.  As Richard Kettlewell has pointed out, what the encryption code
>>>> writers want is "constant time execution, regardless of inputs" which
>>>> is not a promised output from gcc, no matter the optimization level
>>>> chosen.
>>>>
>>>> The compiler is "properly optimizing" given the meaning of
>>>> "optimization" it uses ("make code run as fast as possible" or "make
>>>> code as small as possible" -- with -Os).  But the compiler was not
>>>> designed to create "constant time execution" code.  The writers were
>>>> expecting a promise the compiler never promised.
>>>
>>> In the example posted:
>>>
>>>    The user types in a password, which gets checked against
>>>    a database, character by character. Once the first character
>>>    doesn't match, an error message is returned.
>>>
>>> ...the fault is not of the compiler, but of the programmer. He has to 
>>> examine all characters even if he knows there is no point.
>>>
>>>
>> I think the point is that the compiler knows that isn't necessary, and 
>> doesnt bother.
>> 
> 
> Then don't optimize. Optimization has always been somewhat problematic. 
> Sometimes it introduced bugs that could not be debugged, because 
> debugging altered the code, possibly removing the optimizations.

It wasn't the optimizer causing the "skipping" of the rest of the 
checks.  It was a byproduct of boolean short-circuiting of boolean 
expressions.  Most languages only evaluate just enough of a complex 
boolean expression to reach a true or false indication, then skip the 
rest of the expression (yes, this is an 'optimization', but not by the 
code optimizer but the language specification itself).

The skipping of the remaining character checks in the example posted 
here was due to this boolean short-circuit behavior.  Once the first 
'false' arrived for the first incorrect character, the compiled code 
skipped over evaluating the boolean expression for subsequent 
characters.  So -O0 (no optimizations) or -O3 (full optimizations) made 
no difference, portions of the 'constant time execution' were skipped, 
opening a timing side channel attack.

[toc] | [prev] | [next] | [standalone]

#81989

On 2026-02-12 18:23, Rich wrote:
> Carlos E. R. <robin_listas@es.invalid> wrote:
>> On 2026-02-12 13:38, The Natural Philosopher wrote:
>>> On 11/02/2026 22:24, Carlos E. R. wrote:
>>>> On 2026-02-11 19:50, Rich wrote:
>>>>> c186282 <c186282@nnada.net> wrote:
>>>>>> On 2/10/26 04:09, The Natural Philosopher wrote:
>>>>>>> ...more fuel on the fire...
>>>>>>>



>>> I think the point is that the compiler knows that isn't necessary, and
>>> doesnt bother.
>>>
>>
>> Then don't optimize. Optimization has always been somewhat problematic.
>> Sometimes it introduced bugs that could not be debugged, because
>> debugging altered the code, possibly removing the optimizations.
> 
> It wasn't the optimizer causing the "skipping" of the rest of the
> checks.  It was a byproduct of boolean short-circuiting of boolean
> expressions.  Most languages only evaluate just enough of a complex
> boolean expression to reach a true or false indication, then skip the
> rest of the expression (yes, this is an 'optimization', but not by the
> code optimizer but the language specification itself).
> 
> The skipping of the remaining character checks in the example posted
> here was due to this boolean short-circuit behavior.  Once the first
> 'false' arrived for the first incorrect character, the compiled code
> skipped over evaluating the boolean expression for subsequent
> characters.  So -O0 (no optimizations) or -O3 (full optimizations) made
> no difference, portions of the 'constant time execution' were skipped,
> opening a timing side channel attack.

Ah, yes, I remember that now. Can play havoc when one of the expression 
is actually a function and the later code relies on the prior execution 
of that code.



-- 
Cheers,
        Carlos E.R.

[toc] | [prev] | [next] | [standalone]

#82014

On 12/02/2026 18:52, Carlos E. R. wrote:
> On 2026-02-12 18:23, Rich wrote:
>> Carlos E. R. <robin_listas@es.invalid> wrote:
>>> On 2026-02-12 13:38, The Natural Philosopher wrote:
>>>> On 11/02/2026 22:24, Carlos E. R. wrote:
>>>>> On 2026-02-11 19:50, Rich wrote:
>>>>>> c186282 <c186282@nnada.net> wrote:
>>>>>>> On 2/10/26 04:09, The Natural Philosopher wrote:
>>>>>>>> ...more fuel on the fire...
>>>>>>>>
> 
> 
> 
>>>> I think the point is that the compiler knows that isn't necessary, and
>>>> doesnt bother.
>>>>
>>>
>>> Then don't optimize. Optimization has always been somewhat problematic.
>>> Sometimes it introduced bugs that could not be debugged, because
>>> debugging altered the code, possibly removing the optimizations.
>>
>> It wasn't the optimizer causing the "skipping" of the rest of the
>> checks.  It was a byproduct of boolean short-circuiting of boolean
>> expressions.  Most languages only evaluate just enough of a complex
>> boolean expression to reach a true or false indication, then skip the
>> rest of the expression (yes, this is an 'optimization', but not by the
>> code optimizer but the language specification itself).
>>
>> The skipping of the remaining character checks in the example posted
>> here was due to this boolean short-circuit behavior.  Once the first
>> 'false' arrived for the first incorrect character, the compiled code
>> skipped over evaluating the boolean expression for subsequent
>> characters.  So -O0 (no optimizations) or -O3 (full optimizations) made
>> no difference, portions of the 'constant time execution' were skipped,
>> opening a timing side channel attack.
> 
> Ah, yes, I remember that now. Can play havoc when one of the expression 
> is actually a function and the later code relies on the prior execution 
> of that code.
> 
the keyword 'volatile' helps in this case

> 
> 

-- 
Truth welcomes investigation because truth knows investigation will lead 
to converts. It is deception that uses all the other techniques.

[toc] | [prev] | [next] | [standalone]

#82016

The Natural Philosopher <tnp@invalid.invalid> writes:

> On 12/02/2026 18:52, Carlos E. R. wrote:
>> On 2026-02-12 18:23, Rich wrote:
>>> Carlos E. R. <robin_listas@es.invalid> wrote:
>>>> On 2026-02-12 13:38, The Natural Philosopher wrote:
>>>>> On 11/02/2026 22:24, Carlos E. R. wrote:
>>>>>> On 2026-02-11 19:50, Rich wrote:
>>>>>>> c186282 <c186282@nnada.net> wrote:
>>>>>>>> On 2/10/26 04:09, The Natural Philosopher wrote:
>>>>>>>>> ...more fuel on the fire...
>>>>>>>>>
>> 
>>>>> I think the point is that the compiler knows that isn't necessary, and
>>>>> doesnt bother.
>>>>>
>>>>
>>>> Then don't optimize. Optimization has always been somewhat problematic.
>>>> Sometimes it introduced bugs that could not be debugged, because
>>>> debugging altered the code, possibly removing the optimizations.
>>>
>>> It wasn't the optimizer causing the "skipping" of the rest of the
>>> checks.  It was a byproduct of boolean short-circuiting of boolean
>>> expressions.  Most languages only evaluate just enough of a complex
>>> boolean expression to reach a true or false indication, then skip the
>>> rest of the expression (yes, this is an 'optimization', but not by the
>>> code optimizer but the language specification itself).
>>>
>>> The skipping of the remaining character checks in the example posted
>>> here was due to this boolean short-circuit behavior.  Once the first
>>> 'false' arrived for the first incorrect character, the compiled code
>>> skipped over evaluating the boolean expression for subsequent
>>> characters.  So -O0 (no optimizations) or -O3 (full optimizations) made
>>> no difference, portions of the 'constant time execution' were skipped,
>>> opening a timing side channel attack.
>>
>> Ah, yes, I remember that now. Can play havoc when one of the
>> expression is actually a function and the later code relies on the
>> prior execution of that code.
> 
> the keyword 'volatile' helps in this case

No. volatile does not affect the execution of the short-circuiting
boolean operators. If the left-hand side of && is false, or the left
hand side of || is true, then the right-hand is not executed.

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#82013

On 12/02/2026 14:14, Carlos E. R. wrote:
> On 2026-02-12 13:38, The Natural Philosopher wrote:
>> On 11/02/2026 22:24, Carlos E. R. wrote:
>>> On 2026-02-11 19:50, Rich wrote:
>>>> c186282 <c186282@nnada.net> wrote:
>>>>> On 2/10/26 04:09, The Natural Philosopher wrote:
>>>>>> ...more fuel on the fire...
>>>>>>
>>>>>> https://www.theregister.com/2026/02/09/compilers_undermine_encryption/
>>>>>>
>>>>>> GCC erases code whose delays obfuscates encryption delays because it
>>>>>> doesn't do anything...
>>>>>>
>>>>>
>>>>>    Very interesting ! How 'optimization' sometimes ISN'T.
>>>>
>>>> Nope.  As Richard Kettlewell has pointed out, what the encryption code
>>>> writers want is "constant time execution, regardless of inputs" which
>>>> is not a promised output from gcc, no matter the optimization level
>>>> chosen.
>>>>
>>>> The compiler is "properly optimizing" given the meaning of
>>>> "optimization" it uses ("make code run as fast as possible" or "make
>>>> code as small as possible" -- with -Os).  But the compiler was not
>>>> designed to create "constant time execution" code.  The writers were
>>>> expecting a promise the compiler never promised.
>>>
>>> In the example posted:
>>>
>>>    The user types in a password, which gets checked against
>>>    a database, character by character. Once the first character
>>>    doesn't match, an error message is returned.
>>>
>>> ...the fault is not of the compiler, but of the programmer. He has to 
>>> examine all characters even if he knows there is no point.
>>>
>>>
>> I think the point is that the compiler knows that isn't necessary, and 
>> doesnt bother.
>>
> 
> Then don't optimize. Optimization has always been somewhat problematic. 
> Sometimes it introduced bugs that could not be debugged, because 
> debugging altered the code, possibly removing the optimizations.
> 

I think you are on a hiding to nothing here.  No high level language 
guarantees any particular load of assembler, and no particular load of 
assembler guarantees an exact timing these days.
  We have moved on from the Z80....

-- 
Truth welcomes investigation because truth knows investigation will lead 
to converts. It is deception that uses all the other techniques.

[toc] | [prev] | [next] | [standalone]

#82025

On 2/13/26 05:10, The Natural Philosopher wrote:
> On 12/02/2026 14:14, Carlos E. R. wrote:
>> On 2026-02-12 13:38, The Natural Philosopher wrote:
>>> On 11/02/2026 22:24, Carlos E. R. wrote:
>>>> On 2026-02-11 19:50, Rich wrote:
>>>>> c186282 <c186282@nnada.net> wrote:
>>>>>> On 2/10/26 04:09, The Natural Philosopher wrote:
>>>>>>> ...more fuel on the fire...
>>>>>>>
>>>>>>> https://www.theregister.com/2026/02/09/ 
>>>>>>> compilers_undermine_encryption/
>>>>>>>
>>>>>>> GCC erases code whose delays obfuscates encryption delays because it
>>>>>>> doesn't do anything...
>>>>>>>
>>>>>>
>>>>>>    Very interesting ! How 'optimization' sometimes ISN'T.
>>>>>
>>>>> Nope.  As Richard Kettlewell has pointed out, what the encryption code
>>>>> writers want is "constant time execution, regardless of inputs" which
>>>>> is not a promised output from gcc, no matter the optimization level
>>>>> chosen.
>>>>>
>>>>> The compiler is "properly optimizing" given the meaning of
>>>>> "optimization" it uses ("make code run as fast as possible" or "make
>>>>> code as small as possible" -- with -Os).  But the compiler was not
>>>>> designed to create "constant time execution" code.  The writers were
>>>>> expecting a promise the compiler never promised.
>>>>
>>>> In the example posted:
>>>>
>>>>    The user types in a password, which gets checked against
>>>>    a database, character by character. Once the first character
>>>>    doesn't match, an error message is returned.
>>>>
>>>> ...the fault is not of the compiler, but of the programmer. He has 
>>>> to examine all characters even if he knows there is no point.
>>>>
>>>>
>>> I think the point is that the compiler knows that isn't necessary, 
>>> and doesnt bother.
>>>
>>
>> Then don't optimize. Optimization has always been somewhat 
>> problematic. Sometimes it introduced bugs that could not be debugged, 
>> because debugging altered the code, possibly removing the optimizations.
>>
> 
> I think you are on a hiding to nothing here.  No high level language 
> guarantees any particular load of assembler, and no particular load of 
> assembler guarantees an exact timing these days.
>   We have moved on from the Z80....


   Hmmmm ... how about a Z80 equiv in a thumb-drive
   casing ? You can send it stuff, it can send stuff
   back, nice single-CPU single-thread performance :-)

   When getting a PW you actually have the Z80 do it
   and confirm accuracy.

   For desktops, a PCI card with similar setup.

   You can EMULATE a Z80 or 6502 and a few others
   easily enough with Linux utils, but they're
   still actually a Linux x86/64 pgm and may be
   subject to the same vulnerabilities as the
   article mentioned.

   For on-order commercial purposes, there might be a
   market for "<oldCPU>-on-a stick" ...

   I'd like a 6809 and the CoCo ver of OS-9  :-)

   (don't think MicroWare actually makes a 6809
    version of OS-9 anymore alas - there ARE a
    few ARM versions however)

[toc] | [prev] | [next] | [standalone]

#82007

On 2/12/26 07:38, The Natural Philosopher wrote:
> On 11/02/2026 22:24, Carlos E. R. wrote:
>> On 2026-02-11 19:50, Rich wrote:
>>> c186282 <c186282@nnada.net> wrote:
>>>> On 2/10/26 04:09, The Natural Philosopher wrote:
>>>>> ...more fuel on the fire...
>>>>>
>>>>> https://www.theregister.com/2026/02/09/compilers_undermine_encryption/
>>>>>
>>>>> GCC erases code whose delays obfuscates encryption delays because it
>>>>> doesn't do anything...
>>>>>
>>>>
>>>>    Very interesting ! How 'optimization' sometimes ISN'T.
>>>
>>> Nope.  As Richard Kettlewell has pointed out, what the encryption code
>>> writers want is "constant time execution, regardless of inputs" which
>>> is not a promised output from gcc, no matter the optimization level
>>> chosen.
>>>
>>> The compiler is "properly optimizing" given the meaning of
>>> "optimization" it uses ("make code run as fast as possible" or "make
>>> code as small as possible" -- with -Os).  But the compiler was not
>>> designed to create "constant time execution" code.  The writers were
>>> expecting a promise the compiler never promised.
>>
>> In the example posted:
>>
>>    The user types in a password, which gets checked against
>>    a database, character by character. Once the first character
>>    doesn't match, an error message is returned.
>>
>> ...the fault is not of the compiler, but of the programmer. He has to 
>> examine all characters even if he knows there is no point.
>>
>>
> I think the point is that the compiler knows that isn't necessary, and 
> doesnt bother.


   Yep, too smart for its own good :-)

   This behavior will have to be sabotaged - either
   by messing with the compiler or messing with the
   algo used.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.os.linux.misc

csiph-web