Re: [Xen-devel] [PATCH v2 01/13] x86emul/fuzz: add rudimentary limit checking

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 09/10/17 14:26, Jan Beulich wrote:
>
>>>  (NB: put_rep_prefix() is what allows
>>> complete_insn to be reached with rc set to other than X86EMUL_OKAY or
>>> X86EMUL_DONE. See also commit 53f87c03b4 ["x86emul: generalize
>>> exception handling for rep_* hooks"].)
>>>
>>> Add assert()-s for all other (data) access routines, as effective
>>> address generation in the emulator ought to guarantee in-range values.
>>> For them to not trigger, several adjustments to the emulator's address
>>> calculations are needed: While for DstBitBase it is really mandatory,
>>> the specification allows for either behavior for two-part accesses.
>> I can't parse this sentence.  What does the "it" following DstBitBase
>> refer to, and which two things do "either behaviours" refer to?
> See the discussion we've have with George. The replacement text
> now reads
>
> "Add assert()-s for all other (data) access routines, as effective
>  address generation in the emulator ought to guarantee in-range values.
>  For them to not trigger, several adjustments to the emulator's address
>  calculations are needed: While the DstBitBase one is really mandatory,
>  the specification allows for either original or new behavior for two-
>  part accesses. Observed behavior on real hardware, however, is for such
>  accesses to silently wrap at the 2^^32 boundary in other than 64-bit
>  mode, just like they do at the 2^^64 boundary in 64-bit mode, which our
>  code is now being brought in line with. While adding truncate_ea()
>  invocations there, also convert open coded instances of it."

Ok.  Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel