If an external interrupt with vector 0-31 comes in, we are likely to
do the wrong thing, since we'll think it's a trap from the CPU.
Depending on which vector it is, we could get even more confused,
because some traps push an error code but traps do not, so we will
corrupt the stack on return.

We can reduce the chance that we get such an interrupt from a rogue
or malfunctioning device by changing the APIC's TPR.

This is not known to fix any real bugs, but it should not hurt and
it's has no performance cost.  It is inspired by, but much less
aggressive than this patch from Xen:

http://xenbits.xen.org/hg/staging/xen-4.0-testing.hg/rev/b85a9e58ec3a

Signed-off-by: Andy Lutomirski <luto@mit.edu>
---

The original paper is here and is rather interesting:
http://www.invisiblethingslab.com/resources/2011/Software%20Attacks%20on%20Intel%20VT-d.pdf

This patch *does not* prevent most of the interesting attacks in
that paper, and the fancy mitigation tricks that Xen added seem
silly.  They don't address all of the attacks, and they slow down
interrupt processing.  But this particular part should be free and
seems like a potentially worthwhile change to improve resistance to
dumb bugs.

 arch/x86/kernel/apic/apic.c |    8 +++-----
 1 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index b9338b8..125e2b2 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1252,12 +1252,10 @@ void __cpuinit setup_local_APIC(void)
 #endif
 
 	/*
-	 * Set Task Priority to 'accept all'. We never change this
-	 * later on.
+	 * Set Task Priority to 'accept all external vectors'. We never
+	 * change this later on.
 	 */
-	value = apic_read(APIC_TASKPRI);
-	value &= ~APIC_TPRI_MASK;
-	apic_write(APIC_TASKPRI, value);
+	apic_write(APIC_TASKPRI, (FIRST_EXTERNAL_VECTOR & 0xF0) - 0x10);
 
 	/*
 	 * After a crash, we no longer service the interrupts and a pending
-- 
1.7.6