linux-kernel - Re: [PATCH] scsi: eata: drop VLA in reorder()

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: <134937.1520836598@turing-police.cc.vt.edu>
Date:   Mon, 12 Mar 2018 02:36:38 -0400
From:   valdis.kletnieks@...edu
To:     "Tobin C. Harding" <tobin@...orbit.com>
Cc:     Salvatore Mesoraca <s.mesoraca16@...il.com>,
        linux-kernel@...r.kernel.org, kernel-hardening@...ts.openwall.com,
        linux-scsi@...r.kernel.org,
        "James E.J. Bottomley" <jejb@...ux.vnet.ibm.com>,
        "Martin K. Petersen" <martin.petersen@...cle.com>,
        Dario Ballabio <ballabio_dario@....com>,
        Kees Cook <keescook@...omium.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        kernelnewbies@...nelnewbies.org
Subject: Re: [PATCH] scsi: eata: drop VLA in reorder()

On Mon, 12 Mar 2018 14:08:34 +1100, "Tobin C. Harding" said:

> removal patch that 768 was a lot of stack space.  That comment did,
> however say 'deep in some transfer call chain'.  I don't know what a
> 'transfer call chain' (the transfer bit) is but is there some heuristic
> we can use to know how deep is deep?  Or more to the point, is there some
> heuristic we can use to know what is an acceptable amount of stack space
> to use?

The canonical "why we put kernel stacks on a diet" configuration:

Imagine a bunch of ISCSI targets - with IPSec wrapping the connection.
Arranged into a software RAID5. With LVM. With encryption on the LV.  With XFS
on the encrypted LV.  And then the in-kernel sharing it out over NFS. With
more IPSec wrapping the  NFS TCP connection.

Oh, and I/O interrupts, just for fun.  And most of all of that has to fit their *entire*
stack chain into 2 4K pages.  Suddenly, that 768 bytes is taking close to 10% of
*all* of the stack that all of that call chain has to share.

And I see that patch is against scsi/eata.c - which means it can plausibly end up
sharing that stack scenario above starting at 'software raid5'.

(For bonus points, the alert reader is invited to figure out which stack each of the
above actually ends up on.  No, it isn't split across enough stacks that taking
768 bytes out of any of them is acceptable.. :)

Content of type "application/pgp-signature" skipped