Re: [PATCH] Kconfig.debug: disable CONFIG_FRAME_WARN for KASAN_STACK && CC_IS_CLANG by default

From: "Arnd Bergmann" <arnd@arndb.de>
To: "Tudor Ambarus" <tudor.ambarus@linaro.org>,
	"Nathan Chancellor" <nathan@kernel.org>,
	"Nick Desaulniers" <ndesaulniers@google.com>,
	"Tom Rix" <trix@redhat.com>,
	"Andrew Morton" <akpm@linux-foundation.org>
Cc: joneslee@google.com, "Peter Zijlstra" <peterz@infradead.org>,
	"Kees Cook" <keescook@chromium.org>,
	"Josh Poimboeuf" <jpoimboe@kernel.org>,
	zhaoyang.huang@unisoc.com,
	"Liam R. Howlett" <liam.howlett@oracle.com>,
	"Randy Dunlap" <rdunlap@infradead.org>,
	"Geert Uytterhoeven" <geert+renesas@glider.be>,
	linux-kernel@vger.kernel.org, llvm@lists.linux.dev,
	"Mark Brown" <broonie@kernel.org>,
	"Dmitry Vyukov" <dvyukov@google.com>,
	nogikh@google.com, "Ard Biesheuvel" <ardb@kernel.org>
Subject: Re: [PATCH] Kconfig.debug: disable CONFIG_FRAME_WARN for KASAN_STACK && CC_IS_CLANG by default
Date: Sun, 30 Apr 2023 00:03:26 +0200	[thread overview]
Message-ID: <96947fdc-835f-4bfa-b112-4ba9991cfe5f@app.fastmail.com> (raw)
In-Reply-To: <b6341f73-3ad2-4fcf-8612-e026751019b5@app.fastmail.com>

On Fri, Apr 21, 2023, at 17:28, Arnd Bergmann wrote:
> On Fri, Apr 21, 2023, at 17:10, Tudor Ambarus wrote:
>> On 4/21/23 15:30, Arnd Bergmann wrote:
>
> The main problem with stack frame usage is that the compiler cannot know
> during compile time what the other functions are going to use, so it's
> always a bit of guesswork, and we just try to make the limit as small
> as possible without causing too much work addressing the warnings.

Hi Tudor,

One follow-up here regarding the risk of actually overflowing the
stack on production systems: There is a possible feature that I've
discussed with Ard in the past, if we add a user-configurable stack offset
for syscall entry, it becomes possible to test kernels with an
artificially low stack size to find out the most critical call chain
that one can hit from user space.

You mentioned elsewhere that you are using syzkaller for testing for bugs,
and this would be the perfect way to exercise the modified kernels as
well, since it can hit all kinds of unusual call chains.

We already call add_random_kstack_offset() on four architectures (arm64,
powerpc, s390 and x86), and the same location could add a fixed offset
that is configurable e.g. system-wide using sysctl() or per task using
prctl(), depending on what makes this more useful for testing.

When CONFIG_VMAP_STACK is set, the result should be a process crash
with a full call chain printed to see how it got this bad, similar to
what you get with a KASAN violation. This probably makes most sense
with KASAN_STACK disabled to see which functions are the most critical
in real systems, though testing with KASAN_STACK enabled could also
give some hints at which of the warnings you see are worth fixing first.

If you would like to run tests with this, I might be able to come
up with a prototype patch for it.

       Arnd