Extend bit-flip detection with heuristics to calculate confidence levels
afranchuk opened this issue · comments
There should be a confidence level provided for each possible bit-flip address provided. The possible bit flips should be exposed in JSON as an array of objects, where each object has an address and confidence field.
Heuristics may include:
- Whether the bit-flipped address caused a non-canonical address (very high confidence)
- Whether the corrected address is near many other register values
- Whether the corrected address is null
It's unclear whether it would be more useful to decide the confidence levels we want to impart, or whether we want to provide flags of these heuristic conditions and allow users to calculate confidence levels with their own weighting.
I thought of another thing that might be useful: when dealing with NULL-pointer-with-one-bit-flipped issues we might look for the contents of other registers. If at least one contains the posion pattern (0xe5e5e5e5e5e5e5e5) lower our confidence as it might be a UAF in disguise.
Do you have thoughts on whether we should expose these detection flags versus calculating/showing a confidence ourselves? Or maybe we can provide both, which also provides some explanation of the confidence number to the user.
Good question, it would probably be better to store them as flags because then we can index them and aggregate them in crashes. That gives a more complete picture to whoever is doing the triage (e.g. "this crash has a significant number of potential UAFs" or "all the machines have the same CPU which is known to have a bug").
Is that poison pattern something specific to the Fx allocator?
Yes, though I remember there was a specific reason why it was chosen so maybe others use it too. Mike Hommey or Paul Bone are likely to know about that.
Okay. From searching around I see that xmalloc uses 0xa5 (repeated). I'm not sure whether that should be configurable or whether we should just look for a handful of known poison patterns (it's probably easier to just look for known ones).
Yes, though I remember there was a specific reason why it was chosen so maybe others use it too. Mike Hommey or Paul Bone are likely to know about that.
At some point in history the bounds of the chosen memory region being used was included as an annotation, but it looks like @gabrielesvelto removed the last traces of that a few years ago: https://hg.mozilla.org/mozilla-central/rev/5a56e755615d6c8cb19030cb55064d06cd87633f#l3.78
Okay. From searching around I see that xmalloc uses 0xa5 (repeated). I'm not sure whether that should be configurable or whether we should just look for a handful of known poison patterns (it's probably easier to just look for known ones).
@gabrielesvelto where does 0xe5e5e5e5e5e5e5e5 come from? (more specifically; I can't find the code in searchfox).
I vaguely remembered that it was chosen because it didn't represent any valid userspace instructions for x86 and indeed that's the case, see bug 1044077. OT: it would be interesting to see if this also applies to 32- and 64-bit ARM.