ProjectRationale » History » Version 1
laforge, 02/19/2016 10:48 PM
start a page explainig what we do and why we do it
1 | 1 | laforge | = Project Rationale = |
---|---|---|---|
2 | |||
3 | == Why? == |
||
4 | Why on earth would somebody want (to write) an open source GSM stack for a GSM baseband chip? |
||
5 | |||
6 | There's many answers to this question. The first and obvious: Because we can. However, |
||
7 | looking more deeper, there are many good reasons for an Open Source GSM baseband firmware: |
||
8 | |||
9 | === Security of an always-connected device in a public network === |
||
10 | Every mobile device that is connected to a cellular network runs some kind of baseband |
||
11 | processor with highly proprietary and closed-source firmware. |
||
12 | |||
13 | Any reasonably complex software has bugs, and a number of them will be security relevant |
||
14 | and might get exploited. |
||
15 | |||
16 | As we know from more than a decade of security nightmares on the Internet: Open Source |
||
17 | projects provide a much higher level of security, as more eyes review the code and |
||
18 | security related bugs get fixed almost immediately. An update is released, and that |
||
19 | particular security issue is closed. |
||
20 | |||
21 | Most people understand that connecting an unprotected PC to a public network like |
||
22 | the internet is dangerous. People use personal or dedicated firewalls, application |
||
23 | level gateways, virus scanners and other technology to protect their PC. |
||
24 | |||
25 | But what about the mobile phone, particularly the baseband processor? It is permanently |
||
26 | attached to a public network, in most cases there is no proper incident response management |
||
27 | and not even a clean way how bugs in that software can be updated quickly, as device |
||
28 | manufacturers rarely release firmware update, publish security advisories or any of |
||
29 | that sort. |
||
30 | |||
31 | The security situation becomes even worse when looking at the software architecture in |
||
32 | those baseband chips. They often run the entire software stack in supervisor mode, |
||
33 | without any software protection. There are no non-executable pages, there's no |
||
34 | stack protection, etc. The UI and the protocol stack run in one shared address |
||
35 | space with no privilege separation. |
||
36 | |||
37 | The only companies who have access to the baesband firmware source code have no |
||
38 | interest in improving this situation. So the logical conclusion is to form an |
||
39 | Open Source project that can try to improve the situation |