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:	Wed, 17 Feb 2010 14:38:00 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Luca Barbieri <luca@...a-barbieri.com>
CC:	mingo@...e.hu, a.p.zijlstra@...llo.nl, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 10/10] x86-32: panic on !CX8 && XMM

On 02/17/2010 03:42 AM, Luca Barbieri wrote:
> No known CPU should have this combination, and future ones are very
> unlikely to.
> 
> However, should this happen, we would generate working but non-atomic
> code, so panic instead.
> ---
>  arch/x86/lib/atomic64_32.c |   11 +++++++++++
>  1 files changed, 11 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/x86/lib/atomic64_32.c b/arch/x86/lib/atomic64_32.c
> index 9ff8589..35dbd12 100644
> --- a/arch/x86/lib/atomic64_32.c
> +++ b/arch/x86/lib/atomic64_32.c
> @@ -47,6 +47,17 @@ EXPORT_SYMBOL(cx8_atomic64_inc_not_zero_cx8call);
>  union generic_atomic64_lock generic_atomic64_lock[ATOMIC64_NR_LOCKS] __cacheline_aligned_in_smp;
>  pure_initcall(init_generic_atomic64_lock);
>  
> +static int __init panic_on_sse_without_cx8(void)
> +{
> +	/* no known CPU should do this, and we generate non-atomic code in this case
> +	 * because we mix the generic spinlock-reliant code and the SSE code
> +	 */
> +	if (!boot_cpu_has(X86_FEATURE_CX8) && boot_cpu_has(X86_FEATURE_XMM))
> +		panic("CPUs without CX8 but with SSE are not supported\nBoot with clearcpuid=25 and report your CPU model to linux-kernel@...r.kernel.org\n");
> +	return 0;
> +}
> +core_initcall(panic_on_sse_without_cx8);
> +
>  EXPORT_SYMBOL(generic_atomic64_add);
>  EXPORT_SYMBOL(generic_atomic64_add_return);
>  EXPORT_SYMBOL(generic_atomic64_sub);

NAK in the extreme.

This is not how we deal with these kinds of stuff.  If this really
matters, we explicitly clear the CPU feature in the feature detect code.

	-hpa

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ