[Replicant] [PATCH 6/9] freedom-privacy-security-issues: Improve hardware freedom state description.

[Paul Kocialkowski]

Le mercredi 02 mars 2016 à 20:28 +0100, Denis 'GNUtoo' Carikli a écrit :
> Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo at 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>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.osuosl.org/pipermail/replicant/attachments/20160303/5bf4a3bc/attachment-0001.asc>