|
Pine64 Hardware and FSF RYF Certification
|
 Hi everyone, this is my first thread on this forum
 I'm wondering if Pine64 has the goal of having their HW (Hardware) RYF-certified? If so, then what is the current state of binary blobs for Pine64 HW? How many are there? Can they be replaced? Are they signed by some third-party vendor or something? Thank you everyone!
09-13-2019, 10:56 AM
I mused about this in another thread.
To me the bootloader and ARM Trust Zone stuff are the most interesting aspects of making the Pine64 fully open. Since my post there, I noticed that rockchip has documented the boot flow and an earlier SoC's bootloader has been partially reverse engineered. I'll be interested to watch further developments. 
It's not development. Development is when something, that didn't work, starts working or when worked poorly, - starts working better. because of someone's effort. And these bothering about and rummage in things that are not and will not be available "opensource" is a waste of time. it won't bring users any benefits. it's just yeah - stupid and vain entertainment for weird people. to demand everything be opensourced. ROM code not only is not open, most importantly - it's not replaceable. so all this pointless asking for opensourcing stuff, that needs not to be open is waste of time. you might get a "source" of it showing the blob inside has a Stallman photo bitmap, whereas in fact, there is Bill Gates photo inside. and all the freedom has evaporated. you cannot use your device anymore! because hell, there is smiling Bill Gates inside.
 The same goes to literally every peripheral device, you would need to run your SBC. take an SD card. this simple. or eMMC module. without these, SBCs won't run. All these devices have firmware inside, which you don't have source code of and never will. and which you cannot replace! so what's the point to mess around and ask these silly questions of "how open a board X is". why? why one would need that? never it is open 100%, never. period. the board producer provided you as much information as they could. so you can mainline and compile your linux every day. functionality, quality of software/hardware - these are the real concerns, that users should be bothered with (if they were driven by common sense). not the nonsensical "freedom" and opensaucing frigging ROM code. I start to wonder - why all these FSF dudes don't demand opensourcing car manufacturing, for example. or nuclear plant technologies. anything. because why not? the freedom© doesn't end on computers, right? let's demand every industry opensource everything. every bit should be GPLed! *sigh
ANT - my hobby OS for x86 and ARM.
09-13-2019, 03:20 PM
(This post was last modified: 09-13-2019, 03:37 PM by Der Geist der Maschine.
Edit Reason: Added another point about adaptability.
)
Open source is a prerequisite for trust. Some people want to trust their device.
Having the boot rom's documented source code available is the first level of trust. From time to time people add new features and implicitly go over the source code. This process builds more trust over time. The problem is the hardware. You can never really trust it. Undocumented controllers or, as z4v4l pointed out, the controller firmware in general, or the hardware circuitry programmed by (even open source) firmware. Another point: open source let's you adapt source code to your needs. Here and there I need to do this because upstream is not reacting to bug reports and provided patches. This is also true for the boot firmware. In the case of Rockchip, it's a design mistake to provide boot-rom and not boot-spi flash. PS: When it comes to trusting software, one should also be aware of Ken Thompson's Turing Award lecture Reflections on Trusting Trust https://www.archive.ece.cmu.edu/~ganger/...ompson.pdf
09-13-2019, 03:29 PM
(09-13-2019, 03:20 PM)Der Geist der Maschine Wrote: PS: When it comes to trusting software, one should also be aware of Ken Thompson's Turing Award lecture Reflections on Trusting Trust https://www.archive.ece.cmu.edu/~ganger/...ompson.pdf I was looking for that link-- you beat me to it! Another, and completely separate point: even aside from trust, it can be educational and even sometimes useful to learn about different firmware and experiment with them. You might think of your car's firmware as something you wouldn't want to mess with; but in fact firmware tweaks can often get you a little more torque or a gear ratio you like better. Monkeying with your car's ECU, or your single board computer's boot loader, may not be everyone's cup of tea, but I think it's far from pointless.
you missed the point, that it's irreplaceable, - you need your own SoC design/manufacturing facility to "monkey" with this kind of stuff, you need to become Rockchip, TSMC etc. and when you become Rockchip. TSMC etc, you find that having all things open to anybody is not such a cool idea - unless you are going to be a charity organization. but eh, as with all irrational things, it's impossible to argue a productive way.
Quote:In the case of Rockchip, it's a design mistake to provide boot-rom and not boot-spi flash.It's not any special to Rockchip, every ARM vendor does so. and I don't see it a "mistake". The purpose of ROM code is to reliably start out of reset and to load the platform firmware, for which there is storage provision in form of SPI flash as well (and eMMC, SD too). This way, the possibility of entirely bricking the chip is lesser. additionally to being a more reliable way, it is much more flexible. You want to "monkey" with the board, and they (Rockchip, Allwinner) need their SoCs to be selling. they earn money for living, not making SoCs for fun and "monkeying". and angried users that bricked their devices irreversibly after trying "better things" from some c00lh4ck3r freedom lover will be a serious obstacle in achieving that.
ANT - my hobby OS for x86 and ARM.
09-13-2019, 05:38 PM
All the years, board schematics and bioses have been closed source (at least for remotely usable hardware). Pine64 is doing something exciting. They build a fully functional laptop and open source major parts: board schematics (not yet) and major parts of the boot process. Let's see where we are in 15 years.
z4v4l, you are right in as long as there is one single proprietary component, there can't be complete trust. But the more parts are open, the more difficult it is to technically compromise trust. This builds some trust. In this thread, I briefly explained how AST2500 is booting up https://forum.pine64.org/showthread.php?...9#pid49759 That's very elegant. BTW: on our spi bus, we have a mux. So, if we brick our primary spi boot flash, we can switch to the secondary spi boot flash, boot from there and repair our primary boot flash. Almost fool-proof. Well, then one can always physically replace the bricked spi-flash with a working one.
hehe, this is exactly how x86 machines start - CPU executes the memory mapped code in the SPI flash. and, as you can see, it doesn't give you any "trust" you want. you don't trust it, am I correct?
and nothing more elegant in that method. it's just a more cut off variant not giving flexibility in choosing the boot way at this level. for PCs, it's ok, because they conventionally all have such SPI chips for firmware and all boot OSes from the same source - beefy HDDs/SSDs. for mobile, SPI NOR (NAND. eMMC etc) may be not present all, there is no single conventional source of booting, even for firmware, it may be any of those mentioned, it's decided later on the board design level, so SoC vendors need to devise a little bit smarter way of choosing where to go next - this is what ROM code is for and what it does. it chooses, based on board configuration what to boot from - SPI, NAND, SD, eMMC and proceeds. it's a minimalistic, yet pretty capable piece of code and it's always there, always guaranteed to work - much better, much flexible. you want SPI for FW - get it, another one wants to boot from boot areas of eMMC - okay! your "elegant method" is not able to satisfy this as easy (it's more restricted - requires SPI that narrows choices for board makers - pins are shared), but moreover, - it is not suitable for end users, since it lets them break things easy, but for fixing it, they would need to learn what the fsck "pinmux" is and get some soldering skills. again, it's not a "tinkerer workshop" or classes for learning, SoC vendors sell products, the products cannot be breakable easily. all SoCs I am aware of have this model and it's a good model.Pine doesn't have any influence on the boot flow of the firmware. other ARM SoCs aren't "more open source friendly." as you call them. lol, Apple is so "friendly", that one barely can know about their phone SoC anything but ad blurb. often you won't get even a TRM for the SoC, say mediatek or marvel, qualcomm. nothing available. we must be thankful, that these fabless vendors from china making their SoCs mostly for android OTT boxes (and not for SBC tinkerers overly bothered with "trust"), provide some documentation at all. in the end, on the example of the discussed ROM code, we see, that its openness is not needed - 1) there are no secrets over there, it's basic boot initializing and choice decision for the boot source and 2) it's made permanent inside an SoC for reliability, but the permanence makes opensourcing it pointless. however, there are fileds where there are secrets*. just look at this hidden GPU land - total lack of information, vendors are afraid of losing their technological achievements, this is what matters, not the imaginary "trust". why do you want this trust in computers and not in, for example gasoline? why don't you demand that all the technological process of gasoline production had been disclosed? or food. beer. why not demand all breweries over the world open recipes of their products? come on, it's not serious. * - actually, ROM code as well may need to be kept secret, it starts in Secure mode after all! there might be things related to providing security - ironically, ROM code then would be what is called The Root Of Trust - and obviously, it should not be modifiable or even readable outside of Secure world, definitely it's not the same "trust" you want. and here, I suspect, you, freedom guys, and hw vendors, have different understanding of who should own this root. the former apparently would say - if we bought a device, everything related to it, should be at our discretion (which is not true). the latter would say, it's security, we care about you (you are important to us ), security isn't being done this way, if we let everybody modify it, no security will be available and you will become a target of attackers. their power is ability to make it, yours is ability to not buy, what is stronger?
ANT - my hobby OS for x86 and ARM.
09-17-2019, 03:53 PM
A development I find exciting: Andrius Štikonas documented how to boot RockPro64 without any binary blobs and with the ARM Trusted Firmware built from source. In the process he modified the default baud rate from the serial console to match the one used by the Linux kernel, which might help prevent some of the issues people have been having with unreadable output. His posting is here: https://stikonas.eu/wordpress/2019/09/15...rockpro64/
10-18-2019, 06:24 PM
(09-13-2019, 03:29 PM)MikeInMass Wrote:Hmm ?(09-13-2019, 03:20 PM)Der Geist der Maschine Wrote: PS: When it comes to trusting software, one should also be aware of Ken Thompson's Turing Award lecture Reflections on Trusting Trust https://www.archive.ece.cmu.edu/~ganger/...ompson.pdf IT may be possible to change or maybe improve your torque, BUT No amount of writing code can change how many physical teeth are on a gear, The ONLY way to change a "Gear Ratio" is by physically changing them. (except in a sci-fi movie where any thing can be fixed by pushing a few buttons) Sorry, |
