[PATCH] x86: Set TPR to block external interrupts 0-31

From: Andy Lutomirski
Date: Tue Jul 19 2011 - 09:13:50 EST

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:


Signed-off-by: Andy Lutomirski <luto@xxxxxxx>

The original paper is here and is rather interesting:

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)

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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/