linux-kernel - Re: [PATCH] x86/math-emu: Add support for FCMOVcc and F[U]COMI[P] insns

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: <55D9EB14.9010102@redhat.com>
Date:	Sun, 23 Aug 2015 17:47:32 +0200
From:	Denys Vlasenko <dvlasenk@...hat.com>
To:	Ingo Molnar <mingo@...nel.org>
CC:	Borislav Petkov <bp@...en8.de>, "H. Peter Anvin" <hpa@...or.com>,
	Andy Lutomirski <luto@...capital.net>,
	Kees Cook <keescook@...omium.org>, x86@...nel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86/math-emu: Add support for FCMOVcc and F[U]COMI[P]
 insns

On 08/23/2015 08:15 AM, Ingo Molnar wrote:
> 
> * Denys Vlasenko <dvlasenk@...hat.com> wrote:
> 
>>>  static FUNC const st_instr_table[64] = {
>>> -	fadd__,  fld_i_,  fcmovb,   fcmovnb,  fadd_i,  ffree_,  faddp_,  _df_c0_,
>>> -	fmul__,  fxch_i,  fcmove,   fcmovne,  fmul_i,  _dd_c8_, fmulp_,  _df_c8_,
>>> -	fcom_st, fp_nop,  fcmovbe,  fcmovnbe, _dc_d0_, fst_i_,  _de_d0_, _df_d0_,
>>> -	fcompst, _d9_d8_, fcmovu,   fcmovnu,  _dc_d8_, fstp_i,  fcompp,  _df_d8_,
>>> -	fsub__, FPU_etc, __BAD__, finit_, fsubri, fucom_, fsubrp, fstsw_,
>>> -	fsubr_, fconst,   fucompp,  fucomi_,  fsub_i,  fucomp,  fsubp_,  fucomip,
>>> -	fdiv__, FPU_triga, __BAD__, fcomi_,   fdivri,  __BAD__, fdivrp,  fcomip,
>>> -	fdivr_, FPU_trigb, __BAD__, __BAD__, fdiv_i, __BAD__, fdivp_, __BAD__,
>>> +/* 0x00 */	fadd__,		fld_i_,		fcmovb,		fcmovnb,
>>> +/* 0x04 */	fadd_i,		ffree_,		faddp_,		_df_c0_,
>>> +/* 0x08 */	fmul__,		fxch_i,		fcmove,		fcmovne,
>>> +/* 0x0c */	fmul_i,		_dd_c8_,	fmulp_,		_df_c8_,
>>> +/* 0x10 */	fcom_st,	fp_nop,		fcmovbe,	fcmovnbe,
>>> +/* 0x14 */	_dc_d0_,	fst_i_,		_de_d0_,	_df_d0_,
>>> +/* 0x18 */	fcompst,	_d9_d8_,	fcmovu,		fcmovnu,
>>> +/* 0x1c */	_dc_d8_,	fstp_i,		fcompp,		_df_d8_,
>>> +/* 0x20 */	fsub__,		FPU_etc,	__BAD__,	finit_,
>>> +/* 0x24 */	fsubri,		fucom_,		fsubrp,		fstsw_,
>>> +/* 0x28 */	fsubr_,		fconst,		fucompp,	fucomi_,
>>> +/* 0x2c */	fsub_i,		fucomp,		fsubp_,		fucomip,
>>> +/* 0x30 */	fdiv__,		FPU_triga,	__BAD__,	fcomi_,
>>> +/* 0x34 */	fdivri,		__BAD__,	fdivrp,		fcomip,
>>> +/* 0x38 */	fdivr_,		FPU_trigb,	__BAD__,	__BAD__,
>>> +/* 0x3c */	fdiv_i,		__BAD__,	fdivp_,		__BAD__,
>>
>> The numeric comments added at the left don't look correct.
> 
> Yeah, so they are correct for the purpose I used it: I simply wanted to index the 
> table by its natural index: 'instr_idx', which is derived from the opcode.
> 
> But you are right that indexing it by the opcode is more useful for future 
> extensions:
> 
>> In this table, each _column_ corresponds to one 0xd? opcode.
>> Each row corresponds to a group of mod-reg-rm bytes
>> with only "rm" field chnaging. (These insns act on registers,
>> not memory, and "rm" value encodes register number, st(i).)
>>
>> Something like this:
>>
>> /*Opcode: d8      d9        da      db       dc      dd      de      df */
>> /*c0..7*/ fadd__, fld_i_,   fcmovb, fcmovnb, fadd_i, ffree_, faddp_, _df_c0_,
>> /*c8..f*/ fmul__, fxch_i,   fcmove, fcmovne, fmul_i, _dd_c8_,fmulp_, _df_c8_,
>> /*d0..7*/ fcom_st,fp_nop,   fcmovbe,fcmovnbe,_dc_d0_,fst_i_, _de_d0_,_df_d0_,
>> /*d8..f*/ fcompst,_d9_d8_,  fcmovu, fcmovnu, _dc_d8_,fstp_i, fcompp, _df_d8_,
>> /*e0..7*/ fsub__, FPU_etc,  __BAD__,finit_,  fsubri, fucom_, fsubrp, fstsw_,
>> /*e8..f*/ fsubr_, fconst,   fucompp,fucomi_, fsub_i, fucomp, fsubp_, fucomip,
>> /*f0..7*/ fdiv__, FPU_triga,__BAD__,fcomi_,  fdivri, __BAD__,fdivrp, fcomip,
>> /*f8..f*/ fdivr_, FPU_trigb,__BAD__,__BAD__, fdiv_i, __BAD__,fdivp_, __BAD__,
> 
> (Assuming you also do the table alignment improvements I did, the current format 
> is pretty hard to navigate.)
> 
>>
>>
>> They should be:
> 
> Hm, your mail seems to have been cut off at this point.

In fact, my mail was too long - I forgot to delete this last line,
"They should be"    :)

I propose the table to be commented like shown below:

/*Opcode: d8      d9        da      db       dc      dd      de      df */
/*c0..f*/ fadd__, fld_i_,   fcmovb, fcmovnb, fadd_i, ffree_, faddp_, _df_c0_,
/*c8..f*/ fmul__, fxch_i,   fcmove, fcmovne, fmul_i, _dd_c8_,fmulp_, _df_c8_,
/*d0..7*/ fcom_st,fp_nop,   fcmovbe,fcmovnbe,_dc_d0_,fst_i_, _de_d0_,_df_d0_,
/*d8..f*/ fcompst,_d9_d8_,  fcmovu, fcmovnu, _dc_d8_,fstp_i, fcompp, _df_d8_,
/*e0..7*/ fsub__, FPU_etc,  __BAD__,finit_,  fsubri, fucom_, fsubrp, fstsw_,
/*e8..f*/ fsubr_, fconst,   fucompp,fucomi_, fsub_i, fucomp, fsubp_, fucomip,
/*f0..7*/ fdiv__, FPU_triga,__BAD__,fcomi_,  fdivri, __BAD__,fdivrp, fcomip,
/*f8..f*/ fdivr_, FPU_trigb,__BAD__,__BAD__, fdiv_i, __BAD__,fdivp_, __BAD__,

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