Re: [PATCH 1/1] arm64: dts: qcom: msm8994: Reserve gpio ranges

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> > Konrad, is there any public docs about GPIOs on this secure peripherals?
> > It it somehow related to Chain of Trust? [1].  I guess it's not, because once we
> > boot Linux all bootloader stuff is over.

> No, Qualcomm pretty much does security through obscurity. It's *probably* not even that very secure considering how big in size their TZ+HYP stack is - number of bugs rises exponentially with code size. But not many people tried breaking into it considering the complexity and QCOM's legal team size.

> There is no public documentation on that, and even if there were - you are not allowed to flash the "secure" partitions on *your device that you unlocked the bootloader of by choice* (which is absurd).

> Also, while "all bootloader stuff is over", the platform is still under control of the proprietary hypervisor and the "Trust Zone". For example if you try to write to some IOMMU registers on certain platforms, the hypervisor will treat that as a security violation and shut down the entire device. 

> This is essentially the same as your issue. You're trying to poke a thing that Qualcomm *really* doesn't want you to (the fingerprint SPI pins) and since *they* are in control, they say "nonono" and your device dies. All you can do is comply with that (or find a way to replace the blobs or politely ask Google to release a set of unsecure binaries for your Nexus - which they won't do).

Again, thanks a lot for info. I looked into downstream sources to see that
really pins 85-88 (which I've sent a patch to add into gpio-reserved-ranges) are
used for fingerprint. I also wonder if downstream commit d45c35c7b586 ("angler:
fingerprint: remove all the code about spi") [1] confirms that also downstream
kernel would reset or it's a security (it would not reset, thus they removed
the access). It's probably aosp issue tracker [2], but "Access denied" for me.

I also did some testing and this is maximum range which can be disabled:
gpio-reserved-ranges = <0 4>, <6 139> and it does not help to solve second
reset (in loop_init() or later when starting initramfs).
Removing access to GPIO 4 or 5 causes reset right immediately (no message from
kernel).

I still don't understand what changed in a99163e9e708 ("Merge tag
'devicetree-for-5.12' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux")
I checked both 882d6edfc45c cb8be8b4b27f, which it merges and they're ok.

Kind regards,
Petr

[1] https://android.googlesource.com/kernel/msm/+/d45c35c7b586711e757eb7e3239db5c88d114e0e
[2] https://issuetracker.google.com/issues/23756466

> Konrad



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux