linux-kernel - Re: [PATCH 084/208] x86/fpu: Rename xsave.header::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: <20150506124618.GA18655@gmail.com>
Date:	Wed, 6 May 2015 14:46:19 +0200
From:	Ingo Molnar <mingo2.kernel.org@...il.com>
To:	Ingo Molnar <mingo2.kernel.org@...il.com>
Cc:	Dave Hansen <dave.hansen@...ux.intel.com>,
	linux-kernel@...r.kernel.org,
	Andy Lutomirski <luto@...capital.net>,
	Borislav Petkov <bp@...en8.de>,
	Fenghua Yu <fenghua.yu@...el.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Oleg Nesterov <oleg@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 084/208] x86/fpu: Rename xsave.header::xstate_bv to
 'xfeatures'


* Ingo Molnar <mingo2.kernel.org@...il.com> wrote:

> > XSTATE_BV is the set of states written to the xsave area.
> > 
> > XCOMP_BV is essentially always XCR0 (aka pcntxt_mask, aka 
> > xfeatures_mask) or'd with bit 63.
> 
> So how about this naming:
> 
> 	/*
> 	 * Mask of xstate components currently not in init state, 
> 	 * typically written to by XSAVE*.
> 	 */
> 	u64 xfeat_mask_used; /* SDM: XSTATE_BV */
> 
> 	/*
> 	 * Mask of all state components saved/restored, plus the 
> 	 * compaction flag. (Note that the XRSTORS instruction caches
> 	 * this value, and the next SAVES done for this same
> 	 * area expects it to match, before it can perform the 'were
> 	 * these registers modified' hardware optimization.)
> 	 */
> 	u64 xfeat_mask_all; /* SDM: XCOMP_BV */
> 
> (Note that I kept the SDM name easily greppable.)

Hm, so the problem with this naming is that for non-compacted XRSTOR, 
XCOMP_BV has to be zero. (This seems nonsensical btw., as there's a 
separate 'compaction' flag at bit 63 already.)

So a better name would be:

 	/*
 	 * Mask of xstate components currently not in init state, 
 	 * typically written to by XSAVE*.
 	 */
	u64 xfeat_used_mask;	/* SDM: XSTATE_BV */

 	/*
 	 * This mask is non-zero if the CPU supports state compaction: 
	 * it is the mask of all state components to be saved/restored, 
	 * plus the compaction flag at bit 63.
	 * (Note that the XRSTORS instruction caches this value, and 
	 * the next SAVES done for this same area expects it to match, 
	 * before it can perform the 'were these registers modified' 
	 * hardware optimization.)
 	 */
	u64 xfeat_comp_mask;	/* SDM: XCOMP_BV */

?

Thanks,

	Ingo
--
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/