Re: [PATCH Bugfix v2 2/4] x86/xsaves: Define and use user_xstate_size for xstate size in signal context

From: Dave Hansen
Date: Wed Apr 22 2015 - 20:34:38 EST


On 04/22/2015 05:06 PM, Yu, Fenghua wrote:
> We need to copy ALL of supported xstates to user. Using xstate_bv only copies
> partial xstates that are in non-init status.
>
> Xstate_bv only has xstates that are in non-init status. The xstates that are in
> init status will not be copied to user if using xstate_bv. In this case, the xstates
> that are in init status will be all zeros in the user buffer (remember we clear
> the user buffer before). That's incorrect.

Do we *need* to fill every field in the user buffer? I don't think
that's a given. The xstate_bv that we copy out to userspace would
clearly spell out which fields we've populated. Leaving the rest zeros
might be OK.

> So there should be a problem to use pcntxt_mask here.

I'm not convinced. Let's step through this.

1. kernel does an xsaves
2. Due to the 'init optimization' xstate_bv != pcntxt_mask, and some
fields of kernel xsave buffer are untouched
3. Kernel looks at pcntxt_mask, which means it copies untouched xsave
buffer fields out to userspace

If those untouched fields of the xsave buffer are in the "init state",
then we've got no problem. But, are those "untouched since (1)" fields
in the kernel xsave buf *GUARANTEED* to be in the init state?

What stops this sequence of events from happening?

1. task sets xsave fields to non-init state
2. kernel 'xsaves' xsave fields to fpu.state->xsave
3. userspace gets all xsave fields to init state again
4. kernel calls 'xsaves' again, but 'xsaves' declines to fill the
fpu.state->xsave fields because of the init optimization, leaves some
xstate_bv bits = 0.
5. Signal handling code looks at pcntxt_mask, copies stale
non-init-state fields from (2) out to userspace
6. Userspace sees wrong fields. Boom.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/