linux-kernel - Re: [PATCH 08/13] fs: limit filesystem stacking depth

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: <CA+icZUVz1DNBipOOT_j+ewKSuuFR0775RKyRWq4CcDqwafqC8Q@mail.gmail.com>
Date:	Thu, 16 Aug 2012 15:24:08 +0200
From:	Sedat Dilek <sedat.dilek@...il.com>
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	viro@...iv.linux.org.uk, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, hch@...radead.org,
	torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
	apw@...onical.com, nbd@...nwrt.org, neilb@...e.de,
	jordipujolp@...il.com, ezk@....cs.sunysb.edu, ricwheeler@...il.com,
	dhowells@...hat.com, hpj@...la.net, sedat.dilek@...glemail.com,
	penberg@...nel.org, goran.cetusic@...il.com, romain@...bokech.com
Subject: Re: [PATCH 08/13] fs: limit filesystem stacking depth

On Thu, Aug 16, 2012 at 12:42 PM, Miklos Szeredi <miklos@...redi.hu> wrote:
> Sedat Dilek <sedat.dilek@...il.com> writes:
>
>> On Wed, Aug 15, 2012 at 5:48 PM, Miklos Szeredi <miklos@...redi.hu> wrote:
>>> From: Miklos Szeredi <mszeredi@...e.cz>
>>>
>>> Add a simple read-only counter to super_block that indicates deep this
>>> is in the stack of filesystems.  Previously ecryptfs was the only
>>> stackable filesystem and it explicitly disallowed multiple layers of
>>> itself.
>>>
>>> Overlayfs, however, can be stacked recursively and also may be stacked
>>> on top of ecryptfs or vice versa.
>>>
>>> To limit the kernel stack usage we must limit the depth of the
>>> filesystem stack.  Initially the limit is set to 2.
>>>
>>
>> Hi,
>>
>> I have tested OverlayFS for a long time with "fs-stack-depth=3".
>> The original OverlayFS test-case script  from Jordi was slightly
>> modified (see "testcase-ovl-v3.sh").
>> I have sent my test-results to Andy and Jordi (tested with the
>> patchset from Andy against Linux-v3.4 [1] with Ext4-FS).
>> The attached test-case script *requires* "fs-stack-depth=3" to run
>> properly (patch attached).
>>
>> So, I have 2 questions:
>>
>> [1] FS-stack-limitation
>>
>> Is a "fs-stack-depth>=2" (like "3") critical?
>> Is your setting to "2" just a defensive (and initial) one?
>> Can you explain your choice a bit more as ecryptFS is involved in this
>> limitation, too.
>
> If directly stacking filesystems like this on top of each other
> (ecryptfs is currently the only filesystem that does this in mainline)
> then the call chain can get too long and the kernel stack overflow.
>
> Yes, setting it to 2 is defensive, it would need more stack depth
> analysis to see what an acceptable number would be.
>

Can you describe such an analysis method (in case you need help for testing it)?

>
>> [2] Test-Case/Use-Case scripts
>>
>> It would be *very very very* helpful if you could provide or even ship
>> in the Linux-kernel a test-case/use-case script, Thanks!
>
> Sure, I could add Andy's test script under the tools/ directory.  But I
> don't understand why exactly it needs the stacking depth to be
> increased.
>

No, it was Jordi's test-case script :-).
Unfortunately, my modified version had a brownbag included and will
not run (forgot a comment sign).
v4 attached is included in the atched tarball (see scripts/).

I have added my test-results against a slightly modified Linux-Next
(next-20120816) kernel (see patches/).

All relevant material is in the TAR-XZ archive (see also attached ls-lR.txt).

AFAICS Jordi is creating 3x Upper/Lower/Root dirs/mounts/etc., that's
why a "fs-stack-max-depth=3" is minimum requirement.
( Just FYI: The "LOG-24G" log-file below
TEST-3.6.0-rc1-next20120816-1-iniza-generic-DLq/ has detailed
informations. )

Hope this helps you.

- Sedat -

> Thanks,
> Miklos

View attachment "ls-lR.txt" of type "text/plain" (2201 bytes)

Download attachment "overlayfs-v14_tested-by-dileks.tar.xz" of type "application/octet-stream" (107384 bytes)

Download attachment "overlayfs-v14_tested-by-dileks.tar.xz.sha256sum" of type "application/octet-stream" (104 bytes)