Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1069413pxb; Thu, 4 Mar 2021 02:23:50 -0800 (PST) X-Google-Smtp-Source: ABdhPJx3RyM96m2nadukkSqF9sl8g8uo0Nu3w7O8M/YtrmEJROOFRGDkFYbV+H4RMCxqnf78BOYt X-Received: by 2002:a05:6402:158d:: with SMTP id c13mr3413416edv.297.1614853430556; Thu, 04 Mar 2021 02:23:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614853430; cv=none; d=google.com; s=arc-20160816; b=nnEobn8Cos3xDZvQCaQ88mWvXDUBIaAqg7beE66cNJua1PH1PCfgQxfvFK/oA31eXP W1k811ReiRndZ783Ulddbk+KLLSaRJi+L4G/9/nU2+zAnziqNfbsAnVBeZY5ThhR4Hti hegK24uBGVSptDhjU1N4Q+hRhHlKWGcv/kSUCpgLbsTpCxFGWrBWIWOvvN8gx3hmGFxp 6AJoZT/P8eLVsv9VZV5D9PfelkaUdulNw09GpCS1kHIJgaTCeLP3cJRBifZtigvxjgMP pgL39+HVuKMXojWc8Dlw8ipojA0aOQtTn7VnrR4GT/kOrdgwYctUybmTdUkAwHtNn8BS nJ8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=FyeaoBaYtA8Okmk3JT5jzGJzKiiQIAhzEdSQL3sGFAE=; b=vzwpfkoo5SKT0LRujs2FDeSYfzlR7vaNMIvd0QK3KH6wJPs3QvnAwcQjSAj8aib9yE B2z4LX7LXnZxGQGccei3uhjusXjphXTE4yiaA9ijDLZbE5V+mnzwFcs+QsfXYLVkuPVb T2/gDnFy3iUCVt+TCJ6DMoM2wEToFRAzCqB8uieeNxFqdGJMmIsB1wm0KTG71VsWY0ZB pgpOCgnyG8owOPf/KUgo7zF6nwP5Nr838dPklazDXvsGPuWsgkPwQq0KzDTLvoD53SXx cQ/SP8qFlh7CnQFIR07OEddfnv7QUg9toKla+VFMhqujy4DWgt3EF2V208TjtoKseaqz CZ+A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id hb37si2459781ejc.81.2021.03.04.02.23.27; Thu, 04 Mar 2021 02:23:50 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1444422AbhCCQkz (ORCPT + 99 others); Wed, 3 Mar 2021 11:40:55 -0500 Received: from out30-56.freemail.mail.aliyun.com ([115.124.30.56]:48432 "EHLO out30-56.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1356800AbhCCMNb (ORCPT ); Wed, 3 Mar 2021 07:13:31 -0500 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R211e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=alimailimapcm10staff010182156082;MF=tianjia.zhang@linux.alibaba.com;NM=1;PH=DS;RN=12;SR=0;TI=SMTPD_---0UQGMJow_1614773561; Received: from B-455UMD6M-2027.local(mailfrom:tianjia.zhang@linux.alibaba.com fp:SMTPD_---0UQGMJow_1614773561) by smtp.aliyun-inc.com(127.0.0.1); Wed, 03 Mar 2021 20:12:42 +0800 Subject: Re: [PATCH] selftests/sgx: fix EINIT failure dueto SGX_INVALID_SIGNATURE To: Jarkko Sakkinen Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Sean Christopherson , Shuah Khan , x86@kernel.org, linux-sgx@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, Jia Zhang References: <20210301051836.30738-1-tianjia.zhang@linux.alibaba.com> <3bcdcf04-4bed-ed95-84b6-790675f18240@linux.alibaba.com> From: Tianjia Zhang Message-ID: Date: Wed, 3 Mar 2021 20:12:41 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3/2/21 8:51 PM, Jarkko Sakkinen wrote: > Nit: "due to" > > Start with capital letter "Fix" > Will do in the next patch. > On Tue, Mar 02, 2021 at 01:06:52PM +0800, Tianjia Zhang wrote: >> >> >> On 3/1/21 5:54 PM, Jarkko Sakkinen wrote: >>> On Mon, Mar 01, 2021 at 01:18:36PM +0800, Tianjia Zhang wrote: >>>> q2 is not always 384-byte length. Sometimes it only has 383-byte. >>> >>> What does determine this? >>> >>>> In this case, the valid portion of q2 is reordered reversely for >>>> little endian order, and the remaining portion is filled with zero. >>> >>> I'm presuming that you want to say "In this case, q2 needs to be reversed because...". >>> >>> I'm lacking these details: >>> >>> 1. Why the length of Q2 can vary? >>> 2. Why reversing the bytes is the correct measure to counter-measure >>> this variation? >>> >>> /Jarkko >>> >> >> When use openssl to generate a key instead of using the built-in >> sign_key.pem, there is a probability that will encounter this problem. >> >> Here is a problematic key I encountered. The calculated q1 and q2 of this >> key are both 383 bytes, If the length is not processed, the hardware >> signature will fail. > > Why is reversing bytes the correct way to fix the issue? > This is caused by the incorrect length of the reversed data. If the length of q2 is 383 bytes, the inversion will cause the first byte to be zero. For this, please refer to the signature tool in sgx sdk: https://github.com/intel/linux-sgx/blob/master/sdk/sign_tool/SignTool/sign_tool.cpp#L381 If it can be repaired, it may be possible to use to generate sign_key.pem key on fly instead of using the static key. Best regards, Tianjia