| 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
| ||
|
Message-ID: <55D8C61B.3010902@redhat.com>
Date: Sat, 22 Aug 2015 20:57:31 +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/22/2015 10:54 AM, Ingo Molnar wrote:
>
> * Denys Vlasenko <dvlasenk@...hat.com> wrote:
>
>> +/* fcmovCC and f(u)comi(p) are enabled if CPUID(1).EDX(15) "cmov" is set */
>> +
>> static FUNC const st_instr_table[64] = {
>> - fadd__, fld_i_, __BAD__, __BAD__, fadd_i, ffree_, faddp_, _df_c0_,
>> - fmul__, fxch_i, __BAD__, __BAD__, fmul_i, _dd_c8_, fmulp_, _df_c8_,
>> - fcom_st, fp_nop, __BAD__, __BAD__, _dc_d0_, fst_i_, _de_d0_, _df_d0_,
>> - fcompst, _d9_d8_, __BAD__, __BAD__, _dc_d8_, fstp_i, fcompp, _df_d8_,
>> + 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, __BAD__, fsub_i, fucomp, fsubp_, __BAD__,
>> - fdiv__, FPU_triga, __BAD__, __BAD__, fdivri, __BAD__, fdivrp, __BAD__,
>> + 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__,
>> };
>
> So the problem is that you did not give an FPU register encoding type table entry
> for the new opcodes:
>
> static u_char const type_table[64] = {
> _REGI_, _NONE_, _null_, _null_, _REGIi, _REGi_, _REGIp, _REGi_,
> _REGI_, _REGIn, _null_, _null_, _REGIi, _REGI_, _REGIp, _REGI_,
> _REGIc, _NONE_, _null_, _null_, _REGIc, _REG0_, _REGIc, _REG0_,
> _REGIc, _REG0_, _null_, _null_, _REGIc, _REG0_, _REGIc, _REG0_,
> _REGI_, _NONE_, _null_, _NONE_, _REGIi, _REGIc, _REGIp, _NONE_,
> _REGI_, _NONE_, _REGIc, _null_, _REGIi, _REGIc, _REGIp, _null_,
> _REGI_, _NONE_, _null_, _null_, _REGIi, _null_, _REGIp, _null_,
> _REGI_, _NONE_, _null_, _null_, _REGIi, _null_, _REGIp, _null_
> };
>
> Those _null_ entries must be filled in as well.
>
> For FUCOMI[P] it's _REGIc I think, so I tried that - and the patch below on top of
> yours made those instructions appear to work - only to be caught in an MMX op:
>
> 0xb75eb3fb <bn_mul_add_words+59>: movd %ebp,%mm0
>
> :-/
>
> Arguably the way I tested it, user-space libraries see SSE and MMX capabilities:
>
> flags : vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
> pse36 clflush mmx sse2 ht syscall nx mmxext lm 3dnowext 3dnow rep_good pni lahf_lm
> cmp_legacy 3dnowprl...
>
> So I'll first turn those CPUID bits off, to (hopefully) not confuse user-space.
>
> Thanks,
>
> Ingo
>
> ====================>
>
> arch/x86/math-emu/fpu_entry.c | 82 ++++++++++++++-----------------------------
> 1 file changed, 27 insertions(+), 55 deletions(-)
>
> diff --git a/arch/x86/math-emu/fpu_entry.c b/arch/x86/math-emu/fpu_entry.c
> index d20c8f8420e2..4d91c0fc6bc3 100644
> --- a/arch/x86/math-emu/fpu_entry.c
> +++ b/arch/x86/math-emu/fpu_entry.c
> @@ -40,12 +40,10 @@
>
> #define __BAD__ FPU_illegal /* Illegal on an 80486, causes SIGILL */
>
> -#ifndef NO_UNDOC_CODE /* Un-documented FPU op-codes supported by default. */
> -
> -/* WARNING: These codes are not documented by Intel in their 80486 manual
> +/* WARNING: These codes are not all documented by Intel in their 80486 manual
> and may not work on FPU clones or later Intel FPUs. */
>
> -/* Changes to support the un-doc codes provided by Linus Torvalds. */
> +/* Changes to support the un-documented instructions provided by Linus Torvalds. */
>
> #define _d9_d8_ fstp_i /* unofficial code (19) */
> #define _dc_d0_ fcom_st /* unofficial code (14) */
> @@ -60,31 +58,24 @@
> /* fcmovCC and f(u)comi(p) are enabled if CPUID(1).EDX(15) "cmov" is set */
>
> 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.
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__,
They should be:
--
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/
Powered by blists - more mailing lists