linux-kernel - Re: Variant symlink filesystem

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: <CACsf_wwWZvu7YFomfB6S=iA24yFxjW9YcsDCmQTuPHod8+emCw@mail.gmail.com>
Date:	Fri, 11 Mar 2016 22:22:13 +0200
From:	Cole <cole@...eqint.net>
To:	Richard Weinberger <richard@....at>
Cc:	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Variant symlink filesystem

On 11 March 2016 at 22:18, Richard Weinberger <richard@....at> wrote:
> Am 11.03.2016 um 21:15 schrieb Cole:
>> On 11 March 2016 at 22:04, Richard Weinberger
>> <richard.weinberger@...il.com> wrote:
>>> On Fri, Mar 11, 2016 at 5:20 PM, Cole <cole@...eqint.net> wrote:
>>>> Hi,
>>>>
>>>> I have written a Variant Symlink Filesystem for linux, currently
>>>> implemented as a kernel module:
>>>> https://github.com/onslauth/varsymfs
>>>> The code was written for the 3.x kernel.
>>>>
>>>> I would like to try to get this included into the linux kernel, and am
>>>> willing to hand over all copyright and change the license as needed.
>>>> As such, I would like to know what I can do to try to make this
>>>> happen.
>>>>
>>>> If the code quality or standards are not up to par with those of the
>>>> linux kernel, or code needs to change due to newer changes introduced
>>>> into the kernel, please let me know and I will endeavour to make the
>>>> necessary changes.
>>>>
>>>> Please can you also cc me in any replies, as I am not currently
>>>> subscribed to the list.
>>>
>>> Why does this need to be a kernel filesystem and not a filesystem in
>>> userspace (FUSE)?
>>> Especially as you are dealing with environment variables which are
>>> owned and controlled
>>> by userspace.
>>
>> The original implementation was in fuse, to prove the concept. However,
>> because we are compiling, as well as running programs and reading/writing
>> files inside of this path, the performance loss is too great. Therefore we
>> moved to this solution.
>
> Before giving up and going to kernelspace you could try improving the root cause of the performance loss. :)
> Maybe the kernel interface for finding the env variables can be speeded up.

If I remember correctly, when we were testing the fuse version, we hard coded
the path to see if that solved the problem, and the difference between
the env lookup
code and the hard coded path was almost the same, but substantially slower than
the native file system.

Regards
/Cole