From: George Dunlap <george.dunlap@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
Wei Liu <wei.liu2@citrix.com>,
xen-devel@lists.xenproject.org,
Ian Jackson <ian.jackson@citrix.com>
Subject: Re: [PATCH v4 11/12] fuzz/x86_emulate: Set and fuzz more CPU state
Date: Fri, 13 Oct 2017 11:39:37 +0100 [thread overview]
Message-ID: <123fa10c-068d-60fe-65c5-9c059c10029d@citrix.com> (raw)
In-Reply-To: <59DFA8B20200007800185B9C@prv-mh.provo.novell.com>
On 10/12/2017 04:38 PM, Jan Beulich wrote:
>>>> On 11.10.17 at 19:52, <george.dunlap@citrix.com> wrote:
>> The Intel manual claims that, "If [certain CPUID bits] are set, the
>> processor deprecates FCS and FDS, and the field is saved as 0000h";
>> but experimentally it would be more accurate to say, "the field is
>> occasionally saved as 0000h". This causes the --rerun checking to
>> trip non-deterministically. Sanitize them to zero.
>
> I think we've meanwhile settled on the field being saved as zero
> being a side effect of using 32-bit fxsave plus a context switch in
> the OS kernel.
>
>> @@ -594,6 +595,75 @@ static const struct x86_emulate_ops all_fuzzer_ops = {
>> };
>> #undef SET
>>
>> +/*
>> + * This funciton will read or write fxsave to the fpu. When writing,
>> + * it 'sanitizes' the state: It will mask off the appropriate bits in
>> + * the mxcsr, 'restore' the state to the fpu, then 'save' it again so
>> + * that the data in fxsave reflects what's actually in the FPU.
>> + *
>> + * TODO: Extend state beyond just FPU (ymm registers, &c)
>> + */
>> +static void _set_fpu_state(char *fxsave, bool write)
>> +{
>> + if ( cpu_has_fxsr )
>> + {
>> + static union __attribute__((__aligned__(16))) {
>> + char x[512];
>> + struct {
>> + uint16_t cw, sw;
>> + uint8_t tw, _rsvd1;
>> + uint16_t op;
>> + uint32_t ip;
>> + uint16_t cs, _rsvd2;
>> + uint32_t dp;
>> + uint16_t ds, _rsvd3;
>> + uint32_t mxcsr;
>> + uint32_t mxcsr_mask;
>> + /* ... */
>> + };
>> + } *fxs;
>> +
>> + fxs = (typeof(fxs))fxsave;
>> +
>> + if ( write )
>> + {
>> + /*
>> + * Clear reserved bits to make sure we don't get any
>> + * exceptions
>> + */
>> + fxs->mxcsr &= mxcsr_mask;
>> +
>> + /*
>> + * The Intel manual says that on newer models CS/DS are
>> + * deprecated and that these fields "are saved as 0000h".
>> + * Experimentally, however, at least on my test box,
>> + * whether this saved as 0000h or as the previously
>> + * written value is random; meaning that when run with
>> + * --rerun, we occasionally detect a "state mismatch" in these
>> + * bytes. Instead, simply sanitize them to zero.
>> + *
>> + * TODO Check CPUID as specified in the manual before
>> + * clearing
>> + */
>> + fxs->cs = fxs->ds = 0;
>
> Shouldn't be needed anymore with ...
>
>> + asm volatile( "fxrstor %0" :: "m" (*fxs) );
>
> rex64 (or fxrstor64) used here and ...
>
>> + }
>> +
>> + asm volatile( "fxsave %0" : "=m" (*fxs) );
>
> ... here (of course the alternative here then is fxsave64).
>
> Also please add blanks before the opening parentheses.
>
>> @@ -732,6 +806,18 @@ static void setup_state(struct x86_emulate_ctxt *ctxt)
>> printf("Setting cpu_user_regs offset %x\n", offset);
>> continue;
>> }
>> + offset -= sizeof(struct cpu_user_regs);
>> +
>> + /* Fuzz fxsave state */
>> + if ( offset < sizeof(s->fxsave) / 4 )
>
> You've switched to sizeof() here but ...
>
>> + {
>> + /* 32-bit size is arbitrary; see comment above */
>> + if ( !input_read(s, s->fxsave + (offset * 4), 4) )
>> + return;
>> + printf("Setting fxsave offset %x\n", offset * 4);
>> + continue;
>> + }
>> + offset -= 128;
>
> ... not here.
>
>> @@ -1008,6 +1098,16 @@ static void compare_states(struct fuzz_state state[2])
>> if ( memcmp(&state[0].ops, &state[1].ops, sizeof(state[0].ops)) )
>> printf("ops differ!\n");
>>
>> + if ( memcmp(&state[0].fxsave, &state[1].fxsave, sizeof(state[0].fxsave)) )
>> + {
>> + printf("fxsave differs!\n");
>> + for ( i = 0; i < sizeof(state[0].fxsave)/sizeof(unsigned); i++ )
>
> Blanks around / again please.
>
>> + {
>> + printf("[%04lu] %08x %08x\n",
>
> I think I've indicated before that I consider leading zeros on decimal
> numbers misleading.
Come to think of it I agree with you.
> Could I talk you into using %4lu instead (or
> really %4zu, considering the expression type) in places like this one
> (i.e. also in the earlier patch, where I notice only now the l -> z
> conversion wasn't done consistently either)?
/me looks up what %zu is supposed to do
Sure.
>
>> + i * sizeof(unsigned), ((unsigned *)&state[0].fxsave)[i], ((unsigned *)&state[1].fxsave)[i]);
>
> Long line.
Ack.
-George
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2017-10-13 10:39 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-11 17:52 [PATCH v4 01/12] fuzz/x86_emulate: Clear errors in the officially sanctioned way George Dunlap
2017-10-11 17:52 ` [PATCH v4 02/12] fuzz/x86_emulate: Improve failure descriptions in x86_emulate harness George Dunlap
2017-10-11 17:52 ` [PATCH v4 03/12] fuzz/x86_emulate: Implement input_read() and input_avail() George Dunlap
2017-10-11 17:52 ` [PATCH v4 04/12] fuzz/x86_emulate: Rename the file containing the wrapper code George Dunlap
2017-10-11 17:52 ` [PATCH v4 05/12] fuzz/x86_emulate: Add 'afl-cov' target George Dunlap
2017-10-11 17:52 ` [PATCH v4 06/12] fuzz/x86_emulate: Take multiple test files for inputs George Dunlap
2017-10-11 17:52 ` [PATCH v4 07/12] fuzz/x86_emulate: Move definitions into a header George Dunlap
2017-10-12 9:03 ` Wei Liu
2017-10-11 17:52 ` [PATCH v4 08/12] fuzz/x86_emulate: Move all state into fuzz_state George Dunlap
2017-10-12 15:16 ` Jan Beulich
2017-10-13 9:22 ` George Dunlap
2017-10-13 9:54 ` Jan Beulich
2017-10-13 9:55 ` George Dunlap
2017-10-11 17:52 ` [PATCH v4 09/12] fuzz/x86_emulate: Make input more compact George Dunlap
2017-10-11 17:52 ` [PATCH v4 10/12] fuzz/x86_emulate: Add --rerun option to try to track down instability George Dunlap
2017-10-12 15:24 ` Jan Beulich
2017-10-13 9:43 ` George Dunlap
2017-10-13 9:56 ` Jan Beulich
2017-10-11 17:52 ` [PATCH v4 11/12] fuzz/x86_emulate: Set and fuzz more CPU state George Dunlap
2017-10-12 15:38 ` Jan Beulich
2017-10-13 10:39 ` George Dunlap [this message]
2017-10-11 17:52 ` [PATCH v4 12/12] fuzz/x86_emulate: Add an option to limit the number of instructions executed George Dunlap
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=123fa10c-068d-60fe-65c5-9c059c10029d@citrix.com \
--to=george.dunlap@citrix.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=ian.jackson@citrix.com \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).