linux-kernel - Re: [PATCH v2] w1:fix byteorder of W1_READ

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

Message-Id: <265491504618761@web52g.yandex.ru>
Date:   Tue, 05 Sep 2017 16:39:21 +0300
From:   Evgeniy Polyakov <zbr@...emap.net>
To:     "chen.lin5@....com.cn" <chen.lin5@....com.cn>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "jiang.biao2@....com.cn" <jiang.biao2@....com.cn>
Subject: Re: [PATCH v2] w1:fix byteorder of W1_READ_ROM id under big-endian cpu

Hi

28.08.2017, 12:25, "chen.lin5@....com.cn" <chen.lin5@....com.cn>:
> Hi
>
> Q:
>
> But w1_reg_num has a different layout for be/le systems, isn't it enough?
>
> A:
>
> sure, it's right only under the assumption that 'rn' is a  correct layout id.
>
> Here's my example in be system which I encounter before.
>
> buf[0] return from w1_read_8(dev) in code section2 will always be 'family:8', buf[0] store at the first byte of rn, then it will be transport to cb(dev, rn) in code section1,
>
> but it will be parsed to 'crc:8' of the struct w1_reg_num in be system, then there comes the wrong.

Sorry, I do not understand. Do you mean that there is a difference between 2 ways to read ID content in w1_read_block() ?
If it is the case, is it possible, that there is a bug in particular master implementation?

There is a fair number of be devices in the tree already, and no one yet reported that there is an endian issue.