netdev - RE: [PATCH 0/7] net: openvswitch: Reduce stack usage

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: <ff6cd12e28894f158d9a6c9f7157487f@AcuMS.aculab.com>
Date: Fri, 13 Oct 2023 08:27:00 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Nicholas Piggin' <npiggin@...il.com>, Aaron Conole <aconole@...hat.com>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "dev@...nvswitch.org"
	<dev@...nvswitch.org>, Pravin B Shelar <pshelar@....org>, Eelco Chaudron
	<echaudro@...hat.com>, Ilya Maximets <imaximet@...hat.com>, Flavio Leitner
	<fbl@...hat.com>, Paolo Abeni <pabeni@...hat.com>, Jakub Kicinski
	<kuba@...nel.org>, "David S. Miller" <davem@...emloft.net>, Eric Dumazet
	<edumazet@...gle.com>
Subject: RE: [PATCH 0/7] net: openvswitch: Reduce stack usage

From: Nicholas Piggin
> Sent: 12 October 2023 02:19
...
> It is a kernel crash, so we need something for stable. But In a case
> like this there's not one single problem. Linux kernel stack use has
> always been pretty dumb - "don't use too much", for some values of
> too much, and just cross fingers config and compiler and worlkoad
> doesn't hit some overflow case.

I think it ought to be possible to use a FINE_IBT (I think that
is what it is called) compile to get indirect calls grouped
and change objtool to output the stack offset of every call.
It is then a simple (for some definition of simple) process
to work out the static maximum stack usage.

Any recursion causes grief (the stack depth for each
loop can be reported).

Also I suspect the compiler will need an enhancement to
add a constant into the hash to disambiguate indirect
calls with the same argument list.

My suspicion (from doing this exercise on an embedded system
a long time ago) is that the stack will be blown somewhere
inside printk() in some error path.

	David

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