Add mem.timingSafeEql() for constant-time array comparison

[jedisct1]

Add mem.timingSafeEql() for constant-time array comparison.

• Assembly code is generated on x86_64. SSE2-only, so compatible with a baseline CPU target).
• On other targets, best efforts are made to avoid compiler optimizations by avoiding inlining and using empty assembly blocks.

More assembly implementations are planned to be added shortly after (starting with arm & aarch64).

[komuw]

also relevant: #1776

[kubkon]

The Windows fail seems mysterious.

[jedisct1]

@andrewrk Do you have any idea about what could explain the failure with MSVC?

This happens even if the tests are removed, and the functions are not called anywhere.

[kubkon]

@jedisct1 when I find some time, I'll spin up your changes on Windows locally and see if I can help out with debugging the issue with the CI.

[jedisct1]

Thank you @kubkon !

[jedisct1]

Similar issue on master after 72f4cdb ?

https://dev.azure.com/ziglang/zig/_build/results?buildId=9258&view=logs&j=d1f84438-6a35-5012-cb7c-bd94b3e3f1c5&t=05ce345c-2d32-59f4-e4b3-8efcfe85154b

[kubkon]

Similar issue on master after 72f4cdb ?

https://dev.azure.com/ziglang/zig/_build/results?buildId=9258&view=logs&j=d1f84438-6a35-5012-cb7c-bd94b3e3f1c5&t=05ce345c-2d32-59f4-e4b3-8efcfe85154b

Actually, this time the error seems more concrete: https://dev.azure.com/ziglang/zig/_build/results?buildId=9272&view=logs&j=d1f84438-6a35-5012-cb7c-bd94b3e3f1c5&t=05ce345c-2d32-59f4-e4b3-8efcfe85154b&l=18780

[kubkon]

Darn, can't seem to be able to replicate the fault locally...

[jedisct1]

Fun :(

[LemonBoy]

Given that the functions are meant to compare small (< 100 bytes) I'd go for something simpler. I definitely agree on implementing the core logic with an inline asm block, but I see no need to take out the big guns, let's write a single function that uses a siiiimple byte-by-byte loop that's portable, simpler to write, read and audit and serves its main purpose. I'd also change the != 0 to use some bit-level trickery (eg. or all the 8 result bits together) and avoid a conditional branch there (using cmov is cheating?) to make the whole comparison as robust as possible wrt LLVM influence.

This paper proposes and interesting statistical method to check for info leakages, it may be interesting to run the resulting function trough the same evaluation process and see how well it fares.

[andrewrk]

I'd like to explore #1776 before resorting to this. The approach in this patch - which I recognize is the industry-accepted standard in all other programming languages - throws away all the language semantics, and basically amounts to giving up and coding in assembly. It moves into userland the main thing that a compiler is supposed to do: converting language semantics into code generation to many different architectures, keeping up with new CPUs and features, and catching bugs via semantic analysis. It thwarts zig's comptime feature- the ability to call the same functions both at comptime and runtime. And yet it's still tricky to use correctly, landmines are present at the seams of the APIs here.

Let's spend energy towards #1776 before spending it on this kind of thing. I want to climb the big mountain, not the small hill next to it. We can come back to this if it turns out #1776 won't work out. But I don't want to green light this as part of the standard library until that possibility is exhausted.

Here's a start: at which callsites did you want to use this function? Let's pick one example, and see if we can start working on #1776 and do a proof of concept with it.

I hope you can give this a chance. I think this could potentially not work out, but on the other hand, this could end up being a big deal and make a huge paradigm shift in the field of software security. I think it's worth a shot.