linux-kernel - Re: [PATCH 0/5] [RFC] MUSE: Userspace backed MTD

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] [day] [month] [year] [list]

Message-ID: <728548959.34116.1606346025135.JavaMail.zimbra@nod.at>
Date:   Thu, 26 Nov 2020 00:13:45 +0100 (CET)
From:   Richard Weinberger <richard@....at>
To:     Miklos Szeredi <miklos@...redi.hu>
Cc:     Miquel Raynal <miquel.raynal@...tlin.com>,
        Vignesh Raghavendra <vigneshr@...com>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        linux-mtd <linux-mtd@...ts.infradead.org>
Subject: Re: [PATCH 0/5] [RFC] MUSE: Userspace backed MTD

----- Ursprüngliche Mail -----
> When working with flash devices a common task is emulating them to run various
> tests or inspect dumps from real hardware. To achieve that we have plenty of
> emulators in the mtd subsystem: mtdram, block2mtd, nandsim.
> 
> Each of them implements a adhoc MTD and have various drawbacks.
> Over the last years some developers tried to extend them but these attempts
> often got rejected because they added just more adhoc feature instead of
> addressing overall problems.
> 
> MUSE is a novel approach to address the need of advanced MTD emulators.
> Advanced means in this context supporting different (vendor specific) image
> formats, different ways for fault injection (fuzzing) and recoding/replaying
> IOs to emulate power cuts.
> 
> The core goal of MUSE is having the complexity on the userspace side and
> only a small MTD driver in kernelspace.
> While playing with different approaches I realized that FUSE offers everything
> we need. So MUSE is a little like CUSE except that it does not implement a
> bare character device but an MTD.
> 
> To get early feedback I'm sending this series as RFC, so don't consider it as
> ready to merge yet.
> 
> Open issues are:
> 
> 1. Dummy file object
> The logic around fuse_direct_io() expects a file object.
> Unlike FUSE or CUSE we don't have such an object in MUSE because usually an
> MTD is not opened by userspace. The kernel uses the MTD and makes it available
> to filesystems or other layers such as mtdblock, mtdchar or UBI.
> Currently a anon inode is (ab)used for that.
> Maybe there is a better way?

FYI, I'll send an updated series soon. I rewrote the MUSE IO path to not use fuse_direct_io()
which made things much simpler and all hacks go away.

Thanks,
//richard