Received-SPF: pass (google.com: domain of linux-kernel+bounces-79434-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: <f1257a02-e383-484f-a0c4-90ac5b870dc1@gmx.de>
Date: Sat, 24 Feb 2024 03:06:44 +0100
Precedence: bulk
MIME-Version: 1.0
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>,
 Lino Sanfilippo <l.sanfilippo@kunbus.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 <LinoSanfilippo@gmx.de>
In-Reply-To: <ae3fecc4-7b76-4607-8749-045e17941923@infineon.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
UI-OutboundReport: notjunk:1;M01:P0:nCj0f9L+1XM=;ux8VvHNJspF81voaqysoH4iLjZM
 lCmbCZu7U1aTJrzeBM0/XWD5i8qlnzBBiSYiuUKqPab0Y3OL4GcGCLDQPkT7eqr8HZ6r/8LW5
 gNA44Rj3QUR4WsY4UBZLgZVZ1FIjdaZwGCSVC9K9B382FYraz6KwzbbQSNjj0KkOB3FJjFp9Z
 zEXRl2NVrzxpnKm5tiOiBk3do09jLmUcVMzHcigqliL0T4rq5tacX5UcaiKTD4uERITN1deDJ
 cjk+5uT+HCSAZ6am916dmLwGVdRF/MxcyRr/d5z9rZ9AwLkigkWsKFzgJCRzFeZI4bpVlQLUw
 nhSc25cZTLU2mM/etGpWlOD1r/EkWCsd/HfMcLCu+grKCXmUf4DEsSw+xH2SCB77AImg6wUTi
 jaP0CI7WF81D8oRn5bk2jR0D7mnJK3akSe02CuvBYv26ubzvz5TYHIr/Z2Khq61ZKlGI1MLrQ
 R+K+5tiOh2gLEmtVbvPbsry0tF7BBolaUmZOAUuWnJiphZQmtBgmGSCQh9ARyacmGgWhoYjbZ
 ZgLrvpgfmSWkH1Wee5ZavdqynAcqJNs3Slln5aobsHVSZnXCawZWAXQZEoR/gU7ItYECi8lgb
 1m3wBX8pXQ6Jdo8BiSRUItMSaABnmcryDRnn1OdlAI0TmbvLH++F+dGrPVFrhmDaWPWYR6JtT
 dEzdjhXpV15hkhdftaZhjuGMP4ujbJvwutR1mUeybLF+cz8nUuOwS5awve0sKcLdcMIMuYLHp
 QHuknEXYE/zX7HIVs5RBGBPXUJLrGu2dYR8b4ag9Qo2t+iR9Y1ZUirj8p/lw7pYa+RaqyyuhM
 WvwqxlnDanIetDTDDvkrbJUW6r4QPDIlGaO6G0pxEXt+8=


Hi,

On 20.02.24 19:42, Alexander Steffen wrote:
> 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 contr=
ol 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 int=
eger
>>>> 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_reque=
st_locality()
>> for the first time, but since a locality is (unexpectedly) already acti=
ve
>> 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.

So how was the reported underflow triggered then? We only request locality=
 0 in TPM TIS core, no other locality.

>
> But since theoretically a locality !=3D 0 could be requested, the correc=
t fix would be to check for something like ret >=3D 0 or ret =3D=3D l inst=
ead of !ret.

I thought that the underflow issue has actually been triggered and is not =
only a theoretical problem.
But now I wonder how this could ever happen.

BR,
Lino