linux-kernel - Re: [PATCH] RISC-V: Add STACKLEAK erasing the kernel stack at the end of syscalls

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, 7 Oct 2022 12:29:49 +0100
From:   Mark Rutland <mark.rutland@....com>
To:     Palmer Dabbelt <palmer@...belt.com>
Cc:     Conor.Dooley@...rochip.com, guoren@...nel.org, oleg@...hat.com,
        vgupta@...nel.org, linux@...linux.org.uk, monstr@...str.eu,
        dinguyen@...nel.org, davem@...emloft.net,
        Arnd Bergmann <arnd@...db.de>, shorne@...il.com,
        Paul Walmsley <paul.walmsley@...ive.com>,
        aou@...s.berkeley.edu, ardb@...nel.org, heiko@...ech.de,
        daolu@...osinc.com, linux-arch@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org,
        linux-arm-kernel@...ts.infradead.org,
        linux-snps-arc@...ts.infradead.org, sparclinux@...r.kernel.org,
        openrisc@...ts.librecores.org, xianting.tian@...ux.alibaba.com,
        linux-efi@...r.kernel.org
Subject: Re: [PATCH] RISC-V: Add STACKLEAK erasing the kernel stack at the
 end of syscalls

On Thu, Oct 06, 2022 at 07:31:01PM -0700, Palmer Dabbelt wrote:
> On Tue, 06 Sep 2022 10:35:10 PDT (-0700), Conor.Dooley@...rochip.com wrote:
> > On 03/09/2022 17:23, guoren@...nel.org wrote:
> > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> > > 
> > > From: Xianting Tian <xianting.tian@...ux.alibaba.com>
> > > 
> > > This adds support for the STACKLEAK gcc plugin to RISC-V and disables
> > > the plugin in EFI stub code, which is out of scope for the protection.
> > > 
> > > For the benefits of STACKLEAK feature, please check the commit
> > > afaef01c0015 ("x86/entry: Add STACKLEAK erasing the kernel stack at the end of syscalls")
> > > 
> > > Performance impact (tested on qemu env with 1 riscv64 hart, 1GB mem)
> > >     hackbench -s 512 -l 200 -g 15 -f 25 -P
> > >     2.0% slowdown
> > > 
> > > Signed-off-by: Xianting Tian <xianting.tian@...ux.alibaba.com>
> > 
> > What changed since Xianting posted it himself a week ago:
> > https://lore.kernel.org/linux-riscv/20220828135407.3897717-1-xianting.tian@linux.alibaba.com/
> > 
> > There's an older patch from Du Lao adding STACKLEAK too:
> > https://lore.kernel.org/linux-riscv/20220615213834.3116135-1-daolu@rivosinc.com/
> > 
> > But since there's been no activity there since June...
> 
> Looks like the only issues were some commit log wording stuff, and that
> there's a test suite that should be run.  It's not clear from the commits
> that anyone has done that, I'm fine with the patch if it passes the tests
> but don't really know how to run them.

Enable CONFIG_LKDTM, and do:

  echo STACKLEAK_ERASING > /sys/kernel/debug/provoke-crash/DIRECT

Example GOOD/BAD output below, taken from:

  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/misc/lkdtm/stackleak.c?id=72b61896f2b47fa4b98e86184bc0e6ddbd1a8db1

GOOD result on x86_64:

| # echo STACKLEAK_ERASING > /sys/kernel/debug/provoke-crash/DIRECT
| lkdtm: Performing direct entry STACKLEAK_ERASING
| lkdtm: stackleak stack usage:
|   high offset: 168 bytes
|   current:     336 bytes
|   lowest:      656 bytes
|   tracked:     656 bytes
|   untracked:   400 bytes
|   poisoned:    15152 bytes
|   low offset:  8 bytes
| lkdtm: OK: the rest of the thread stack is properly erased

GOOD result on arm64:

| # echo STACKLEAK_ERASING > /sys/kernel/debug/provoke-crash/DIRECT
| lkdtm: Performing direct entry STACKLEAK_ERASING
| lkdtm: stackleak stack usage:
|   high offset: 336 bytes
|   current:     656 bytes
|   lowest:      1232 bytes
|   tracked:     1232 bytes
|   untracked:   672 bytes
|   poisoned:    14136 bytes
|   low offset:  8 bytes
| lkdtm: OK: the rest of the thread stack is properly erased

BAD result on arm64:

| # echo STACKLEAK_ERASING > /sys/kernel/debug/provoke-crash/DIRECT
| lkdtm: Performing direct entry STACKLEAK_ERASING
| lkdtm: FAIL: non-poison value 24 bytes below poison boundary: 0x0
| lkdtm: FAIL: non-poison value 32 bytes below poison boundary: 0xffff8000083dbc00
...
| lkdtm: FAIL: non-poison value 1912 bytes below poison boundary: 0x78b4b9999e8cb15
| lkdtm: FAIL: non-poison value 1920 bytes below poison boundary: 0xffff8000083db400
| lkdtm: stackleak stack usage:
|   high offset: 336 bytes
|   current:     688 bytes
|   lowest:      1232 bytes
|   tracked:     576 bytes
|   untracked:   288 bytes
|   poisoned:    15176 bytes
|   low offset:  8 bytes
| lkdtm: FAIL: the thread stack is NOT properly erased!
| lkdtm: Unexpected! This kernel (5.18.0-rc1-00013-g1f7b1f1e29e0-dirty aarch64) was built with CONFIG_GCC_PLUGIN_STACKLEAK=y

Mark.