linux-kernel - Re: ibmvtpm byteswapping inconsistency

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:   Tue, 31 Jan 2017 19:38:32 +1100
From:   Michael Ellerman <mpe@...erman.id.au>
To:     Tyrel Datwyler <tyreld@...ux.vnet.ibm.com>,
        Tyrel Datwyler <tyreld@...ux.vnet.ibm.com>,
        Michal Suchanek <hramrach@...il.com>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc:     Marcel Selhorst <tpmdd@...horst.net>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
        Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
        tpmdd-devel@...ts.sourceforge.net,
        Paul Mackerras <paulus@...ba.org>,
        Ashley Lai <ashleydlai@...il.com>,
        Peter Huewe <peterhuewe@....de>,
        Michal Suchánek <msuchanek@...e.de>,
        linuxppc-dev@...ts.ozlabs.org
Subject: Re: ibmvtpm byteswapping inconsistency

Tyrel Datwyler <tyreld@...ux.vnet.ibm.com> writes:
> On 01/29/2017 08:32 PM, Michael Ellerman wrote:
>> Tyrel Datwyler <tyreld@...ux.vnet.ibm.com> writes:
>>>
>>> Byte  |   0   |   1   |   2   |   3   |   4   |   5   |   6   |   7
>>> -----------------------------------------------------------------------
>>> Word0 | Valid | Type  |     Length    |              Data
>>> -----------------------------------------------------------------------
>>> Word1 |				Reserved
>>> -----------------------------------------------------------------------
>>>
>>> The following definition looks to match:
>>>
>>> struct ibmvtpm_crq {
>>>         u8 valid;
>>>         u8 msg;
>>>         __be16 len;
>>>         __be32 data;
>>>         __be64 reserved;
>>> } __attribute__((packed, aligned(8)));
>> 
>> Well it's a partial match.
>> 
>> Your layout above doesn't define which byte of Length or Data is the MSB
>> or LSB. So going by that we still don't know the endianness of either
>
> I should have been explicit that PAPR uses Big Endian bit and byte
> numbering throughout the spec unless otherwise noted.

OK. I didn't actually remember that so yeah good to be explicit.

cheers