Re: [PATCH] Revert "x86/fpu: Refine and simplify the magic number check during signal return"

[Andrei Vagin]

On Sat, May 2, 2026 at 12:23 PM Chang S. Bae <chang.seok.bae@xxxxxxxxx> wrote:
>
> On 5/1/2026 2:42 PM, Andrei Vagin wrote:
> >
> > My point is that the reverted change broke a significant, real-life use
> > case that the hardware was explicitly designed to support.
> >
> > It is the responsibility of C/R tooling to ensure the migration target
> > is compatible with the source. Enforcing a magic check based on a fixed
> > offset does not provide additional security. The kernel must be prepared
> > to handle "trash" data in the userspace xsave area and manage any
> > exceptions triggered by the xrstor instruction.
>
> It looks like this behavior has been in place since c37b5efea43f ("x86,
> xsave: save/restore the extended state context in sigframe"). With the
> sanity check, userspace can modify the sw_fx->xfeature_size and the
> sw_fx->xfeatures (independently).

I will take a look at this. Thanks.

>
>
> But, it seems there is no consistency check between the two. For
> example, the size only could be set to an arbitrary value within the
> valid range, without matching xfeatures.
>
> If userspace sets an inconsistent size vs. xfeatures, maybe zeroing out
> the garbage could be an option which I expect still compatible with the
> portability model.
>
> It's still not entirely clear to me whether your claimed portability was
> considered in the original sigframe design. If so, this should be
> documented more clearly (e.g., in headers and/or Documentation), along
> with relevant selftests. I’d to follow up on that.

I will address this in a separate series.

>
>
> That said, yes, this area ultimately falls under the rule of not
> breaking userspace. So,
>
>    Acked-by: Chang S. Bae chang.seok.bae@xxxxxxxxx

Thank you, Chang. Ingo, could you take this patch?

ps Sorry for the previous html reply with the same content.

Thanks,
Andrei