12:33 <macc24> bamse: what's stopping modem on sc7180 from addressing kernel space?

12:43 <konradybcio> Probably nothing as all things "secure" and "remote" happen behind a qcom veil

12:45 <macc24> konradybcio: isn't it behind an iommu?

13:00 <konradybcio> No

13:01 <konradybcio> Even if it were, *mmus are managed by the proprietary hypervisor

13:12 <flto> konradybcio: actually, for crOS (which is what runs on all?/most sc7180) kernel runs at EL2 and manages both S1+S2 mmu (that doesn't mean there isn't a "backdoor" through the mmu.. cDSP has such a thing at least)

13:12 <konradybcio> There's always tz higher up and there are "secure" iommu contexts

13:13 <macc24> flto: well i run linux on my sc7180 machine

13:40 <minecrell> macc24: I have the perfect quote for this

13:40 <minecrell> regarding what protects modem from accessing kernel

13:40 <minecrell> https://lore.kernel.org/linux-arm-msm/20200507130210.GB31783@willie-the-truck/

14:20 <macc24> minecrell: lol

14:24 <bamse> macc24: the XPU is used to allow only specific ranges of memory to the modem

14:24 <bamse> macc24: this is as konradybcio says dealt with by tz/hypervisor

14:24 <macc24> bamse: isn't QSEE missing from sc7180?

14:24 <bamse> macc24: through static configuration and through the scm hyp_assign

14:25 <bamse> macc24: ahh, sc7180 as found in the chromebooks...i expect that someone configures the XPU still

14:25 <macc24> hmm

14:26 <bamse> macc24: there's still some proprietary stuff, even if qsee as a whole isn't there

14:49 <minecrell> macc24: the SCM calls end up in the proprietary qtiseclib blob in TF-A https://github.com/ARM-software/arm-trusted-firmware/blob/09665c83484b3e730814e368df80129598573bd9/plat/qti/common/src/qti_syscall.c#L279-L282

14:52 <macc24> cursed stuff

15:32 <robclark> jstultz, calebccff: https://patchwork.freedesktop.org/patch/460086/?series=95975&rev=1 is worth a try to see if it helps with the a630 power instability

15:33 <robclark> macc24: the bootloader setups up firewalls that restrict the modems memory access.. if that were not the case it would not have met CrOS's security requirements

15:34 <robclark> konradybcio: no hyp on CrOS devices.. kernel manages S2 translations

15:35 <macc24> robclark: thank

15:35 <robclark> firewalls == XPU

15:35 <macc24> "no hyp" isn't hyp required for kvm on aarch64?

15:36 <robclark> actually the inverse.. hyp is why on android phones the kernel starts at EL1 which prevents kvm

15:36 <robclark> this is part of the reason there is no hyp on CrOS devices, because kvm is a requirement

15:36 <minecrell> macc24: well KVM is the "hyp" in that case :P

15:36 <robclark> right

15:37 <ahalaney> yeah "no hyp" == "no QHEE"

15:37 <macc24> huh

15:58 <konradybcio> Woah, now I feel like a second (or even third given that WP fw is more liberal) class citizen on an LA platform..

16:12 <macc24> LA?

16:15 <robclark> Linux Android

16:15 <robclark> ie. not CrOS or windows

16:17 <bamse> or automotive (AU)

16:17 <macc24> robclark: why not cros?

16:18 <bamse> because that's named "LC"

16:18 <macc24> huh?

16:19 <bamse> and per above discussion, the software is different - e.g. wrt the boot/security flow

16:19 <robclark> ahh, forgot automative

16:19 <robclark> but yeah, boot flow and fw is very different for CrOS

16:19 <macc24> what about chromebooks running linux

16:20 <robclark> the dev boards (like rb3/db820c/etc) use LA fw even if they are running linux

16:20 <bamse> macc24: that doesn't exist as a deliverable from Qualcomm, hence no name of the software package

16:20 <macc24> and what about chromebooks running linux with correct keys so vboot is happy

16:20 <robclark> and also, it would still be LC

16:20 <robclark> since the name (in this context) is about the boot chain and related fw

16:20 <bamse> robclark: in the event that qualcomm would make a release of say Ubuntu on 7c, it probably wouldn't be a LC release anymore

16:21 <robclark> I'd assume so

16:21 <macc24> i'm more confused than befor

16:21 <robclark> it would probably be more similar to windows, with UEFI and ACPI

16:22 <robclark> macc24: just ignore the "Android" part of the name "LA" and it makes more sense ;-)

16:22 <macc24> robclark: where does cros fit into this

16:22 <bamse> macc24: LA/LC/AU/WP are software releases from qualcomm, i.e. boot, firmware, kernel, userspace everything

16:24 <bamse> macc24: so for the chromebooks, there's a ChromeOS release from Qualcomm, that Google "uses"...and per the software design and components of that release it's a "LC" release

16:25 <macc24> bamse: so if i put linux onto my chromebook, while still using coreboot with depthcharge as boot firmware and while using firmware stolen from cros, it would be LC?

16:25 <bamse> macc24: for your typical android device, there's a set of these software components with Android as userspace, and that's a LA release

16:25 <bamse> macc24: if qualcomm where to ship that yes

16:25 <bamse> macc24: but i doubt that qualcomm will take your software, repackage that and redistribute it

16:25 <macc24> bamse: well i'm not saying i'm not talking with qcom about it

16:26 <bamse> macc24: then you're not making a qualcomm release, so you wouldn't use the qualcomm naming scheme

16:27 <macc24> ok\

16:27 <robclark> macc24: putting linux on the thing doesn't change the boot fw.. so it is still "LC"

16:27 <bamse> and sorry, no if you take LC, turn that into a non-Chrome thing, then it's no longer LC...there's someother two-letter ackronym for "standard Linux distribution"

16:27 <macc24> bamse: it's not standard linux distribution

16:27 <robclark> well, I mean the fw is still LC.. we don't really take "qualcomms kernel" or userspace for CrOS.. they just deliver patches, we pick them, we release the sw

16:28 <bamse> robclark: so perhaps it's better to say it would be "based on LC"

16:28 <robclark> ok, sure

16:28 <macc24> robclark: i don't really take your kernel ;)

16:28 <bamse> pretty much how all our devboards are "based on LA", but it's not Android

16:28 <robclark> it isn't really my kernel

16:29 <macc24> yea yea i know