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-next>] [day] [month] [year] [list]
Date:   Mon, 19 Dec 2016 14:20:55 +0000
From:   Matt Redfearn <matt.redfearn@...tec.com>
To:     Ralf Baechle <ralf@...ux-mips.org>
CC:     <linux-mips@...ux-mips.org>,
        "Jason A . Donenfeld" <Jason@...c4.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Matt Redfearn <matt.redfearn@...tec.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Marcin Nowakowski <marcin.nowakowski@...tec.com>,
        Chris Metcalf <cmetcalf@...lanox.com>,
        Petr Mladek <pmladek@...e.com>, <linux-kernel@...r.kernel.org>,
        Adam Buchbinder <adam.buchbinder@...il.com>,
        James Hogan <james.hogan@...tec.com>,
        Paul Burton <paul.burton@...tec.com>,
        Jiri Slaby <jslaby@...e.cz>,
        "Maciej W. Rozycki" <macro@...tec.com>,
        Aaron Tomlin <atomlin@...hat.com>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: [PATCH v3 0/5] MIPS: Add per-cpu IRQ stack


This series adds a separate stack for each CPU wihin the system to use
when handling IRQs. Previously IRQs were handled on the kernel stack of
the current task. If that task was deep down a call stack at the point
of the interrupt, and handling the interrupt required a deep IRQ stack,
then there was a likelihood of stack overflow. Since the kernel stack
is in normal unmapped memory, overflowing it can lead to silent
corruption of other kernel data, with weird and wonderful results.

Before this patch series, ftracing the maximum stack size of a v4.9
kernel running on a Ci40 board gave:
4996

And with this series:
4084

Handling interrupts on a separate stack reduces the maximum kernel stack
usage in this configuration by ~900 bytes.

Since do_IRQ is now invoked on a separate stack, we select
HAVE_IRQ_EXIT_ON_IRQ_STACK so that softirqs will also be executed on the
irq stack rather than attempting to switch with do_softirq_own_stack().

This series has been tested on MIPS Boston, Malta and SEAD3 platforms,
Pistachio on the Creator Ci40 board and Cavium Octeon III.


Changes in v3:
Drop superfluous nop that would have been in delay slot with .set
noreorder but is no longer required now that the code is .set reorder.

Changes in v2:
Drop .set reorder/noreorder when updating $28

Matt Redfearn (5):
  MIPS: Introduce irq_stack
  MIPS: Stack unwinding while on IRQ stack
  MIPS: Only change $28 to thread_info if coming from user mode
  MIPS: Switch to the irq_stack in interrupts
  MIPS: Select HAVE_IRQ_EXIT_ON_IRQ_STACK

 arch/mips/Kconfig                  |  1 +
 arch/mips/include/asm/irq.h        | 12 ++++++
 arch/mips/include/asm/stackframe.h |  7 ++++
 arch/mips/kernel/asm-offsets.c     |  1 +
 arch/mips/kernel/genex.S           | 81 +++++++++++++++++++++++++++++++++++---
 arch/mips/kernel/irq.c             | 11 ++++++
 arch/mips/kernel/process.c         | 15 ++++++-
 7 files changed, 122 insertions(+), 6 deletions(-)

-- 
2.7.4

Powered by blists - more mailing lists