linux-kernel - RE: [PATCH V4 6/8] riscv: Support HAVE_IRQ_EXIT_ON_IRQ

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:   Fri, 9 Sep 2022 07:30:30 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Sebastian Andrzej Siewior' <bigeasy@...utronix.de>,
        "guoren@...nel.org" <guoren@...nel.org>
CC:     "arnd@...db.de" <arnd@...db.de>,
        "palmer@...osinc.com" <palmer@...osinc.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "luto@...nel.org" <luto@...nel.org>,
        "conor.dooley@...rochip.com" <conor.dooley@...rochip.com>,
        "heiko@...ech.de" <heiko@...ech.de>,
        "jszhang@...nel.org" <jszhang@...nel.org>,
        "lazyparser@...il.com" <lazyparser@...il.com>,
        "falcon@...ylab.org" <falcon@...ylab.org>,
        "chenhuacai@...nel.org" <chenhuacai@...nel.org>,
        "apatel@...tanamicro.com" <apatel@...tanamicro.com>,
        "atishp@...shpatra.org" <atishp@...shpatra.org>,
        "palmer@...belt.com" <palmer@...belt.com>,
        "paul.walmsley@...ive.com" <paul.walmsley@...ive.com>,
        "linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
        Guo Ren <guoren@...ux.alibaba.com>
Subject: RE: [PATCH V4 6/8] riscv: Support HAVE_IRQ_EXIT_ON_IRQ_STACK

From: Sebastian Andrzej Siewior
> Sent: 08 September 2022 17:08
> 
> On 2022-09-07 22:25:04 [-0400], guoren@...nel.org wrote:
> > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> > index a07bb3b73b5b..a8a12b4ba1a9 100644
> > --- a/arch/riscv/Kconfig
> > +++ b/arch/riscv/Kconfig
> > @@ -433,6 +433,14 @@ config FPU
> >
> >  	  If you don't know what to do here, say Y.
> >
> > +config IRQ_STACKS
> > +	bool "Independent irq stacks"
> > +	default y
> > +	select HAVE_IRQ_EXIT_ON_IRQ_STACK
> > +	help
> > +	  Add independent irq stacks for percpu to prevent kernel stack overflows.
> > +	  We may save some memory footprint by disabling IRQ_STACKS.
> 
> Do you really think that it is needed to save memory here? Avoiding
> stack overflows in deep call chains is probably more important than
> saving ~8KiB per CPU.

Particularly if a 64bit build is using small stacks.

Without static analysis of actual call chain depth it is
really difficult to trim the stack size.

I'd bet (a few beers) that the deepest stack use in inside
the console print code form a printk() (eg warn_on_once)
in an obscure error path somewhere.
This won't be hit during any normal testing.

I think that the analysis objtool does is getting close
to be able to generate the raw data that can be used for
static stack depth analysis.
You need the 'CFI' constants for indirect calls and
some assumptions about depth of recursive calls.
But apart from that the code to process the raw output
isn't that complex.

A nice task for someone with some spare time.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)