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, 26 Feb 2020 18:08:56 +0100
From:   Frederic Weisbecker <frederic@...nel.org>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     LKML <linux-kernel@...r.kernel.org>, x86@...nel.org,
        Steven Rostedt <rostedt@...dmis.org>,
        Brian Gerst <brgerst@...il.com>,
        Juergen Gross <jgross@...e.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Arnd Bergmann <arnd@...db.de>,
        Josh Poimboeuf <jpoimboe@...hat.com>
Subject: Re: [patch 05/10] x86/traps: Document do_spurious_interrupt_bug()

On Tue, Feb 25, 2020 at 10:36:41PM +0100, Thomas Gleixner wrote:
> Add a comment which explains why this empty handler for a reserved vector
> exists.
> 
> Requested-by: Josh Poimboeuf <jpoimboe@...hat.com>
> Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
> ---
>  arch/x86/kernel/traps.c |   19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
> 
> --- a/arch/x86/kernel/traps.c
> +++ b/arch/x86/kernel/traps.c
> @@ -862,6 +862,25 @@ do_simd_coprocessor_error(struct pt_regs
>  dotraplinkage void
>  do_spurious_interrupt_bug(struct pt_regs *regs, long error_code)
>  {
> +	/*
> +	 * This addresses a Pentium Pro Erratum:
> +	 *
> +	 * PROBLEM: If the APIC subsystem is configured in mixed mode with
> +	 * Virtual Wire mode implemented through the local APIC, an
> +	 * interrupt vector of 0Fh (Intel reserved encoding) may be
> +	 * generated by the local APIC (Int 15).  This vector may be
> +	 * generated upon receipt of a spurious interrupt (an interrupt
> +	 * which is removed before the system receives the INTA sequence)
> +	 * instead of the programmed 8259 spurious interrupt vector.
> +	 *
> +	 * IMPLICATION: The spurious interrupt vector programmed in the
> +	 * 8259 is normally handled by an operating system's spurious
> +	 * interrupt handler. However, a vector of 0Fh is unknown to some
> +	 * operating systems, which would crash if this erratum occurred.
> +	 *
> +	 * In theory this could be limited to 32bit, but the handler is not
> +	 * hurting and who knows which other CPUs suffer from this.
> +	 */
>  }

Nice to have!

Reviewed-by: Frederic Weisbecker <frederic@...nel.org>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ