Re: [Xen-devel] [PATCH] x86emul/fuzz: adjust canonicalization in sanitize_input()

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 29.03.19 at 16:42, <George.Dunlap@xxxxxxxxxx> wrote:
>> On Mar 29, 2019, at 3:23 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>>> On 29.03.19 at 16:14, <George.Dunlap@xxxxxxxxxx> wrote:
>>> FAOD:
>>> 1. I don’t oppose this, but
>>> 2. I don’t support it either; however,
>>> 3. I don’t think my Ack is necessary.
>> 
>> Well, preferably I would address your concerns despite 3. So could
>> you clarify what you would suggest instead? Keep things as they
>> are? Drop all canonicalization? I've basically tried to find a middle
>> ground between the two extremes.
> 
> I appreciate that. :-) But the main reason I wrote this was #3: I didn’t 
> want my silence interpreted as a nack.
> 
> I don’t think it will help fuzzing to remove canonicalization of ebp; it may 
> help to have it in.  In fact I’d prefer to CANONICALIZE_MAYBE() more 
> registers.

But canonicalization removes potentially interesting bits from fuzzed
input, which is liable to be relevant if a register is used for other than
a base address in an effective address calculation. As an example,
take BSR: You'd remove the possibility to get results in the range
[48,62]. Or take the XSA-195 case: The memory range covered by
BT{,C,R,S} is dramatically much smaller when the register holding the
bit offset first got canonicalized.

Granted the canonicalization is conditional, so it wouldn't be making it
entirely impossible to get into such a state, but since fuzzing is all
about likelihood, we'd like to avoid reducing our chances of hitting
interesting cases. But as you say ...

> But I don’t think the question is so clear, or so important, that it’s worth 
> having a long discussion about.  Absent some sort of rigorous testing, we’re 
> all just guessing which is better; you & Andy are guessing one way, I’m 
> guessing the other way.  This patch is about as close to middle-ground as 
> there is.

... here, there's indeed a fair bit of guesswork involved.

Thanks in any event for the clarification,
Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel