Respectfully, you really, seriously need to work on your communication skills. You seem to be doing good work and I respect that (I use Mull, for one), but... you systematically sound fairly aggressive and complaining about everybody. Just for that I wouldn't want to contribute to any of your projects, and I wouldn't want to depend too much on them either (who knows who you will piss off next and where your projects will go).
For instance, let's look at what you describe here as "my PR was fixing a ton of stuff but it was ignored and closed".
First, the title of your PR is "Make the kernel less awful"... really? How would you feel if I opened a PR saying "Make DivestOS suck a little less, but let's be honest, it will still be a piece of shit after that"?
Not even mentioning that you say "Untested, but shouldn't require more than a handful drop/reverts". So you just come and drop a huge PR that you haven't tested, and then you complain that others don't pick it up?
Before closing your PR, the maintainer said:
> Don't get me wrong, it's impressive, but there's no way I'm going to merge this. You can't send someone 424 patches to a repo and expect them to stop everything they're doing for a month and checking them one by one in case just one of them fucks up the entire system (or contains some kind of malicious code), even less so on a 3.18.140 kernel that originally comes from Qualcomm.
That is very fair, and I would not call that "being ignored" at all.
Keep up the good work, and learn to communicate in a constructive way!
Your PR was not ignored, and the author explained why they could not merge it as-is.
After your PR got closed you explained how to create the patchset from kernel.org sources which is the right approach, maybe that happened in other commits?
Note: it's not a free software baseband FW as you'd expect from that being said.
What the PinePhone does is using a low end Qualcomm SoC as the modem (which has a CPU core and all, and runs a stripped-down Android in the stock configuration).
This just replaces that part which you can already edit on your own Android phone, but doesn't touch the actual modem bits at all, which remain the provided binary.
Still, I believe having full control on the firmware of the phone modem is at least as important as having root on the phone - otherwise, the firmware can say "location off? no problem!" while continuing to get GPS position locks + transmit the position inside UDP packets that won't be visible to the CPU running the android kernel and communicating to the firmware.
EDIT: actually, you are partly wrong when you say "This just replaces that part which you can already edit on your own Android phone": many android phones use a modem module to have certification in different markets.
So you can't replace the modem firmware on most android phones I'm familiar with.
Don't be confused by the modem using adb and fastboot like the android phones: it has its own software stack, and runs its own OS a bit like Intel ME or AMD PSP on PCs.
Following the discussion on illegal cell tracking where several comments mentioned the firmware can be a problem, here's a link to a free-software firmware.
I believe this is important, because on Android the firmware controls the network connection (and GPS, etc). It has its own embedded Linux, flash and CPU so even if you have root and run a firewall on android, it can send packets that will not be visible to the android kernel.
Most firmware have adb and fastboot, which can be used to replace what's running there by something you can recompile and audit. If you don't like it, you can also restore the initial firmware, for ex: https://github.com/Biktorgj/quectel_eg25_recovery
It's pretty interesting to see the added features this replacement userland provides when considering the tenacity of the TLAs in slurping up the data of citizens and non-citizens alike. It's capabilities like these that freak me out when considering similar stacks like the rPI GPU blobs and intel management engine/SGX.
I don't expect with the public failure of Clipper that they simply gave up on the capability to run clandestine code on your hardware, I think they just changed tactics.
Totally feasible. Or, hey, put it on an SBC, use it as an incoming SMS proxy with a dedicated SIM so you can recieve 2FA SMS without need of having the SIM and a phone with you.
Nothing really. I think you have to do something to make sure USB audio is routed right (I think its in their wiki). Other than that, it would work just fine!
What is the actual risk of closed baseband with it's own cpu? Does it have access to the same memory as the OS kernel? If so, is it not possible to design SoCs/boards that have dedicated memory for the baseband so that the main OS can treat the baseband and data in its memory as untrusted?
The risk is that the baseband could be implementing similar features that this userland adds to the "distro" running on the modem (call, data, and SMS recording), and these features could be driven by signals from the cell network. Unless you have a tap on the data egress path to the RF section, it would be difficult to know if data like this was being exfiltrated from your device as it completely bypasses the host's stack.
I wonder if it'd be possible, at this level, to create an E2EE voice connection between two devices.
I'm not familiar with the stack or the voice data stream through the hardware.
If code in the blob is responsible for encoding maybe it would still be possible to use a methodology similar to video mpeg where the raw data producer is aware of the blocking scheme and can formulate the data in a way that it is not compromised by encoding.
If the stream is encoded in userland I suppose it would be quite a bit easier.
Another feature this makes me ponder on is if perhaps you could send arbitrary data over the voice channel (if the above is possible, this should be). Since most providers these days provide unlimited voice, you could proxy your internet traffic to a second device located elsewhere and gain unlimited data, as well as perhaps reap the benefits of the steganographic nature of the channel.
I hope you realize you are describing dial-up internet? I could see having an automated dialer integrated with the OS do a decent job of masking the set up and tear down time of the connections, but it would have even slower data rates than the days of landlines, because cellular audio quality is much, much, much worse. And more importantly the jitter is significantly worse. Even sending faxes over cellular, or even wired VoIP fails regularly and that is an even slower data rate than would be acceptable for dial-up internet.
Also I haven’t looked it up but I assume the battery life of the pine phone while on a phone call is at most a few hours, compared to days for an active LTE connection.
It has had different phone numbers before, but we always ended up having some issue with some app where the it (correctly) thought the number was invalid, wouldn't allow you to reply etc.
So I settled with two easy to remember numbers: +22 33 44 55 66 77 for normal user<-->modem communication and +22 33 44 55 66 78 for Cell Broadcast message relays
[+] [-] _rdvw|2 years ago|reply
Also running long end-of-life and insecure Linux 3.18: https://github.com/the-modem-distro/quectel_eg25_kernel/blob...
I submitted a PR with my CVE auto-patcher which fixed many issues including numerous modem related ones which was ignored and closed: https://github.com/the-modem-distro/quectel_eg25_kernel/pull...
[+] [-] palata|2 years ago|reply
For instance, let's look at what you describe here as "my PR was fixing a ton of stuff but it was ignored and closed".
First, the title of your PR is "Make the kernel less awful"... really? How would you feel if I opened a PR saying "Make DivestOS suck a little less, but let's be honest, it will still be a piece of shit after that"?
Not even mentioning that you say "Untested, but shouldn't require more than a handful drop/reverts". So you just come and drop a huge PR that you haven't tested, and then you complain that others don't pick it up?
Before closing your PR, the maintainer said:
> Don't get me wrong, it's impressive, but there's no way I'm going to merge this. You can't send someone 424 patches to a repo and expect them to stop everything they're doing for a month and checking them one by one in case just one of them fucks up the entire system (or contains some kind of malicious code), even less so on a 3.18.140 kernel that originally comes from Qualcomm.
That is very fair, and I would not call that "being ignored" at all.
Keep up the good work, and learn to communicate in a constructive way!
[+] [-] fabrice_d|2 years ago|reply
After your PR got closed you explained how to create the patchset from kernel.org sources which is the right approach, maybe that happened in other commits?
[+] [-] c-c-c-c-c|2 years ago|reply
[deleted]
[+] [-] my123|2 years ago|reply
What the PinePhone does is using a low end Qualcomm SoC as the modem (which has a CPU core and all, and runs a stripped-down Android in the stock configuration).
This just replaces that part which you can already edit on your own Android phone, but doesn't touch the actual modem bits at all, which remain the provided binary.
[+] [-] csdvrx|2 years ago|reply
I'm currently editing my summary to clarify.
Still, I believe having full control on the firmware of the phone modem is at least as important as having root on the phone - otherwise, the firmware can say "location off? no problem!" while continuing to get GPS position locks + transmit the position inside UDP packets that won't be visible to the CPU running the android kernel and communicating to the firmware.
EDIT: actually, you are partly wrong when you say "This just replaces that part which you can already edit on your own Android phone": many android phones use a modem module to have certification in different markets.
So you can't replace the modem firmware on most android phones I'm familiar with.
Don't be confused by the modem using adb and fastboot like the android phones: it has its own software stack, and runs its own OS a bit like Intel ME or AMD PSP on PCs.
[+] [-] csdvrx|2 years ago|reply
I believe this is important, because on Android the firmware controls the network connection (and GPS, etc). It has its own embedded Linux, flash and CPU so even if you have root and run a firewall on android, it can send packets that will not be visible to the android kernel.
Most firmware have adb and fastboot, which can be used to replace what's running there by something you can recompile and audit. If you don't like it, you can also restore the initial firmware, for ex: https://github.com/Biktorgj/quectel_eg25_recovery
EDIT: replaced baseband by firmware. I confused one for the other. For context as to why it matters, see https://news.ycombinator.com/item?id=36658078
[+] [-] nurple|2 years ago|reply
I don't expect with the public failure of Clipper that they simply gave up on the capability to run clandestine code on your hardware, I think they just changed tactics.
[+] [-] kaba0|2 years ago|reply
[+] [-] BasedAnon|2 years ago|reply
[+] [-] pcdoodle|2 years ago|reply
[+] [-] dumdumchan|2 years ago|reply
[+] [-] brianmorris10|2 years ago|reply
[+] [-] 3np|2 years ago|reply
[+] [-] kop316|2 years ago|reply
[+] [-] gsich|2 years ago|reply
[+] [-] badrabbit|2 years ago|reply
[+] [-] nurple|2 years ago|reply
[+] [-] nurple|2 years ago|reply
I'm not familiar with the stack or the voice data stream through the hardware.
If code in the blob is responsible for encoding maybe it would still be possible to use a methodology similar to video mpeg where the raw data producer is aware of the blocking scheme and can formulate the data in a way that it is not compromised by encoding.
If the stream is encoded in userland I suppose it would be quite a bit easier.
Another feature this makes me ponder on is if perhaps you could send arbitrary data over the voice channel (if the above is possible, this should be). Since most providers these days provide unlimited voice, you could proxy your internet traffic to a second device located elsewhere and gain unlimited data, as well as perhaps reap the benefits of the steganographic nature of the channel.
[+] [-] callalex|2 years ago|reply
Also I haven’t looked it up but I assume the battery life of the pine phone while on a phone call is at most a few hours, compared to days for an active LTE connection.
It’s a funny thought experiment though.
[+] [-] bibaheu|2 years ago|reply
[+] [-] gsich|2 years ago|reply
[+] [-] pmontra|2 years ago|reply
+223 is the country code of Mali.
[+] [-] biktor_gj|2 years ago|reply
So I settled with two easy to remember numbers: +22 33 44 55 66 77 for normal user<-->modem communication and +22 33 44 55 66 78 for Cell Broadcast message relays