linux-kernel - Re: [RFC] mtd: Fix error code loss in mtdchar

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, 25 Sep 2023 11:14:40 +0200 (CEST)
From:   Richard Weinberger <richard@....at>
To:     ZhaoLong Wang <wangzhaolong1@...wei.com>
Cc:     Vignesh Raghavendra <vigneshr@...com>,
        linux-mtd <linux-mtd@...ts.infradead.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        chengzhihao1 <chengzhihao1@...wei.com>,
        yi zhang <yi.zhang@...wei.com>, yangerkun@...wei.com,
        Miquel Raynal <miquel.raynal@...tlin.com>
Subject: Re: [RFC] mtd: Fix error code loss in mtdchar_read() function.

----- Ursprüngliche Mail -----
>> 'total_retlen' is 0, not the error code.
> 
> Actually after looking at the code, I have no strong opinion
> regarding whether we should return 0 or an error code in this case.
> 
> There is this comment right above, and I'm not sure it is still up to
> date because I believe many drivers just don't provide the data upon
> ECC error:
> 
>                /* Nand returns -EBADMSG on ECC errors, but it returns
>                 * the data. For our userspace tools it is important
>                 * to dump areas with ECC errors!
>                 * For kernel internal usage it also might return -EUCLEAN
>                 * to signal the caller that a bitflip has occurred and has
>                 * been corrected by the ECC algorithm.
>                 * Userspace software which accesses NAND this way
>                 * must be aware of the fact that it deals with NAND
>                 */
> 
>> This problem causes the user-space program to encounter EOF when it has
>> not finished reading the mtd partion, and this also violates the read
>> system call standard in POSIX.

This is a special purpose device file and not a regular file.
Please explain in detail why this violates POSIX and which program breaks.

As pointed out by Miquel, the comment makes it clean that this behavior is
on purpose. If we return now all of a sudden -EBADMSG for the described
scenario we might even break existing MTD userspace.

Thanks,
//richard