linux-kernel - Re: [PATCH v9 08/26] x86/fpu/xstate: Introduce helpers to manage the XSTATE buffer dynamically

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 18 Aug 2021 11:28:24 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     "Bae, Chang Seok" <chang.seok.bae@...el.com>
Cc:     "Lutomirski, Andy" <luto@...nel.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "mingo@...nel.org" <mingo@...nel.org>,
        "x86@...nel.org" <x86@...nel.org>,
        "Brown, Len" <len.brown@...el.com>,
        "Hansen, Dave" <dave.hansen@...el.com>,
        "Macieira, Thiago" <thiago.macieira@...el.com>,
        "Liu, Jing2" <jing2.liu@...el.com>,
        "Shankar, Ravi V" <ravi.v.shankar@...el.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v9 08/26] x86/fpu/xstate: Introduce helpers to manage the
 XSTATE buffer dynamically

On Fri, Aug 13, 2021 at 07:43:53PM +0000, Bae, Chang Seok wrote:
> Without the “compacted” notion in the function name, one might
> call this even with !XSAVES. But chances are very low in practice.

So leave only the first two which are obvious and are more likely to
happen - the first one is going to be the most likely on non-dynamic
setups and the second one is on dynamic systems.

For all the other configurations, just do the loop and that's it.

*IF* an optimization needs to happen there, then it can happen latter,
supplied with perf numbers to justify it.

> Perhaps, the call site in the ptrace path becomes like this, I think:
> 
> +	if (xfeatures_mask_user_dynamic) {
> +		u64 state_mask;
> +
> +		/* Retrieve XSTATE_BV. */
> +		memcpy(&state_mask, (kbuf ?: tmpbuf) + offsetof(struct xregs_state, header),
> +		       sizeof(u64));
> +
> +		/* Expand the xstate buffer based on the XSTATE_BV. */
> +		ret = realloc_xstate_buffer(fpu, state_mask & xfeatures_mask_user_dynamic);
> +		if (ret)
> +			goto out;
> +	}
> 
> Maybe retrieve XSTATE_BV is inevitable here. Then, it is not that ugly.

Lemme see if I can follow: here, a task is being ptraced and the tracer
process does PTRACE_SETREGS to set the xregs and you want to go and read
out the XSTATE_BV vector from the supplied xstate buffer to see how much
to enlarge the buffer.

Which makes me go, whut?

Why doesn't the task already have a large enough buffer?

IOW and IIUC, you should not have to ever resize the xstate buffer of a
task in ptrace.

> In this case, the ptracer just failed to inject some context. But the
> ptracee’s context in the (old) buffer is intact. It will resume and eventually
> exit. I think arch_release_task_struct()->free_xstate_buffer() will take care
> of the old buffer.

You think or you know?

How about verifying it.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette