3 ms·

I'm just guessing here; but the reason why it's not implemented in userspace, not written in Rust, not using IOMMU, BP is allowed full DMA, the system is split

I'm just guessing here; but the reason why it's not implemented in userspace, not written in Rust, not using IOMMU, BP is allowed full DMA, the system is split into AP and BP in the first place, etc etc, is probably because of lags those stuffs introduce - difficulty of meeting and maintaining required realtime constraints. ALL of those desktop-derived event driven technologies, with deep call stacks and abusive use of interrupts, tend to run NOT like a marathon runner, but like an attention deficit man, and the latter is how you get choppy audio. IIUC, Nokia in '00s already used an architecture that baseband OS and application OS(Symbian) would run on the same CPU, with RTOS below the application OS forcing regular switch to baseband or something, because baseband code is synchronized to physical IRL time, managing physical phenomena, and the user, can wait. If anyone's going to move phone signaling and audio processing to AP, they'll have to first show the embedded guys that their fancy stuff is better than the existing realtime stuff, and is not an elaborate prank. Which, I think, isn't easy. I mean, one of news for Raspberry Pi 5 was addition of a programmable I/O processor for realtime/low-level tasks, not removal of.

LoganDark 3y ago
> the latter is how you get choppy audio Tell me, if Discord can stream high-quality audio in real-time, what makes a phone call that much harder to handle, especially given how awful the sample rate is? Shouldn't an 8-bit micro from the 80s be able to handle that? Aren't there even already pieces of homebrew software for those micros that can handle audio of that quality?
- atoav 3y ago
  For me it feels just wrong? Why would we high-level-sandbox a basic functionality when we obviously know how to write safe software in other spaces in the low level? Think anything space, aviation or automotive. If your remedy to writing bad software is "just put it into a sandbox", then who says that sandbox isn't bad software as well? So now you got bad software in a sandbox that may or may not be safe and is less performant than the low level variant. Maybe the software is bad in a kind that allows abuse despite the sandbox, congrats now your baseband lies to you. The solution I like is to use strictly typed languages, formaly verified compliers, a ton of tests and fuzzing and above all: avoiding unnecessary complexity. Embedded programming sucks, but we have Ada, we have Rust and we have a chance to do things that are both safe and performant.
  - eptcyka 3y ago
    Nobody is attacking interfaces of plane SBCs the way mobile basebands are being attacked out in the wild. They defensive architecting and programming for aerospace most often is entirely different from the defensive programming of things that have to contend with malicious input.
  - bdd8f1df777b 3y ago
    > when we obviously know how to write safe software in other spaces in the low level? Think anything space, aviation or automotive. I seriously doubt that those software is near any levels of safe. They are just not attacked as often. > If your remedy to writing bad software is "just put it into a sandbox", then who says that sandbox isn't bad software as well? Chromium has high quality coding, but they still sandbox their own code whenever they can. Security vulnerability results from the limit of humanity, so it cannot be eliminated by just willpower. And to answer your question directly, * Writing a sandbox is easier to get right than many other software. * Even if the sandbox itself is badly written and therefore has vulnerability, it must be combined with the vulnerability of the software it protects in order to achieve any attack. So sandboxing something always increase the difficulty of attackers and is a worthy investment from the viewpoint of security. > The solution I like is to use strictly typed languages, formaly verified compliers, a ton of tests and fuzzing and above all: avoiding unnecessary complexity. The relationship between these and sandboxing is not exclusive. One can and should do both of them.
  - dvdkon 3y ago
    It's just as much software engineering as it is "politics". Baseband vendors could put in as much effort as aviation manufacturers, but they won't. The status quo of overcomplicated, insecure, buggy software is hard to change. So the only tenable approach is one that relies as little on baseband vendors cooperating.
  - LoganDark 3y ago
    > Why would we high-level-sandbox a basic functionality when we obviously know how to write safe software in other spaces in the low level? Why would we sandbox code against vulnerabilities rather than simply writing code without vulnerabilities? Because writing code without vulnerabilities is not possible to achieve 100% of the time. I love Rust as much as the next guy, but you need to know how to use it, too. We're back to "just do it perfectly" again: write perfect code, using perfect languages with perfect compilers. In order to know how to do that, hire perfect employees. In order to hire perfect employees, you need a perfect interview process, etc. I'm sure this would be easy in a perfect world. But do you have any idea how unrealistic this prospect is? About why you can't just place your trust in being able to write perfect code that has no bugs, and about why defense in depth is so important? If you have no sandbox, you have to write code that contains zero vulnerabilities. If you cannot perfectly guarantee the complete absence of bugs, you cannot perfectly guarantee that your code contains zero vulnerabilities.
GoatOfAplomb 3y ago
> is probably because of lags those stuffs introduce There is likely some truth to this, but I think the bigger reason for these things is that Qualcomm can't be arsed.
phh 3y ago
There are two lags to take into account. Lags at connection, and lags during the call. Connection is what is very complicated to do safely, but once its setup, except for some signaling, it is much simpler [1]. The architecture used by some people (I wouldn't know exactly who does what, it's all muddy) is that the connection/signaling is done in application processor, but the Encoding/Decoding + RTP is done in baseband processor. You do get a bit of additional of lag at connection (but anyway you have an UI to show), but you can keep your real time audio guarantees. [1] That's for volte. For vowifi, that's more complicated, but anyway talking about lags over wifi...
the8472 3y ago
> I'm just guessing here; but the reason why it's not implemented in userspace, not written in Rust, not using IOMMU, BP is allowed full DMA, the system is split into AP and BP in the first place, etc etc, is probably because of lags those stuffs introduce - difficulty of meeting and maintaining required realtime constraints. That doesn't seem likely. All those technologies (except userspace maybe) work fine for realtime constrains down to microseconds. If your constraints are in the nanoseconds (wireless signal processing stuff?) you probably have to use some local SRAM anyway and thus not need to touch the system memory.

LoganDark 3y ago

> the latter is how you get choppy audio Tell me, if Discord can stream high-quality audio in real-time, what makes a phone call that much harder to handle, especially given how awful the sample rate is? Shouldn't an 8-bit micro from the 80s be able to handle that? Aren't there even already pieces of homebrew software for those micros that can handle audio of that quality?

atoav 3y ago
For me it feels just wrong? Why would we high-level-sandbox a basic functionality when we obviously know how to write safe software in other spaces in the low level? Think anything space, aviation or automotive. If your remedy to writing bad software is "just put it into a sandbox", then who says that sandbox isn't bad software as well? So now you got bad software in a sandbox that may or may not be safe and is less performant than the low level variant. Maybe the software is bad in a kind that allows abuse despite the sandbox, congrats now your baseband lies to you. The solution I like is to use strictly typed languages, formaly verified compliers, a ton of tests and fuzzing and above all: avoiding unnecessary complexity. Embedded programming sucks, but we have Ada, we have Rust and we have a chance to do things that are both safe and performant.
- eptcyka 3y ago
  Nobody is attacking interfaces of plane SBCs the way mobile basebands are being attacked out in the wild. They defensive architecting and programming for aerospace most often is entirely different from the defensive programming of things that have to contend with malicious input.
- bdd8f1df777b 3y ago
  > when we obviously know how to write safe software in other spaces in the low level? Think anything space, aviation or automotive. I seriously doubt that those software is near any levels of safe. They are just not attacked as often. > If your remedy to writing bad software is "just put it into a sandbox", then who says that sandbox isn't bad software as well? Chromium has high quality coding, but they still sandbox their own code whenever they can. Security vulnerability results from the limit of humanity, so it cannot be eliminated by just willpower. And to answer your question directly, * Writing a sandbox is easier to get right than many other software. * Even if the sandbox itself is badly written and therefore has vulnerability, it must be combined with the vulnerability of the software it protects in order to achieve any attack. So sandboxing something always increase the difficulty of attackers and is a worthy investment from the viewpoint of security. > The solution I like is to use strictly typed languages, formaly verified compliers, a ton of tests and fuzzing and above all: avoiding unnecessary complexity. The relationship between these and sandboxing is not exclusive. One can and should do both of them.
- dvdkon 3y ago
  It's just as much software engineering as it is "politics". Baseband vendors could put in as much effort as aviation manufacturers, but they won't. The status quo of overcomplicated, insecure, buggy software is hard to change. So the only tenable approach is one that relies as little on baseband vendors cooperating.
- LoganDark 3y ago
  > Why would we high-level-sandbox a basic functionality when we obviously know how to write safe software in other spaces in the low level? Why would we sandbox code against vulnerabilities rather than simply writing code without vulnerabilities? Because writing code without vulnerabilities is not possible to achieve 100% of the time. I love Rust as much as the next guy, but you need to know how to use it, too. We're back to "just do it perfectly" again: write perfect code, using perfect languages with perfect compilers. In order to know how to do that, hire perfect employees. In order to hire perfect employees, you need a perfect interview process, etc. I'm sure this would be easy in a perfect world. But do you have any idea how unrealistic this prospect is? About why you can't just place your trust in being able to write perfect code that has no bugs, and about why defense in depth is so important? If you have no sandbox, you have to write code that contains zero vulnerabilities. If you cannot perfectly guarantee the complete absence of bugs, you cannot perfectly guarantee that your code contains zero vulnerabilities.

GoatOfAplomb 3y ago

> is probably because of lags those stuffs introduce There is likely some truth to this, but I think the bigger reason for these things is that Qualcomm can't be arsed.

phh 3y ago

There are two lags to take into account. Lags at connection, and lags during the call. Connection is what is very complicated to do safely, but once its setup, except for some signaling, it is much simpler [1]. The architecture used by some people (I wouldn't know exactly who does what, it's all muddy) is that the connection/signaling is done in application processor, but the Encoding/Decoding + RTP is done in baseband processor. You do get a bit of additional of lag at connection (but anyway you have an UI to show), but you can keep your real time audio guarantees. [1] That's for volte. For vowifi, that's more complicated, but anyway talking about lags over wifi...

the8472 3y ago

> I'm just guessing here; but the reason why it's not implemented in userspace, not written in Rust, not using IOMMU, BP is allowed full DMA, the system is split into AP and BP in the first place, etc etc, is probably because of lags those stuffs introduce - difficulty of meeting and maintaining required realtime constraints. That doesn't seem likely. All those technologies (except userspace maybe) work fine for realtime constrains down to microseconds. If your constraints are in the nanoseconds (wireless signal processing stuff?) you probably have to use some local SRAM anyway and thus not need to touch the system memory.