[Replicant] [PATCH 4/9] freedom-privacy-security-issues: Add an example of where the hardware knowledge is.
Paul Kocialkowski
contact at paulk.fr
Thu Mar 3 11:12:39 UTC 2016
Le mercredi 02 mars 2016 à 20:28 +0100, Denis 'GNUtoo' Carikli a écrit :
> Many people do think that the hardware knowledge is only in the kernel.
> This is to prevent confusion.
I agree with the idea, see comments below.
> Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo at no-log.org>
> ---
> 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 faa9218..65fc54a 100644
> --- a/freedom-privacy-security-issues.php
> +++ b/freedom-privacy-security-issues.php
> @@ -7,7 +7,7 @@
> <p>Mobile devices such as phones and tablets are
> taking and increasingly important part in our computing, hence they are
> particularly subject to freedom and security concerns. These devices are
> actually full computers with powerful hardware, running complete operating
> systems that allow for updates, software changes and installable applications:
> this makes it easy to run <a href="//www.gnu.org/philosophy/free-sw.html">free
> software</a> on them. Mobile devices are often used for communications and
> provide hardware features that are sensitive when it comes to privacy and
> security: GPS, camera, microphone, etc, in addition to storing the user's
> data. Hence, they are particularly subject to being used to spy on the
> user.</p>
> <h3>A simplified overview of mobile devices</h3>
> <p><a href="images/freedom-privacy-security-
> issues/hardware.png" data-lightbox="overview" data-title="Hardware-side
> overview"><img src="images/freedom-privacy-security-issues/hardware.png"
> alt="Hardware-side overview" style="width: 250px; float: left;"/></a>On the
> hardware side, mobile devices are built with a system on a chip (SoC) that
> includes a processor (CPU) and various other fundamental components, around
> which are found various integrated circuits, memory (RAM), storage, user
> input/output (I/O), etc. When the device is telephony-enabled, it also
> features a modem, which is the component in charge of dealing with the mobile
> telephony network. Nowadays, it is usually has a powerful processor, with
> dedicated memory and sometimes storage.</p>
> - <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 in 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.</p>
> + <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 in 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
I think "placing a call" would be a better fit.
> , the dialer application will communicate with the framework, which in turn
> will communicate with the hardware abstraction laye
> r. That hardware abstraction layer will implement the protocol to speak
"speak" sounds a bit odd, I suggest using "communicate".
> with the modem, and the Linux kernel will be responsible of permitting
"permitting" doesn't quite describe what it does. How about:
"That hardware abstraction layer will implement the protocol to communicate with
the modem. The kernel will handle the transactions between the hardware
abstraction layer and the modem, driving the required bus controllers."
I'd avoid mentioning Linux since this description is general ("kernel" is
sufficient).
> 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
> doesn't quite exist as of today, or barely. 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>
-------------- 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/4045b207/attachment-0001.asc>
More information about the Replicant
mailing list