linux-kernel - Re: [PATCH] Revert "firmware: qcom: qseecom: convert to using the TZ allocator"

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMRc=MecyZU6DBWjg7vtohhxtVoaOR6jCRHdEiAKinqvmEtDyQ@mail.gmail.com>
Date: Tue, 30 Jul 2024 13:35:28 +0200
From: Bartosz Golaszewski <brgl@...ev.pl>
To: Johan Hovold <johan@...nel.org>
Cc: Johan Hovold <johan+linaro@...nel.org>, Maximilian Luz <luzmaximilian@...il.com>, 
	Bjorn Andersson <andersson@...nel.org>, Konrad Dybcio <konrad.dybcio@...aro.org>, 
	Amirreza Zarrabi <quic_azarrabi@...cinc.com>, 
	Bartosz Golaszewski <bartosz.golaszewski@...aro.org>, Elliot Berman <quic_eberman@...cinc.com>, 
	linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org, 
	regressions@...ts.linux.dev
Subject: Re: [PATCH] Revert "firmware: qcom: qseecom: convert to using the TZ allocator"

On Mon, Jul 29, 2024 at 2:49 PM Johan Hovold <johan@...nel.org> wrote:
>
> On Mon, Jul 29, 2024 at 02:35:39PM +0200, Bartosz Golaszewski wrote:
> > > > On Mon, Jul 29, 2024 at 11:58 AM Johan Hovold <johan+linaro@...nel.org> wrote:
> > > > >
> > > > > This reverts commit 6612103ec35af6058bb85ab24dae28e119b3c055.
> > > > >
> > > > > Using the "TZ allocator" for qcseecom breaks efivars on machines like
> > > > > the Lenovo ThinkPad X13s and x1e80100 CRD:
> > > > >
> > > > >         qcom_scm firmware:scm: qseecom: scm call failed with error -22
>
> > How do you reproduce this on x1e?
>
> Just boot 6.11-rc1 and you should see the above error (and there are no
> variables under /sys/firmware/efi/efivars/).
>
> Johan

I'm trying to figure out what the difference is with and without
tzmem. Surprisingly the physical address passed down to the SCM call
is actually the same in both cases.

I figured that maybe using different struct device for the underlying
dma_alloc_coherent() would be the culprit but I checked and no.

I'm still on it.

Bart