linux-kernel - Re: [PATCH 3/3] x86, FPU: Do not use static_cpu

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:	Mon, 29 Apr 2013 20:51:23 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	X86 ML <x86@...nel.org>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/3] x86, FPU: Do not use static_cpu_has before
 alternatives

On Mon, Apr 29, 2013 at 08:42:30AM -0700, H. Peter Anvin wrote:
> I *was* considering adding static_cpu_has_safe() at some point which
> would have a three-state jump, with the default (pre-alternatives)
> jump pointing to dynamic detection code.

Actually, if we teach __static_cpu_has to do something like
ALTERNATIVE_JUMP arch/x86/lib/copy_user_64.S but make the second
alternative insn alt2 be none, i.e. no replacement, we can have:

* pre-alternatives: JMP dynamic_detection
* post-alternatives:
  - feature present: delete JMP
  - feature absent: s/dynamic_detection/t_no/, i.e., patch only the label.

And even though asm goto supports multiple labels, we need to be able
to either patch the label only or patch out the whole instruction -
otherwise we'll be adding additional NOP bytes.

I wonder if it would make sense to teach the alternatives to skip the
opcode when patching so that we can say: "we only want to patch the
label so we're patching in the offset now but leaving the single JMP
opcode in there."

But for that we either need flags in struct alt_instr or do something
ad-hoc apply_alternatives already does for relative jumps (0xe8).

> This might be useful here, on the other hand, perhaps it is acceptable
> for use_eager_fpu() to be initially false?

Hmm, I don't know, FPU code is crazy. OTOH, does CR0.TS even matter on
non-lazy FPU restore machines?

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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/