linux-kernel - RE: [patch] x86: ptrace and core-dump extensions for xstate

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]

Message-ID: <8EA2C2C4116BF44AB370468FBF85A7770123AAB0AE@orsmsx504.amr.corp.intel.com>
Date:	Wed, 3 Feb 2010 15:45:12 -0800
From:	"Lu, Hongjiu" <hongjiu.lu@...el.com>
To:	Roland McGrath <roland@...hat.com>,
	"Siddha, Suresh B" <suresh.b.siddha@...el.com>
CC:	Oleg Nesterov <oleg@...hat.com>, "H. Peter Anvin" <hpa@...or.com>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>,
	"Lachner, Peter" <peter.lachner@...el.com>
Subject: RE: [patch] x86: ptrace and core-dump extensions for xstate

> 
> > +	case PTRACE_GETXSTATEREGS:	/* Get the child extended state. */
> > +		return copy_regset_to_user(child,
> > +					   task_user_regset_view(current),
> > +					   REGSET_XSTATE,
> > +					   0, xstate_size,
> > +					   datap);
> > +
> > +	case PTRACE_SETXSTATEREGS:	/* Set the child extended state. */
> > +		return copy_regset_from_user(child,
> > +					     task_user_regset_view(current),
> > +					     REGSET_XSTATE,
> > +					     0, xstate_size,
> > +					     datap);
> 
> I think this is a poor choice of interface for this.  The other existing
> PTRACE_GET*REGS calls use a fixed-size and fixed-layout block that is a
> known constant in the userland ABI.  Here, userland has no way to know
> xstate_size, so you are accessing a chunk of user memory where userland
> doesn't really know how much you are going to access.
> 
> AFAICT from skimming the Intel manuals, there is no specified upper bound
> on how big the xsave size might grow in future processors.  I would think
> that it might be limited to a page, since there is no way to indicate a
> partial copy to restart after a page fault.  So for unpinned access (such
> as in user mode, or the user memory access in the signal frame setup), in
> full-thrashing situations an xsave spanning multiple pages might thrash
> totally and never make progress.  OTOH, the manual does not say that the
> buffer can't span two pages today, just that it has to be 64-byte aligned.
> So perhaps we already have that issue (for signal frame setup or for direct
> user-space uses of xsave/xrstor) and it's just not really an issue that
> matters (thrashing is thrashing--it's already pathological, so who cares if
> it's literal livelock or not).  The upshot being, I don't think there is an
> obvious upper bound that userland can presume statically here.
> 
> AFAICT, the only way for userland to guess xstate_size is to use cpuid
> itself.  Even if that is actually reliable, or even if the kernel gave
> userland some other means to know the kernel's xstate_size value, IMHO that
> is a pretty dubious and error-prone way to construct the ABI.  Usually when
> userland supplies a buffer whose size is not a permanent constant of the
> ABI, userland says how big a buffer it's passing in.
> 

Gdb calls cpuid during startup time to find out the actual xstate_size
on the target machine. It has to be reliable. There is no need for
another ptrace option. But we should document it clearly in ABI.


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