One of the side effects of software eating the world is that the world becomes more exploitable. I expect that over time we may see the emergence of general 'software building codes' much like there are physical building codes, and more importantly liability associated with failing to provably meet such codes.
The current 'random person implements firmware that controls the this chip' practice and the 'no warranty etc etc' disclaimers will, I predict, be replaced by manufacturers who are willing to warrant their code.
I am getting tired of seeing physical building codes thrown around in comparison to software. I've looked at residential building codes, because I've done my own work like building a deck, framing and finishing my basement, and researching how to build concrete & steel suspended floors, or wood floors - seeing what their spans are - seeing how lightweight steel framing vs wood framing works - it's quite fascinating. (I was considering designing my own house, but the wife shot that down)
And there is simply NO COMPARISON in complexity to software. In physical building, you over engineer and get redundancy. You also know that almost everyone builds plumb and level, rectangular rooms, with easy span and shear calculations. You also know that wood follows a predictable strength pattern. So you put in enough nails of the right length, to enough wood of the right thickness, and you're good. How much intelligence do you think you need to follow a building code? Building materials and techniques change GLACIALLY compared to software. (A good thing!)
Whereas in software, one single bit flip will just fuck you up.
The complexity of software doesn't preclude standardized "building codes." Obviously the codes would have to be just as complex, but software could be used to check that those codes are met. It wouldn't be perfect, but current building codes for physical buildings also have their flaws (every building [vs design] needs to be physically inspected by a person [much easier to exploit than a machine]).
These already exist, for example it is very difficult to build biomedical software that gets hooked up into a living thing - even if you use it only for research. In practice such a hard realtime guarantee can only be met by a devices like an FPGA. All of this is in a code.
Real issue here is why such codes don't exist for for this particular problem.
In practice such a hard realtime guarantee can only be met by a devices like an FPGA.
There have always been fully deterministic CPUs around for that purpose. The simpler the system, the better; just hook a Forth chip to a memory without caches and you're set.
No, but I don't see any flaw in that design. Indeed, it seems like the case of Hoare's "obviously no deficiencies" in a system design.
I believe that the GreenArrays people, setting aside the $450 dev board, also had some notes on making cheap breadboards with their chips or something like that. I don't have a link handy, though. ;/
Between writing and formally verifying HDL, logic synthesis (often using third-party or vendor-provided blocks or soft IP, mind you), behavioral and logic simulation (software!), layout, MDP, and building test harnesses that actually test the final hardware, I would actually trust a lower-level language compiled using a well-known compiler and running on a small RTOS on a proven CPU more than I'd trust a new design synthesized into FPGA or especially ASIC form.
Only a win if you have some reason to believe your code will be any less buggy when you inevitably start on your own ad-hoc reimplementations of those abstractions.
You probably don't want a system where all the hardware and software for controlling mobile radios is readily accessible to and modifiable by anyone. You might think you do, but the first time you try to call an emergency service and you can't get through because one idiot somewhere in range of the same base station has screwed up his debugging code and jammed a control channel, you'll change your mind.
I've been the guy who drives around in a truck with a lot of mobile scanning equipment to try and figure out where the rogue device is. There is no magic button like in the movies, where they can immediately triangulate the source of the interference to within a 5 cubic metre box. You basically have to rely on simple physics and boots on the ground. The device you're hunting for isn't playing nicely, so any assumptions you could normally make based on things like which base stations it's in contact with won't necessarily be valid. Things are a bit smarter in modern networks than they were back when I worked in the field, but physics is still physics.
In short, there is a legitimate justification, born of experience, for every telecommunications regulatory authority in the known universe requiring this stuff to be certified before you can legally use it. This is also why in some jurisdictions agents acting for telecommunications regulators have certain legal rights to access private property.
Of course this only affects the radio equipment. I see no reason it should be necessary or possible for such software to have any control over other integrated peripherals such as cameras, speakers, microphones or local storage. And the primary concern is people who could modify the code and break the network, not preventing any legitimate audit to prove that devices are only doing what they say they're doing.
The FCC already regulates who can broadcast what over the airwaves. And if you're not licensed for that part of the spectrum, the source code will do you a fat lot of good with your radio experimentation.
Nobody is asking for some sort of hacker radio anarchy, here. They're asking to see the source code for machines they own, machines that reside in their pockets, machines that are responsible for storing and communicating their most sensitive personal data.
If you cause the device you own to operate according to your own will (i.e. the core concept of FOSS) instead of the will of the carrier, there is a strong likelihood it will cause a denial or degradation of service for everyone else.
Verizon has the right to transmit on spectrum allocated to it using consumer devices as its agents. It employs engineers and QA processes to make sure that any device transmitting on its spectrum plays well with others before it is allowed to leave RF-isolated testing facilities.
The public does not and should not have the right to transmit on Verizon's spectrum, even using devices they own which are legally and technically capable, except according to Verizon's carefully vetted programming. If they were able to run their own radio firmware, you'd have the situation described in the parent.
Cellular radios necessarily cannot be open source. The source could be released for inspection and audit, but it cannot be possible or permissible for you to run modified source on "your" radios.
Open source != free (libre) baseband hardware that you can directly modify the software on. Being able to compile and modify is fine and has no impact on the network if you're not able to run it on the primary network.
A country could enforce openess of the source code for imported software and firmware.
- If Toyota (or any car manufacturer) wants to import cars into my country, then they better show us the sources of their firmware and software (and let us re-compile it and re-install it, to make sure it corresponds to the embedded code). And let the papers compare the code quality of Toyota vs. BMW.
- If Microsoft (or any software vendor) wants to import software into my country, then they better show us the sources of their systems and applications (and let us re-compile it and re-install it, to make sure it corresponds to the binary code, and doesn't contain backdoors to the NSA (or the MSI, or the MI5 or whatever).
- and so on.
And actually, citizens can do the same at their level, not letting enter their house any device or software whose code is not open source or even libre software (so they can recompile it and reinstall it on their hardware).
But a country has more weight than a few citizen that would be qualified of lunatics, and has more resources to analyse and validate the software and firmware.
This is essentially what Alexandria used to do: any ship coming to port with any books on board was required to give the library at Alexandria those books for as long as it took for their scribes to copy them. The library then gave the ship owners the copied version (because hey, data is data, what does it matter if you have the original or secondhand copy?)
This helped propel a lot of the world's best ancient thinkers, including Euclid, Archimedes and Eratosthenes.
> And actually, citizens can do the same at their level, not letting enter their house any device or software whose code is not open source or even libre software (so they can recompile it and reinstall it on their hardware).
I tried that, but at the moment it means you can't even own a cellphone, etc
Or a new stove, microwave, alarm clock, gas meter, coffee-maker, smart thermostat, ... Limiting yourself to only open-source SW (nevermind HW) is severely crippling, I'd imagine!
hardware manufacturers should be less concerned about what their firmware reveals about their IP and more concerned with what not revealing their firmware source code reveals about their security.
the fact that you can get DMA by compromising _any_ device on the bus is a problem too. imo, none of these peripherals should have unmitigated DMA.
Thats easy to just say, but how wil you financially protect the company developing the software / hardware, if their competitors can just copy the work. Or stated the other way round, how will you keep companies encentivised to develop new software / hardware?
Actually quite the opposite. If legislation were passed that required an entire industry to open source their firmware (automotive, voting machines, medical, etc), it would provide better IP protection. Did company A copy company B's code? Well it's open source ... go look! As opposed to being able to hide things in binaries.
But yes, this only applies if the competition must also open their kimonos. That seems practical for industries where regulation is required or provides reasonable benefits to society (automotive, voting machines, medical, etc).
Making the source code visible would probably be sensible in this case though, so I think the idea is a good one even if you need to be careful with the terminology.
Sorry, I forgot to put the necessary disclaimer in my post stating my intended meaning of open source. You're right, I used it in the 'visible' sense of the word, not 'libre'.
I think it is a consequence of the fast improvements in functionality made. People would rather be on a feature rich beta branch, than a safe stable branch. I also expect this to change as the industry matures.
After some particularly huge disasters I've had to deal with coming onto new projects and with general consumer electronics, I'd go for the latter every time both as a consumer and company these days. Time is valuable and losing it to a feature packed unreliable mess is a big risk to that time.
You're right - there is a tradeoff between features and stability, but "consumers vs companies" is an oversimplification. It's about the probability of something breaking, and the consequences of what happens when it does.
For a company with a large workforce, the probability of something breaking is higher - many different machines being used in different ways, and the cost of a botched upgrade can run into millions, with people losing their jobs, and legal action being taken.
For consumers, the risk is typically lower and less costly if it goes wrong. If a Facebook upgrade causes the app to crash repeatedly, it means I can't post for a while, so I'll just upgrade and hope for the best. But if a personal finance or medical app goes wrong the consequences could be extremely serious, so stability is more important.
Yeah, sure, but many don't even try, and as the root comment suggests individuality and lack of enforced common rules and paradigms help to raise insecure software and devices.
Extending that metaphor, a profession could evolve around zoning for permissible uses of code based on types of software and intended audience, much like urban planners do with zoning codes and city master plans.
Possibly; there are already standards in certain areas. But it can greatly increase cost and time-to-market, so even when there are codes corners will be cut. See the Toyota lawsuit at the moment.
Oh, and applying pretty much any "software building codes" to the web app industry would probably kill startup culture entirely.
> applying pretty much any "software building codes" to the web app industry would probably kill startup culture entirely.
Not necessarily. To use the analogy with the building industry, there are different requirements depending on what the building will be used for. Startups holding or processing financial information might have one set of regulations, whereas those hosting cat pictures might be less rigorous.
But at the same time, the consequence for access of account information for cat pictures site on the site holding financial information shouldn't be discounted (passwords, social engineering info etc).
To continue the (somewhat stretched) building analogy my house falling down doesn't affect yours, but someone stealing my access codes from my poorly secured building potentially could affect the security of yours.
This is very unlikely because such embedded software operates on extremely low level and it's completely dependent on a particular hardware design (not just the chip, but the whole architecture). It's extremely hard to make that portable enough to make it sellable, especially with the speed of technology advances today.
The current 'random person implements firmware that controls the this chip' practice and the 'no warranty etc etc' disclaimers will, I predict, be replaced by manufacturers who are willing to warrant their code.