Re: [PATCH] arm64: dts: qcom: Add device tree for TUXEDO Elite 14 Gen1

[Michael Srba]

On 06. 03. 25 19:15, Konrad Dybcio wrote:
> On 6.03.2025 4:22 PM, Georg Gottleuber wrote:
> > Am 06.03.25 um 13:50 schrieb Konrad Dybcio:
> > > On 6.03.2025 1:25 PM, Georg Gottleuber wrote:
> > > > Initial support for TUXEDO Elite 14 Gen1 based on Qualcomm Snapdragon X
> > > > Elite SoC (X1E78100).
> > > >
> > > > Working:
> > > > * Touchpad
> > > > * Keyboard
> > > > * eDP (no brightness control yet)
> > > in case your panel as a PWM backlight, you will need to set the PWM
> > > output pin function explicitly, see x1e80100-microsoft-romulus.dtsi
> > Thank you, will check this.
> >
> > > > * NVMe
> > > > * USB Type-C port
> > > > * WiFi (WiFi 7 untested)
> > > > * GPU (software rendering)
> > > >
> > > > Not working:
> > > > * GPU (WIP: firmware loading but output is jerky)
> > > Please tell us more
> > Oh, this is already an older thing: with kernel 6.10 loading
> > gen70500_gmu.bin and gen70500_sqe.fw leading to partly slow and
> > stuttering video output. Sometimes it rendered black edges / borders to
> > KDE menus. Surely I did something wrong.
> >
> > I have just tried to reproduce the same setup, but I couldn't get it to
> > work just now. If you are interested, I can try it again with a
> > new/current kernel. (which is preferred? linux? linux-next?)
> linux-next/master is good
>
> [...]
>
> > > > +&gpu {
> > > > +       status = "okay";
> > > > +
> > > > +       zap-shader {
> > > > +               firmware-name = "qcom/a740_zap.mbn";
> > > Are the laptop's OEM key/security fuses not blown?
> > I'm not sure. How can I verify this?
> If you took the ZAP file from linux-firmware and it loaded, they are
> not blown.. meaning secure boot (not to be confused with UEFI secure
> boot) is not there and anyone can replace the entire secure firmware
> stack with what they please
>
> Konrad
Which to be clear is probably something Tuxedo would want, because it's by far the simplest way to ensure that the person who buys the device can do that. Even without the SPI flash being write protected and requiring physical access to unprotect (which I believe is what google went with for chromebooks), afaik Linux can't access the spi flash in the default configuration so it would still not be particularly feasible for someone without physical access to abuse this.

Although I'm a bit confused here, because to my knowledge being able to replace the "entire secure firmware stack" before it even has a chance to run (which is what anyone wanting to replace it would presumably intend to do) is considered a privilege escalation CVE by qualcomm and is not something you are supposed to be able to do without their blessing. I suppose they may be a bit more lax about allowing the OEM (and therefore the user if the OEM graciously doesn't lock the device down) to skip XBL_SEC (or whatever it's called now) with TME now being the first core to boot, which would certainly be nice even if it's literally "you can have it as long as it is no longer equivalent to full control over your hw, which is what you wanted in the first place"