Val Packett 🧉2d ago

In preparation for daily driving #MobileLinux I've been thinking a lot about what must be done for reliable and power-efficient push notifications.

Spoiler alert: while UnifiedPush may be a relevant service for some apps, it's not where platform dev focus should be. We want a future full of p2p apps that reject permanently-addressable "servers" entirely, after all! And centralization is not where the bulk of the power-saving magic is anyway. The "magic" is in the fact that the SoC can be in deep sleep and the modem will still wake it up with an interrupt when data arrives on an open connection. It should be fine to have apps' own service processes listen for notifications!

My rough sketch of a to-do list would be:

  • making sure wakeups don't turn the display on xD
  • research into what's needed to set up filtering on the modem for which sockets can wake the SoC up (but initially, fine to just rely on "nothing else has open sockets anyway, only the background services waiting for pushes" maybe?)
  • easy API for establishing the push connection specifically over mobile data if available (since only modem supports wakeup well rn)
  • support for robust background services: unlike what the Background portal offers now, let #Flatpak apps install systemd-user services, which would have metadata connecting them to the .desktop entry, making them introspectable and accountable via settings GUIs (not via control center popups! they shouldn't show up as "annoying left-over in-process thing possibly eating battery"! they're a different thing, expected to run permanently!)
  • actually getting apps to separate push notification listeners into background services

#postmarketOS #linuxmobile #freedesktop

Show threadelly
@valpackett I had similar thoughts, together with "wake up only bare minimum" (single CPU core, modem and ADSP, leave DSI, CSI, I2C/SPI/UART blocks in suspend (if possible, not sure if this can be done... I guess you can tell pinctrl to leave pins in pull-down mode?)

We don't need to wake up the entire SoC for this, which would drastically reduce the power draw (and therefore the battery life)
Mar 22 at 10:54pmWeb
Show threadVal Packett 🧉2d ago

@elly just not turning on the display would leave DSI off, and if touchscreen is a panel-follower also that with the SPI/I2C used for it. that's all already managed by runtime pm!

USB of all things just is not there yet, it does pm_runtime_forbid() still (you can override that by echoing auto into power/control for all usb, xhci-hcd and related phy nodes and pray xD)

not enabling more than one CPU core until there's actual activity is very interesting yeah. somewhat related is using scx-lavd as the scheduler which does try to bunch tasks together onto one cluster to keep the others in suspend as much as possible. but hard "only 1 core online until the session is open" would be a nice big hammer :D

oh oh I also forgor for the list: bg services will need to have some way of opening the push connection specifically over the mobile data interface if available (unless specific-enough wakeup is possible with wifi after all)

Show thread✧✦Catherine✦✧1d ago

@valpackett @elly how does this solve the problem of "five applications independently maintain event sockets resulting in approximately five times the amount of wakeups"? the advantage of something like gms (no idea if unified push actually does it) is that it can batch events from unrelated sources into one wakeup

in theory, if you terminated all of the connections, including TLS, on the modem, you could achieve the same level of power savings. in practice i absolutely do not want to terminate TLS on the modem, that's horrifying

Show threadelly1d ago
@whitequark @valpackett then you will be horrified to find out that smasnug modems (Samsung phones with Exynos SoC, Google Pixel 6 and newer) have a modem where ARM SoC (Control Processor, "CP") running ShannonOS (RTOS) is connected over PCIe and it's running a full IP stack on that RTOS.

AFAIK UnifiedPush does exactly that, I've seen a presentation about it and it acts kinda like GSF do.
Show thread✧✦Catherine✦✧1d ago

@elly @valpackett I'm not surprised at all that this exists (the modem is obviously capable of it and this is obviously desirable from a vendor's point of view), but I'm very surprised that there is both the desire and the capability to use that sort of stuff in FOSS ROM components

is this mechanism at least somewhat portable? do you want to keep using it? if the answers are yes then yeah aggregation on the modem is the way to go, I'm just surprised to see FOSS-minded people be okay letting that blob handle anything important

Show threadelly1d ago
@whitequark @valpackett CP has BootROM that verifies signatures, I tried bit-flipping the firmware package it loads from modem partition and that broke the modem
Show thread✧✦Catherine✦✧1d ago
@elly @valpackett well yeah it better do that
Show thread✧✦Catherine✦✧1d ago
@elly @valpackett i found this slide deck which doesn't say anything about terminating connections on the modem, is there a different presentation? couldn't find anything in UP docs either
Show threadelly1d ago
@whitequark @valpackett Ah, that's not what I meant. Sorry, I meant two different things.

UnifiedPush works completely in userspace
Show thread✧✦Catherine✦✧1d ago
@elly @valpackett okay yeah then to clarify my earlier statement: it horrifies me because the modem is some blob we don't control that is typically tested and built much more shoddily than the AP firmware (do they normally enable NX and stack cookies on it yet?), not because there's anything wrong with the abstract concept of 'brains in the modem'
Show threadCUB3D1d ago
@whitequark On Shannon specifically: NX is enabled, it has stack cookies and they started enabling some LLVM sanitizers. No CFI/PAC/ASLR. Slightly better than other modems, but whether their custom RTOS actually implements any of it *correctly* is anyone's guess.
Show threadrobryk1d ago
@whitequark @valpackett @elly Why including TLS? I thought TLS doesn't require inband acks, so after TCP-acking one can insert an arbitrary delay before the TLS layer sees the data, no?
Show thread✧✦Catherine✦✧1d ago

@robryk @elly @valpackett i'm not a TLS expert so i won't comment on that part; the reason i think practically speaking you'd end up wanting to terminate TLS on the modem is because to minimize the time the SoC spends out of sleep you'd want the messages passed onto the SoC to be complete (no half-read ones where you need to wait for the rest) and useful (no passing along exchanges like "got data? no data!"). and i don't believe you can ensure that something you receive in a TLS envelope is complete because reading from a TLS stream may involve writing to the socket (i think for reasons like rekeying?)

maybe there's a way to half-ass it where it mostly works most of the time, but i've a distaste for halfassing greenfield systems

Show threadDemi Marie Obenour1d ago
@whitequark @robryk @elly @valpackett I’d use asymmetric encryption and treat the modem as untrusted. Rely on it being behind an IOMMU and move its driver into a sandboxed userspace process.
Show threadVal Packett 🧉1d ago
@whitequark @robryk @elly IMO, batching and minimizing the time spent processing and all that is pennies. If you get the SoC to sleep for hours on end while 30-40 feral sockets are open and quietly waiting for something to happen, that's like the vast majority of the possible savings. Upon wakeup it can spend an entire minute turned on and it'll be fine. Recent SoCs just don't draw that much power when idle, this phone (SM7325/Yupik) measures 0.2W at the battery while responding to SSH commands over WiFi. That for a minute on every push, but CX rail collapsed while sleeping otherwise, would be super good. (Currently it doesn't even do CXSD yet, so suspend is not that much better than just being idle xD Still lasts an entire day without heavy screen-on use.)