Just a suggestion, would it be worth putting this into something like pastebin or a document that can be directly edited? It seems like referencing lines would be cleaner than putting the entire document in every email. I do think this sort of documentation is very important but honestly, I'm not even sure what document you are discussing or what its relevance is to this project. I just woke up yesterday and found a bunch of really long messages in my inbox. Not a problem for me since I have time to do a bit of research but some members of the mailing list might be even more confused. I understand what "hardware freedom state description" is after reading it but where is it located on what site? These things need context. The lack of context scares away potential contributors, like myself. It looks like you're diffing .php files but again, not all members of the list will understand what this implies or know what to do with it. I think it is important to have a clear statement of intent in the message. Perhaps near the top of the message body. I often get lost in the more technical discussions since I am not very knowledgeable but this discussion should be accessible to most of the community since grammar and programming and web development are very different skill sets. Food for thought. Sorry if my subject is malformed, that formatting is also unclear to me. Ignore me if I've overlooked something silly but it may be good insight from someone with little experience in these matters. On 3 Mar 2016 11:05 am, <replicant-requ...@lists.osuosl.org> wrote:
> Send Replicant mailing list submissions to > replicant@lists.osuosl.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.osuosl.org/mailman/listinfo/replicant > or, via email, send a message with subject or body 'help' to > replicant-requ...@lists.osuosl.org > > You can reach the person managing the list at > replicant-ow...@lists.osuosl.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Replicant digest..." > > > Today's Topics: > > 1. Re: [PATCH 5/9] freedom-privacy-security-issues: Free > hardware do exist today. (Paul Kocialkowski) > 2. Re: Patches for the website. (Paul Kocialkowski) > 3. Re: [PATCH 6/9] freedom-privacy-security-issues: Improve > hardware freedom state description. (Paul Kocialkowski) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 03 Mar 2016 16:49:04 +0100 > From: Paul Kocialkowski <cont...@paulk.fr> > To: Denis 'GNUtoo' Carikli <gnu...@no-log.org> > Cc: replicant@lists.osuosl.org > Subject: Re: [Replicant] [PATCH 5/9] freedom-privacy-security-issues: > Free hardware do exist today. > Message-ID: <1457020144.1448.2.ca...@paulk.fr> > Content-Type: text/plain; charset="utf-8" > > Le mercredi 02 mars 2016 ? 20:28 +0100, Denis 'GNUtoo' Carikli a ?crit?: > > Signed-off-by: Denis 'GNUtoo' Carikli <gnu...@no-log.org> > > Subject has a grammar mistake: hardware is singular so it should be "does > exist". > > Free hardware means a fully free hardware design (both at pcb and chip > levels). > I don't know of any mobile devices that fits the chip-level hardware > freedom > requirement, so I think it's fair to say that free hardware doesn't exist > in the > scope of mobile devices. > > Perhaps the current version should contain this analysis, emphasis that > it's > about mobile devices. Also it should contrast with the rest about hardware > freedom not being a practical possibility for most people. > > > --- > > ?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 65fc54a..31d8310 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 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, 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 > 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 > > 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> > > + <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>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 really 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/b3252cd7/attachment-0001.asc > > > > ------------------------------ > > Message: 2 > Date: Thu, 03 Mar 2016 16:51:05 +0100 > From: Paul Kocialkowski <cont...@paulk.fr> > To: Denis 'GNUtoo' Carikli <gnu...@no-log.org> > Cc: replicant@lists.osuosl.org > Subject: Re: [Replicant] Patches for the website. > Message-ID: <1457020265.1126.6.ca...@paulk.fr> > Content-Type: text/plain; charset="utf-8" > > Le mercredi 02 mars 2016 ? 20:28 +0100, Denis 'GNUtoo' Carikli a ?crit?: > > Since I didn't finish to review freedom-privacy-security-issues.php, > > other patches series might come in the future. > > Feel free to add more in v2 then. > > Note that I sent some answers to you in double, with my replicant.us email > address. For patch-related matters, I use my paulk.fr address (this > address). > Please use it for sending further patches! > > Thanks for the patches. > > -- > Paul Kocialkowski, Replicant developer > > Replicant is a fully free Android distribution running on several > devices, a free software mobile operating system putting the emphasis on > freedom and privacy/security. > > Website: https://www.replicant.us/ > Blog: https://blog.replicant.us/ > Wiki/tracker/forums: https://redmine.replicant.us/ > -------------- 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/8a678d64/attachment-0001.asc > > > > ------------------------------ > > Message: 3 > Date: Thu, 03 Mar 2016 17:04:25 +0100 > From: Paul Kocialkowski <cont...@paulk.fr> > To: Denis 'GNUtoo' Carikli <gnu...@no-log.org> > Cc: replicant@lists.osuosl.org > Subject: Re: [Replicant] [PATCH 6/9] freedom-privacy-security-issues: > Improve hardware freedom state description. > Message-ID: <1457021065.1126.12.ca...@paulk.fr> > Content-Type: text/plain; charset="utf-8" > > 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> > -------------- 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.asc > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Replicant mailing list > Replicant@lists.osuosl.org > http://lists.osuosl.org/mailman/listinfo/replicant > > > ------------------------------ > > End of Replicant Digest, Vol 169, Issue 8 > ***************************************** >
_______________________________________________ Replicant mailing list Replicant@lists.osuosl.org http://lists.osuosl.org/mailman/listinfo/replicant
