Le mercredi 02 mars 2016 à 20:28 +0100, Denis 'GNUtoo' Carikli a écrit : > Signed-off-by: Denis 'GNUtoo' Carikli <gnu...@no-log.org>
See comments below, > --- > freedom-privacy-security-issues.php | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/freedom-privacy-security-issues.php b/freedom-privacy-security- > issues.php > index 31d8310..0d8c936 100644 > --- a/freedom-privacy-security-issues.php > +++ b/freedom-privacy-security-issues.php > @@ -10,7 +10,7 @@ > <p>Regarding the software side of things on mobile > devices, the main CPU (inside the SoC) starts by executing code located inside > the silicon. If this is an ARM CPU, that code will be ARM instructions. This > code is known as the botrom. It will look up various places such as NAND, eMMC > or MMC (sd/micro sd card) storage, depending on the hardware configuration, to > load a bootloader. The bootloader, which is in fact often split in different > stages, is in charge of bringing up and configuring various aspects of the > hardware and eventually starting the operating system by loading and running > its kernel.<br /><a href="images/freedom-privacy-security- > issues/software.png" > data-lightbox="overview" data-title="Software-side overview"><img > src="images/freedom-privacy-security-issues/software.png" alt="Software-side > overview" style="width: 250px; float: right;"/></a>The kernel itself, among > other things, deals with the hardware directly and provides ways for other > programs (running i > n user-s > pace) to access it. In user-space, hardware abstraction layers are programs > specific to each device that know how to properly drive the hardware. They use > the kernel to communicate back and forth with the hardware and implement the > proper protocols for it.<br /><br />The actual knowledge of how to drive the > hardware is split between the kernel and the hardware abstraction layer > libraries: both are needed to make it work properly. Hardware abstraction > layers provide a generic interface for the framework to use. The framework > itself provides an interface for applications that is independent of the > device and the hardware. That way, applications can access hardware features > through the generic framework interface, which will call the hardware > abstraction layer libraries, ending up with the kernel communicating with the > hardware. For instance, when making a call, the dialer application will > communicate with the framework, which in turn will communicate with the > hardware abstract > ion laye > r. That hardware abstraction layer will implement the protocol to speak with > the modem, and the Linux kernel will be responsible of permitting the > communication between the hardware abstraction layer and the modem.</p> > <p>Many other components of a mobile device also run > software in different forms. The various integrated circuits run small pieces > of dedicated software that are called firmwares. When the device is telephony- > enabled, there is also software running on the modem. Modern modems are > complex and run full operating systems.</p> > <h3>The current situation of freedom and > privacy/security on mobile devices</h3> > - <p>A mobile device respecting the users' freedom > would have:<ul><li>Free hardware</li><li>Free firmwares</li><li>Free modem > system</li><li>Free bootrom and bootloader</li><li>Free system and > applications</li></ul>Regarding <a href="#free-hardware">free hardware</a>, it > barely exist as of today. Modifying hardware is nearly impossible: new > versions of the hardware have to be produced, and those are expensive. While > producing printed circuit boards (PCBs) costs a lot of money, producing > integrated circuits is out of reach. A few devices come with schematics for > the PCB, but that's usually as far as it gets. Hence, totally-free hardware > doesn't exist yet.</p> > + <p>A mobile device respecting the users' freedom > would have:<ul><li>Free hardware</li><li>Free firmwares</li><li>Free modem > system</li><li>Free bootrom and bootloader</li><li>Free system and > applications</li></ul>Regarding <a href="#free-hardware">free hardware</a>, it > barely exist as of today. The ways of modifying existing hardware are very > limited. Because of that, new versions of the hardware have to be produced to > carry the modifications, and this is expensive. While producing printed > circuit boards (PCBs) costs a lot of money, producing integrated circuits is > out of reach. A few devices come with schematics, or full design files for the > PCB, but that's usually as far as it gets. All of the above looks good to me. > Hence, totally-free hardware doesn't exist yet. While design for FPGAs do > exist in free software licenses, FPGAs are not practical enough to be used to > replace ASICs in smartphones, and most of them even proprietary software > tools.</p> Talking about FPGAs comes out of the blue here. Either way, the FPGA design itself causes the same hardware freedom issues, so it's not an any better candidate for a solution. Since FPGA have a purpose that is not what is relevant for mobile devices, I wouldn't mention them at all. > <p>Firmwares running inside integrated circuits are > most of the time proprietary. While free firmwares are hard to write, some > exist for very specific hardware (e.g. <a > href="//www.arduino.cc/">Arduino</a>, <a > href="//dangerousprototypes.com/docs/Bus_Pirate">Bus Pirate</a>) and > sometimes, manufacturers can liberate firmwares running in their integrated > circuits (e.g. <a href="//github.com/qca/open-ath9k-htc- > firmware">ath9k_htc</a>). However, it is not always possible to even replace > those firmwares: some are loaded to the integrated circuit by the main CPU but > some others are pre-installed in the circuit (in that case, they almost seem > to behave like hardware) and cannot be updated to a free replacement.</p> > <p><a href="images/freedom-privacy-security- > issues/bad-modem-isolation.png" data-lightbox="current-situation" data- > title="Bad modem isolation"><img src="images/freedom-privacy-security- > issues/bad-modem-isolation.png" alt="Bad modem isolation" style="width: 250px; > float: left;"/></a>The modem system on telephony-enabled mobile devices is > always proprietary. While <a href="//bb.osmocom.org/">OsmocomBB</a>, a free > software GSM stack exists, it only runs on old feature phones, currently > requires a host computer to operate and is not certified to run on public > networks. Despite this situation, the modem remains a crucial part for > privacy/security: it is nearly always connected to the GSM network, allowing > for <a href="//www.gnu.org/philosophy/malware-mobiles.html">remote control</a> > ; > . The modem can be more or less damaging to privacy/security depending on what > hardware it has access to and can control. That is to say, how isolated it is > from the rest of the device.<br /><br />A > device > with bad modem isolation would allow the modem to access and control key > parts of the hardware, such as the RAM, storage, GPS, camera, user I/O and > microphone. This situation is terrible for privacy/security as it provides > plenty of ways to efficiently spy on the user, triggered remotely over the > mobile telephony network. Those are accessible to the mobile telephony > operator, but also to attackers setting up fake base stations for that > purpose. <a href="images/freedom-privacy-security-issues/good-modem- > isolation.png" data-lightbox="current-situation" data-title="Good modem > isolation"><img src="images/freedom-privacy-security-issues/good-modem- > isolation.png" alt="Good modem isolation" style="width: 250px; float: > right;"/></a>On the other hand, when the modem is well-isolated from the rest > of the device, it is limited to communicating directly with the SoC and can > only access the device's microphone when allowed by the SoC. It is then > strictly limited to accessing what it real > ly needs > , which considerably reduces its opportunities to spy on the user. While it > doesn't solve any of the freedom issues, having an isolated modem is a big > step forward for privacy/security. However, it is nearly impossible to be > entirely sure that the modem is actually isolated, as any documentation about > the device cannot be trusted, due to the lack of effective hardware freedom. > On the other hand, it is possible to know that the modem is not isolated, when > there is proof that it can access hardware that could be used to spy on the > user.</p> > <p>Looking at the software that runs early on the > SoC, the first component is the bootrom. It is always proprietary and is > stored in read-only memory, so it cannot be changed (in that case, it almost > seems to behave like hardware). However, regarding the bootloader, the > situation is different for each platform. There are actually multiple stages > of bootloaders, some of which can be free. However, it also occurs that the > bootloaders are cryptographically signed with a private key. In that case, the > bootrom will check the signature against a public key that cannot be replaced > and only run the bootloader if the signature matches. That sort of tivoization > prevents replacing pre-installed bootloaders, even when their sources are > released as free software. There are some good platforms that don't perform > such signature checks and can run free bootloaders (e.g. Allwinner Ax, TI OMAP > General-Purpose).</p>
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Replicant mailing list Replicant@lists.osuosl.org http://lists.osuosl.org/mailman/listinfo/replicant
