linux-kernel - Re: [PATCH v3 4/4] mtdchar: add MEMREAD ioctl

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: <Ygo6dNsVn1Y6c3PJ@larwa.hq.kempniu.pl>
Date:   Mon, 14 Feb 2022 12:18:12 +0100
From:   Michał Kępień <kernel@...pniu.pl>
To:     Richard Weinberger <richard@....at>
Cc:     Miquel Raynal <miquel.raynal@...tlin.com>,
        Vignesh Raghavendra <vigneshr@...com>,
        Boris Brezillon <boris.brezillon@...labora.com>,
        linux-mtd <linux-mtd@...ts.infradead.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 4/4] mtdchar: add MEMREAD ioctl

> >> If mtd->erasesize is large (which is not uncommon these days) you might
> >> request more from kmalloc() than it can serve.
> >> Maybe kvmalloc() makes more sense?
> > 
> > Mmmh, I would really like these buffers dma-able.
> > 
> > I just discovered mtd_kmalloc_up_to(). Would this work?
> 
> mtd_kmalloc_up_to() makes sense to be more friendly to the system.
> It tries to get memory without forcing write-back and such.
> But if we're out of continuous memory it won't help much. 
> 
> Regarding dma-able, as soon you use something like UBI/UBIFS ontop of it
> the mtd driver has to be able to deal in any way with vmalloc()'ed memory.

Note that the MEMWRITE ioctl is affected by the same issue.  Judging
from the discussion above, I assume a separate patch is in order to turn
kmalloc() calls in mtdchar_write_ioctl() into kvmalloc() calls?

> Another option would be not working on full erase blocks.

Right, the approach proposed in this patch series and also previously in
commit f6562bca84d22525f792305e3106571f8714d057 ("mtdchar: prevent
unbounded allocation in MEMWRITE ioctl") is a trade-off.  I followed a
suggestion I heard earlier:

https://lists.infradead.org/pipermail/linux-mtd/2021-September/088485.html

-- 
Best regards,
Michał Kępień