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]
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ń

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ