Received-SPF: pass (google.com: domain of linux-kernel+bounces-73702-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Message-ID: <91f600ef-867b-4523-89be-1c0ba34f8a4c@kunbus.com>
Date: Tue, 20 Feb 2024 21:54:45 +0100
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/3] tpm: protect against locality counter underflow
Content-Language: en-US
To: Alexander Steffen <Alexander.Steffen@infineon.com>,
 Jarkko Sakkinen <jarkko@kernel.org>,
 "Daniel P. Smith" <dpsmith@apertussolutions.com>,
 Jason Gunthorpe <jgg@ziepe.ca>, Sasha Levin <sashal@kernel.org>,
 linux-integrity@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Ross Philipson <ross.philipson@oracle.com>,
 Kanth Ghatraju <kanth.ghatraju@oracle.com>, Peter Huewe <peterhuewe@gmx.de>
References: <20240131170824.6183-1-dpsmith@apertussolutions.com>
 <20240131170824.6183-2-dpsmith@apertussolutions.com>
 <CYU3CFW08DAA.29DJY7SJYPJJZ@suppilovahvero>
 <2ba9a96e-f93b-48e2-9ca0-48318af7f9b1@kunbus.com>
 <ae3fecc4-7b76-4607-8749-045e17941923@infineon.com>
From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
In-Reply-To: <ae3fecc4-7b76-4607-8749-045e17941923@infineon.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?OTc0cFBQd29WUVBVTGNNSCt6MnJOWU95Uk1PSlpBZURzNkJ1c0t6MjNEVmJy?=
 =?utf-8?B?eEduL2FkNnR3SGM5TXM4ckYrTC9ldUxVUUxDL2Y5N0tTV29CbnppUnJKNUs4?=
 =?utf-8?B?bUJTb3VZc1dMSitKYzIza2NiemIxZUdsWkNyQ1VsckQrQy8wNnlSTFhZMnpD?=
 =?utf-8?B?VXFJN2J2UGY3QnQ5SndtZVloN3FKZ0hVUythMml6bmgzdnA5ZXRGWUZCQ3I4?=
 =?utf-8?B?bGxVRmRRSHl4WWViNGcrcGhYc1M0K09wSms0cnJyUWRSNUdISmFXUFc3cHpk?=
 =?utf-8?B?OWcxVEl3MmlPajRqRmRnMVdLRTAxL29sMXRrc2FJc1lTd0tvajN0S2VvdDlv?=
 =?utf-8?B?d1JqeUxrTUpsTlJCUmpFemExcWdwWHIwNGNsNmxoL0JVZ3RrYTU4NTlwRFpH?=
 =?utf-8?B?RHdkbTBaZGxxVjJyemxibjVXYlg4bEs1T3haNHpUSURhZGFCRDZTbjA3NGg1?=
 =?utf-8?B?anlaVlBORXF3RTA1UnRZMno3ZTdGZER1Sm1yZkhORkcxS2ltZSt0TGYwSWZk?=
 =?utf-8?B?Z2xkSEErVkxYVmRvS0M4d1p0bnJKMXNRdVhhVFFIakZVQnJNaHhqVDRFeEN2?=
 =?utf-8?B?RzBWbEJXZXJ6QnhXZXVyNW9mbGxiRlNFSUZHaWx3b1FUMk1XUDIvT0tHMEps?=
 =?utf-8?B?OVhlVElxcjRneVhSUGlpeHBGNHJoamJreEg5TG93YnhtZTBWOWJrM3BGVExX?=
 =?utf-8?B?dGhoY3lwTHNmcklXTWRPVXEzRFVNVXlsYndubk9nU0FFSDZsWERDMS9WZ0Z5?=
 =?utf-8?B?VVVJenlwQzhFbEpCd0JLVnVWOVRnUzZVWXRCbkx0eXgya0JPRmxnK3Bhbjhx?=
 =?utf-8?B?dWFNdWt4dkU4YkFRYXg4dnlMRUlTS1l4R1dVYTRwUjNEOEY5RTQ0M3ZTMVVp?=
 =?utf-8?B?UVdIcEtKR3NhMFRMcGdVUEpnUTF4RmJjc0dzc1VSQ080cExVUlRMdEp2M3Zj?=
 =?utf-8?B?ZzAyeVNNWk5MYjRSRFFJNUR5QVc4NEhwZ0huZGFsckFiM3FJZFNKeWxkdmJR?=
 =?utf-8?B?cG5SOUs4VzRaS2FaNVk4ZlRhZmFzQW1rdVFyM05Lck8veHJFRllnZnppb0ty?=
 =?utf-8?B?eU51ZitzQ0FWcG1mZ2h6TDlSSTFwcU8yaU1BMk8vb3FTTzVxT1pKMjR1UXV5?=
 =?utf-8?B?dXd4aVJ6bUIzWG93aHBxa0gzcE9wLy9sYUNTa2Y1dXU3dGh1bkFZUk1tZjVD?=
 =?utf-8?B?UVpVZ2tUa01seWE3ZXZaUUllalJaVkx4N0o1LzZVbW96NEFwWE0zc05tZ0xi?=
 =?utf-8?B?VWcxOGgweFpSelVTRXBUSWRtZDF0T21CNGxXS2ZRZVh5VTlyZDBMSWxUb3lv?=
 =?utf-8?B?Y20rRnM2NHA0bHZhcE96RURDQTJQVkp1UVphcW5jdFp2MnRpVnZBWkVqMGRk?=
 =?utf-8?B?Nnl4dk4vTThOQWl6VE9qQTNvdFdvNXk2cGFubzdZd01BNXc3Z0VHK29VamZ4?=
 =?utf-8?B?dFRRem8rQXFNTlVJZmFpTEZteHA5Qm54TmcwVzdRUkVuRGwyd2lYL1V6cURR?=
 =?utf-8?B?dzRsS2d3M2x2Wllaak1vUnZSYm9VdzRHZGZNV0VOTERJK1dpN1RnSUpFWmZo?=
 =?utf-8?B?NGwrRFZ4Smh1UTZ1T0UyWG1PdTFYdGU3Rm5qZi9acisrMlBUV0JrSWJaa1ZY?=
 =?utf-8?B?SE93WWdxb1ZNSmdOZjJGT2F6ZTY0RWJKWXV6eC92bGpFV3FsNk1kM2pGTGNv?=
 =?utf-8?B?VVdicWx5YWNCVDltMWdjbHlyYnBRNTI0MW9VNG55VXBERTdvcFhKUDl0VW1m?=
 =?utf-8?B?SHA2QnU4cGlCTnFSckJTbXNGWHZUUkNPWUtCNkhVQVNXWmdsaGdqNXhFVTZD?=
 =?utf-8?B?YkhIZ1pOVFlscGQ3V0xPa1kwTjFXc1R4SEJiMGdqOTc2cW0zYW84d3VCZTRQ?=
 =?utf-8?B?SVlEN3J0cDNaQmV3cEt1NUpLR1QrNzF0dUt4Z3RndlU1b0gyZ0VKWXVHNVlP?=
 =?utf-8?B?REE4aE5nSWp0ekhZSGljZzIwdU1mb21qaU5xbEx3bGx0UkhVbUpQd2FrT3dv?=
 =?utf-8?B?K3pydjhXWmZzR0FkazlwNVdRUng5VTZiUnMxS3NVMUlzaFIzZ3dTKzdCRjg2?=
 =?utf-8?B?LzBXckRKMXZFalRURWlmbVpKbjc4SGFCTFJ4RGxxU2g3TDVJQXEycHlaeXBo?=
 =?utf-8?B?RUh0NEtXWXJNMWlqb3hZd0toRXBxYk5BMStDdG44YmVmTzYwYUtOOGF2N0U2?=
 =?utf-8?B?LzBuRm1TQ2ptUjk3VDQvdGJMM01meTBMK0hBRlloSGxDL1pmVkEyMTA0VnFG?=
 =?utf-8?B?MDNseDNFa01wczkxUzhlcmgvU3NBPT0=?=
X-OriginatorOrg: kunbus.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 134f3d96-ffa1-469b-0c75-08dc32562d03
X-MS-Exchange-CrossTenant-AuthSource: VI1P193MB0413.EURP193.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Feb 2024 20:54:48.5151
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: aaa4d814-e659-4b0a-9698-1c671f11520b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: OwcINVKhUbsHwn14o2ieXSHIiy6FVZKIWLy5v8nnAwCOq83X7ow6VXfbASEKyyRUB9MlggWAbeJuzKMMj/ygKQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR3P193MB0764

Hi,

On 20.02.24 19:42, Alexander Steffen wrote:
> ATTENTION: This e-mail is from an external sender. Please check attachments and links before opening e.g. with mouseover.
> 
> 
> On 02.02.2024 04:08, Lino Sanfilippo wrote:
>> On 01.02.24 23:21, Jarkko Sakkinen wrote:
>>
>>>
>>> On Wed Jan 31, 2024 at 7:08 PM EET, Daniel P. Smith wrote:
>>>> Commit 933bfc5ad213 introduced the use of a locality counter to control when a
>>>> locality request is allowed to be sent to the TPM. In the commit, the counter
>>>> is indiscriminately decremented. Thus creating a situation for an integer
>>>> underflow of the counter.
>>>
>>> What is the sequence of events that leads to this triggering the
>>> underflow? This information should be represent in the commit message.
>>>
>>
>> AFAIU this is:
>>
>> 1. We start with a locality_counter of 0 and then we call tpm_tis_request_locality()
>> for the first time, but since a locality is (unexpectedly) already active
>> check_locality() and consequently __tpm_tis_request_locality() return "true".
> 
> check_locality() returns true, but __tpm_tis_request_locality() returns
> the requested locality. Currently, this is always 0, so the check for
> !ret will always correctly indicate success and increment the
> locality_count.
> 

Will the TPM TIS CORE ever (have to) request another locality than 0? Maybe the best would
be to hardcode TPM_ACCESS(0) and get rid of all the locality parameters that are
passed from one function to another.
But this is rather code optimization and not really required to fix the reported bug.

As I already wrote in a former comment, the actual bug fix would IMHO simply be to
make sure that no localities are held at the beginning of tpm_tis_core_init():

for (i = 0; i <= MAX_LOCALITY; i++)
	__tpm_tis_relinquish_locality(priv, i);

before wait_startup() should be sufficient.

Regards,
Lino