linux-kernel - Re: BIOS implementors disabling the LAPIC

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: <Pine.LNX.4.64N.0707311119350.16158@blysk.ds.pg.gda.pl>
Date:	Tue, 31 Jul 2007 11:27:25 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@...ux-mips.org>
To:	John Sigler <linux.kernel@...e.fr>
cc:	linux-kernel@...r.kernel.org,
	linux-rt-users <linux-rt-users@...r.kernel.org>
Subject: Re: BIOS implementors disabling the LAPIC

On Tue, 31 Jul 2007, John Sigler wrote:

> As far as I understand, the Local APIC was integrated directly to the CPU
> 12-15 years ago. Why would a BIOS implementor choose to disable it?

 Because they are lazy/incapable/out-of-time/select-your-favourite-excuse.  
For the chip to work you have to provide some minimal support in the 
firmware, in particular for the trickier paths of execution in the system 
management mode.  The system still works with the Local APIC disabled, so 
why bother?

> (And what does it mean to "disable" the LAPIC?)

 The LINT0 and LINT1 inputs of the APIC are routed straight to the INT and 
NMI inputs of the CPU respectively and the rest of the APIC logic becomes 
inactive (tri-stated, etc.).

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