From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751361AbdA0UY1 (ORCPT ); Fri, 27 Jan 2017 15:24:27 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:50096 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751342AbdA0UYO (ORCPT ); Fri, 27 Jan 2017 15:24:14 -0500 Subject: Re: ibmvtpm byteswapping inconsistency To: Benjamin Herrenschmidt , =?UTF-8?Q?Michal_Such=c3=a1nek?= , Ashley Lai , Paul Mackerras , Michael Ellerman , Peter Huewe , Marcel Selhorst , Jarkko Sakkinen , Jason Gunthorpe , tpmdd-devel@lists.sourceforge.net, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org References: <20170126212248.3f3e9103@kitsune.suse.cz> <1485481819.2980.82.camel@kernel.crashing.org> From: Tyrel Datwyler Date: Fri, 27 Jan 2017 10:02:34 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <1485481819.2980.82.camel@kernel.crashing.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 17012718-0024-0000-0000-000015D115E6 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00006508; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000201; SDB=6.00813544; UDB=6.00396882; IPR=6.00590959; BA=6.00005093; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00014074; XFM=3.00000011; UTC=2017-01-27 18:02:42 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17012718-0025-0000-0000-00004851F0D2 Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-01-27_13:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1701270176 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/26/2017 05:50 PM, Benjamin Herrenschmidt wrote: > On Thu, 2017-01-26 at 17:42 -0800, Tyrel Datwyler wrote: >> On 01/26/2017 12:22 PM, Michal Suchánek wrote: >>> Hello, >>> >>> building ibmvtpm I noticed gcc warning complaining that second word >>> of >>> struct ibmvtpm_crq in tpm_ibmvtpm_suspend is uninitialized. >>> >>> The structure is defined as >>> >>> struct ibmvtpm_crq { >>> u8 valid; >>> u8 msg; >>> __be16 len; >>> __be32 data; >>> __be64 reserved; >>> } __attribute__((packed, aligned(8))); >>> >>> initialized as >>> >>> struct ibmvtpm_crq crq; >>> u64 *buf = (u64 *) &crq; >>> ... >>> crq.valid = (u8)IBMVTPM_VALID_CMD; >>> crq.msg = (u8)VTPM_PREPARE_TO_SUSPEND; >>> >>> and submitted with >>> >>> rc = ibmvtpm_send_crq(ibmvtpm->vdev, cpu_to_be64(buf[0]), >>> cpu_to_be64(buf[1])); >> >> These should be be64_to_cpu() here. The underlying hcall made by >> ibmvtpm_send_crq() requires parameters to be in cpu endian unlike the >> RTAS interface which requires data in BE. > > Hrm... an hcall takes register arguments. Register arguments don't have > an endianness. I wasn't suggesting that they do. However, I still believe my point is valid that the arguments need to be loaded into the registers according to the endianness of the cpu. We had several bugs during LE porting where assumptions were made that parameters should be loaded BE regardless of cpu endian. For example: commit 3df76a9dcc74d5f012b94ea01ed6e7aaf8362c5a Author: Cyril Bur Date: Wed Jan 21 13:32:00 2015 +1100 powerpc/pseries: Fix endian problems with LE migration RTAS events require arguments be passed in big endian while hypercalls have their arguments passed in registers and the values should therefore be in CPU endian. > > The problem is that we are packing an in-memory structure into 2 > registers and it's expected that this structure is laid out in the > registers as if it had been loaded by a BE CPU. This is only the case if the cpu is BE. If the cpu is LE, regardless of the fact that our in memory structure is laid out BE, when we break it into 2 words each of those words needs to be loaded LE. -Tyrel > > So we have two things at play here: > > - The >8-bit fields should be laid out BE in the memory image > - That whole 128-bit structure should be loaded into 2 64-bit > registers MSB first. > > So the "double" swap is somewhat needed. The uglyness comes from the > passing-by-register of the h-call but it should work. > > That said, be64_to_cpup(buf) and be64_to_cpup(buf+1) might give you > better result (though recent gcc's might not make a difference). >>> >>> which means that the second word indeed contains purely garbage. >>> >>> This is repeated a few times in the driver so I added memset to >>> quiet >>> gcc and make behavior deterministic in case the unused fields get >>> some >>> meaning in the future. >>> >>> However, in tpm_ibmvtpm_send the structure is initialized as >>> >>> struct ibmvtpm_crq crq; >>> __be64 *word = (__be64 *)&crq; >>> ... >>> crq.valid = (u8)IBMVTPM_VALID_CMD; >>> crq.msg = (u8)VTPM_TPM_COMMAND; >>> crq.len = cpu_to_be16(count); >>> crq.data = cpu_to_be32(ibmvtpm->rtce_dma_handle); >>> >>> and submitted with >>> >>> rc = ibmvtpm_send_crq(ibmvtpm->vdev, be64_to_cpu(word[0]), >>> be64_to_cpu(word[1])); >>> meaning it is swapped twice. >>> >>> >>> Where is the interface defined? Are the command arguments passed as >>> BE >>> subfields (the second case was correct before adding the extra >>> whole >>> word swap) or BE words (the first case doing whole word swap is >>> correct)? >> >> The interface is defined in PAPR. The crq format is defined in BE >> terms. >> However, when we break the crq apart into high and low words they >> need >> to be in cpu endian as mentioned above. >> >> -Tyrel >> >>> >>> Thanks >>> >>> Michal >>> >