Re: [Valgrind-developers] Proposed valgrind division patch

[D. J. B. <aut...@bo...>]

Mark Wielaard writes:
> That is a clever trick. Some of the references mention it needs a
> patched valgrind to introduce poison/unposion functions. But this looks
> like just convenience. As you say, you could just directly introduce
> VALGRIND_MAKE_MEM_UNDEFINED markers in the code. Are these patches
> still needed/used?

I presume that https://github.com/agl/ctgrind/blob/master/valgrind.patch
was just the result of most people back then (2010) not being aware of
VALGRIND_MAKE_MEM_UNDEFINED (2006). Definitely no need for that patch.
The division story is different, obviously.

> The environment variable trick is nice. I wonder if we can generalize
> that.

Could sweep through environ and turn each VALGRIND_BESTEFFORT_X_Y=v into
mc_process_cmd_line_options("--x-y=v"). A quick CLO skim suggests that
False results are generally safe to ignore, but maybe there are (or will
be!) exceptions to that; clearly the code was written with the mindset
that False will exit (often with an error message). Safer would be to
restrict to CLOM, as in VALGRIND_CLO_CHANGE. Not many lines of code in
any case.

> Urgh. Looks like there is a huge list of instructions that might have
> timing issues depending on their input.

Yup, handling all that is a big project, but at least there's a clear
target in the end. I agree that someone tackling this will probably run
into occasions when an Intel instruction and an ARM instruction differ in
whether they're guaranteed to be constant-time but still turn into the
same Iop, so I'd expect a patch to introduce a new Iop for each such
case, which doesn't look too painful as long as it isn't too frequent.
Most timing variations are predictable from the basics of how CPUs are
built; CPU differences come from, e.g., one CPU manufacturer deciding to
invest very little hardware area in a multiplier, at which point there's
a noticeable speedup from having the multiplier exit early on small
inputs, while another CPU manufacturer builds a faster multiplier that
doesn't benefit from timing variations.

---D. J. Bernstein (speaking for myself)