zlacker

>>fghtr+(OP)
This blogpost propagates what I'd like to describe as an urban legend about baseband processors and main memory. The story originates from old times where even fancy phones allowed the baseband to write everywhere in main memory. The myth then becomes that you need the baseband physically separated from your main application processor.

But the world's moved on since those reports were made. It's FUD: https://www.reddit.com/r/CopperheadOS/comments/6wtul0/on_sen...

>>DCKing+ua
I know very little about the topic so bearing that in mind:

We're already in a world were we can't quite trust our CPUs, so why trusting baseband chips?

If it does make the design more complicated, it may also reduce the potential attack surface.

>>alex_d+8b
> If it does make the design more complicated, it may also reduce the potential attack surface.

an increase in complexity would rule out reduction of attack surface. in fact attack surface would be guaranteed to increase

>>Dyslex+wb
Well, that isn't generally true if the complexity is actually a security boundary. After all, all security designs are based on layers -- it's hard to add a layer of security without adding complexity.

As a counter-example -- removing all of Linux's privilege checking would make the code a lot less complicated, but the attack surface would increase a million-fold. In this case, the Librem 5's separation of the baseband such that communication is done over USB (a protocol which doesn't have DMA) is a security improvement over giving the baseband DMA access.

>>cyphar+Ed
> Well, that isn't generally true if the complexity is actually a security boundary.

if the security boundary is baked into the code or the design of the system, and also assuming it doesn't introduce more bugs, then I agree[1]. Security controls that get introduced on top do risk an increase in attack surface. An additional interface is by definition a an additional "surface", the question is if it can be attacked.

[1] you could still argue that more lines of code always means more bugs (but let's assume it's very close to bullet-proof)

>>Dyslex+gj
If the alternative to adding an additional interface is to just give DMA access to the device, I'm not sure I see the downside to using the additional interface. Even if the interface ends up being completely broken, at the very least there was something to break before you get DMA / RCE access. What possible interface breakage could trump free and unrestricted DMA access?