Actually, my interpretation (which admittedly is based off of limited knowledge of hardware, the Linux kernel, and operating systems in general) was that the baseband processor itself doesn't have a kernel driver, per se, because it's software doesn't run within the Linux kernel on the main CPU; rather it runs on the baseband processor, and presumably communicates with the kernel via some bus. It is my understanding that the alleged "backdoor" is based on the fact that the kernel allows the baseband processor to access the device's filesystem over this bus, via the libsamsung-ipc component. Please do correct me if I'm missing something here.
Now, if that's correct, then this is in fact significant, because the baseband processor would not otherwise have such access to the filesystem (since it's not, as I understand it, running in the kernel as a driver).
All that being said, the entire thing hinges upon what really goes on in the baseband processor? There are certainly legitimate engineering uses for such filesystem access (as pointed out elsewhere in these comments), so is there really a corresponding backdoor in the modem to allow an attacker full filesystem access on Galaxy devices?
You are not missing anything. However you have so much Samsung code running in privileged mode on these devices, that picking this issue out and calling it a "backdoor" (implying malice) is an especially nasty PR tactic. This leads to classifying legitimate engineering decisions as something of an evil nature.
I would have to agree with you somewhat. Perhaps this is just FUD.
However, I will say that a lot of the FSF's/GNU project's platform is based on the idea that, with unchecked closed-source code running on a device, such backdoors are possible. (Call it FUD if you like.) Fifteen years ago in the days of Windows '98, that might have seemed ridiculous or improbable, but I believe that in the present climate their concerns have become more relevant than ever. In that sense I think that this Replicant project is really interesting, and I'll probably be paying attention to it in the future.
That being said, they surely aren't making any friends at Samsung by doing this, which could hurt them in the long run (compare to the relatively fruitful, although sometimes tumultuous, relationship between Cyanogen Mod and Google).
Also, the elephant in the room here is still the unchecked software running on the baseband processor, no matter which way you look at it.
>> Now, if that's correct, then this is in fact significant, because the baseband processor would not otherwise have such access to the filesystem (since it's not, as I understand it, running in the kernel as a driver).
You'd think so... The baseband processor is actually integrated on the die of current gen SoCs from Qualcomm and plenty of the teardowns I've seen for high end phones use them. I haven't used these chips but everything I've read leads me to believe that there is a lot more integration between the radio and processor (that's the point)... and as a result, a larger attack surface.
Some further research I did since this thread started has shown that in some phones, even the microphone and camera are under the direct control of the baseband processor. In others, it's not. But in most phones, the CPU and BB share memory, which opens the door for the BB to do all sorts of nasty things to the OS on the CPU.
Now, if that's correct, then this is in fact significant, because the baseband processor would not otherwise have such access to the filesystem (since it's not, as I understand it, running in the kernel as a driver).
All that being said, the entire thing hinges upon what really goes on in the baseband processor? There are certainly legitimate engineering uses for such filesystem access (as pointed out elsewhere in these comments), so is there really a corresponding backdoor in the modem to allow an attacker full filesystem access on Galaxy devices?
We may never know...