Slashdot Mirror
Why Cybersecurity Experts Want Open Source Routers (vice.com)
derekmead writes: A coalition of 260 cybersecurity experts is taking advantage of a Federal Communications Commission (FCC) public comment period to push for open source Wi-Fi router firmware.
The cybersecurity experts asked the FCC on Wednesday to require router makers to open-source their firmware, or the basic software that controls its core functionality, as a condition for it being licensed for use in the US. The request comes amid a wider debate on how the FCC should ensure that Wi-Fi routers' wireless signals don't "go outside stated regulatory rules" and cause harmful interference to other devices like cordless phones, radar, and satellite dishes.
The cybersecurity experts asked the FCC on Wednesday to require router makers to open-source their firmware, or the basic software that controls its core functionality, as a condition for it being licensed for use in the US. The request comes amid a wider debate on how the FCC should ensure that Wi-Fi routers' wireless signals don't "go outside stated regulatory rules" and cause harmful interference to other devices like cordless phones, radar, and satellite dishes.
good luck! check out this provision in the TPP: http://www.international.gc.ca... Prevents governments in TPP countries from demanding access to an enterprise’s software source code.
They want to see the source for the radio. I get that. But let's call these devices what they are: access points.
Exposed to the internet, never monitored, never updated, and sits between a computer and the internet, the textbook definition of a man in the middle attack..
Government intelligence agencies can help contribute to the code base.
The IRS can then help watch people more and help them form more correct political views.
The FEC can then help the Party making sure helpful people are able to help more!
Firmware can be extremely messy, low-level code. It may not even be written in any sort of recognizable programming language. It is frequently the digital equivalent of a set of jumper switches, just a binary blob which is meaningless if you don't have deep knowledge of the hardware it is controlling. Firmware can directly control low-level electronics and an incorrect setting can lead to physical damage to the device and potential harm to nearby humans.
It is dangerously stupid to insist that firmware be open-sourced and to allow developers to modify the firmware on devices.
Below is the text of another comment a career security professional (myself) submitted to the FCC on this issue. Specifically, this is regarding the FCC's proposal to essentially outlaw open routers, by requiring that the firmware be boot-locked.
Based on 18 years of professional experience in network security, in both the private sector and government, the proposed rule causes significant concern for information security posture. There are three primary reasons. The legitimate goals of the FCC could be achieved in an alternate manner which does not cause the same widespread security vulnerabilities, by instead requiring that output power levels and any other critical parameters be limited to legal levels by a separate chip. This approach would be far superior to effectively banning proper security practice for the ENTIRE operating system and all utilities on the device, as the current proposal does.
1
The proposed rule which requires that manufacturers disallow firmware updates (other than signed manufacturer updates, typically provided for only a very short time), makes it much more difficult to prevent incidents such as the $45 million loss at TJX and the Target breach. In both cases, the victim companies were initially targeted because insecure wifi devices were in use. To reduce future occurrences of such breaches, it is imperative to be able to update devices which use wireless networking. Especially when a vulnerability such as Shellshock is discovered, it is imperative that risks be mitigated immediately.
Updates provided by the manufacturer may at first seem to be a possible solution, but are not actually a viable solution for two reasons. Manufacturers generally do not provide long-term updates, updates for devices more than about one-two years old. In many cases, no updates are offered at all to handle issues after the date of sale. It is not reasonable to anticipate that organizations and families will replace their network gear every year or two - firmware updates are needed, including for devices which are a few years old. Perhaps ESPECIALLY for devices which are a few years old.
Secondly, updates from the manufacturer are not a viable solution for more sensitive government and private organizations due to the response time required. In the first 24 hours after the release of Shellshock, thousands of systems were compromised. For many networks, it is critically important to mitigate the threat during this initial time frame. Manufacturer full updates were not available for several days to several months, as we first discussed the best long term solution and that solution propagated downstream from the authors, to the subsystem maintainers, distribution maintainers, OEM repackagers, and finally out to customers after testing at each level. In the meantime, temporary MITIGATIONS were performed on-site by network engineers and security contractors. These vital mitigations which protected sensitive networks in the interim would be illegal and prevented by manufacturer locks under the proposed rule. In simple terms, the proposal makes it illegal to manufacturer equipment which can be _quickly_ protected against new threats to our cyber security.
2
Another reason that the proposed rule is problematic is that the manufacturer default firmware, with all available features designed to be as easily accessible as possible, is not appropriate for any environment in which security is a concern. A central tenet of information security, and security in general, is that the attack surface should be as small as possible - services not needed for a particular installation should not be installed and enabled. The only software which definitely cannot be exploited is software which is not installed or not enabled. Therefore, the most secure firmware tends to be that with as many features _removed_ as possible, with only those items required for the current role installe
How about this for a title: FCC is trying to strip more of your individual freedoms away, EFF objects.
You can't handle the truth.
Ban isp from forcing you to rent there hardware / make them give you a true bridge mode / pure Ethernet handoff
I imagine that getting the firmware that handles some of the new-hotness RF stuff that allows breathlessly advertised high data rates from those vendors would be like pulling teeth; but I wouldn't be entirely surprised if the vendors who put the 'router' together and build the firmware image would be, in part, pleased by a "we have to share ours; but so do all our competitors" situation.
Clever wireless NIC tricks can be an actual competitive advantage; but the "Outdated kernel, busybox, and lighthttpd" side of the equation is mostly one pointless, half-assed, reinvention of the wheel after another. Something you have to do in order to ship; but hardly a selling point.
The firmware in routers is very often Linux. Since Linux is open source, you can download the firmware for many routers and see for yourself. the firewall on the router is the same iptables firewall that runs on my desktop and my laptop. See OpenWRT and the *WRT distributions which are variants of the Linksys firmware for more.
Many of the manufacturers selling routers sold in big-box stores, such as Linksys, have wanted to save a couple of dollars by having a couple MB less memory, they've transitioned to another Unix-like OS that's tailored to lower memory devices, but it's still very much like the Linux they were using.
There is no conflict between the two (sensible) requirements that:
(A) The router's source code should be freely inspectable
AND
(B) The router should have strong technological measures to prevent users from using it in a way that violates the terms, for instance by transmitting on a band that is not licensed in that country.
This is also a very good model for the automotive industry -- another place where there is laughable security that merits some real auditing, but at the same time it would be ridiculous to allow any kid with a $50 flasher to get a few more horsepower by emitting particulates that are known health risks.
Certainly there is no technical reason that "I can view the source" must mean "I can modify and recompile the source and have the system accept the binary as authentic". TiVo (much to RMS' chagrin) adopted the model, as does Android (for some models, other's advertise open bootloaders, consumers chose between them).
Admittedly, this won't satisfy the software-freedom purists, but at the same time we have to have some logical partitioning between a home computer (that you should control down tot he metal) and a computer that controls particulate emissions that harm others' health or a router firmware that can block others' usage of our shared airwaves.
[ And to that point, it would be great if there was software partitioning such that I could tweak my car's systems but not the ECU portions that control emissions. Or modify the router's linux base to add features (disclosure:I do run DD-WRT actually, but not on a WiFi device) but lock the radio in such a fashion that I don't interfere with my neighbors' networks. There's certainly no technical reason this can't be accomplished. ]
the FCC should ensure that Wi-Fi routers' wireless signals don't "go outside stated regulatory rules"
But the router could just sense the test apparatus, and go into "clean" mode when detected.
Open access to the source code of consumer routers is an excellent idea. However, one of the bigger problems is that often elections take statistically bizarre turns, sometimes affecting access to other data... Why not start with mandated open access to source code of voting machines. It doesn't have to be open source per se, but at least inspectable so that outright fraud can be addressed....
I think not...(*poof*)
Along similar lines I proposed that certain devices be locked. I approached as a consumer. Power output strength etc. Anything that the FCC governs to protect interference.
WiFi routers can't output beyond their class governance because some kids were having fun. Esp in this age where people can download this from others without understanding the impact. One person was experimenting with friends to see if they could send a signal 30 miles across Kansas - this can't be used in the middle of a big city.
General operation, features, etc need to remain dynamic. In this throw away world - I bought a router that never had updates beyond the day it was made. There were bugs - feature and security. Loading an open source code base onto it fixed my issues and gave life to the device.
But I also suggested that manufactures might be held accountable for this. Each new platform maybe needs a backward compat. Think of video card companies - at least one has a single driver that works with all hardware. Why are people doing this? Some are having fun, pushing the envelop, creating tomorrows tech... others because they paid $200 for a device that was obsolete when they got it home.
Government shouldn't prohibit tinkering with firmware. It should also not require open sourcing anything. If people want routers with open source firmware (like myself), we can buy them. Other people couldn't care less.
Really people, stop proposing stupid rules.
It happens like this:
(1) Companies write TPP and other laws to indemnify themselves and resist modifications to their buggy routers.
(2) FCC makes the problem worse by effectively requiring DRM on routers.
(3) incidence of serious hacks skyrockets as people are unable to update their routers and other network-enabled devices.
(4) legislators react to spike in online crime/tragedies not by undoing (1)-(3) but with "get tough" anti-"hacking" laws that chill research and throw people in jail for minor transgressions, research, clock-building, vulnerability disclosure, security tools, or a anything not understood that politicians and aggressive prosecutors could perceive as "hacking".
(5) The problem gets MUCH MUCH worse as a result. Bright minds are tossed into jail, open research is chilled, and online crime continues to skyrocket.
(6) GOTO 4.
-------------------
This is my SIG. There are many like it, but this one is mine.
Here is the source for my router. It's written in Z.
You need a Z compiler? Here is one.
Oh you want the source for the Z compiler? Here it is, written in Z. You just have to compile that with this binary version of the Z compiler, which has no suspicious code, I swear!
as long as you don't call them "rooters"
The TPP effectively takes control of the www. If we follow the adage of "the Internet treats censorship as damage and routes around it," then we can see that what will most likely develop is a network that is outside of the www. The easiest way to implement such a network in the U.S. is with Wi-Fi-type devices, but if those devices are locked down, not just legally, but physically, then this task becomes yet harder, especially with the ridiculously low power limitations placed on consumer controlled devices.
comcast metro e / comcast gig pro make you rent that hardware and the basic price should have that built in.
Comcast kind of when you get cable phone
FiOS you can rent or buy there gateway.
You, however, seem to be confused about what firmware is because you are comparing it to "complicated software". And this has been my experience with software engineers--it is impossible to convince them that there is knowledge in this world which is not directly mappable to some sort of software.
There are parts of firmware that are just not understandable unless you have deep knowledge the specific hardware device sitting in front of you, in some cases down to the circuit level (or below, even). It is unreasonable to insist that hardware vendors document their devices down to that level and it is dangerous to allow random idiots to muck about with that firmware.
Similarly, if one has a wi-fi card in one's PC, it is subject to this limitation, as is the drivers used it access it. If the FCC wished, they could engage in interpreting the proposed rules to prevent drivers from being changed in machines using wi-fi cards. Fortunately, the don't wish so at the moment.
davecb@spamcop.net
I think you misconstrue things. Focus on your use of the word 'effectively'. Seriously, dwell on that choice of words. There is no 'effective ban' as you suggest AFAICT. In fact from my very incomplete knowledge of the issue (but far more than 99.9% of the population), I would say that the FCC's existing verbiage supports precisely the goals you are trying to support. What I saw was something that encouraged the router manufacturers to do precisely what you described. I.e. make sure that firmware that is capable of violating spectrum rules be as small as possible to the point that the best strategy for a manufacturer would be to make it perfect. Non-updatable even. I.e. make a bug in that *minimized* portion of code such a rare event, that such a case could be handled by a traditional manufacturer recall scenario. AFAICT Vint Cerf and others are apparently fearful that the router makers will simply lock down the devices. But lets imagine that scenario in the context of your comment. If they did, anyone who wanted to could build their own router with a raspberry pi and a usb wifi dongle. In that case, the radio being physically seperatable, it is clear that the only firmware relevant to this issue is that in the usb wifi dongle. So this has nothing to do at all with people (even kids) being able to build a wifi router that they can have full control over (except the usb wifi dongle's firmware, or perhaps even some small subset of that).
Sure a router (like a PC, btw) runs Linux and C programs, but there's also a BIOS layer below that and perhaps even a microcode layer below that. What language is the microcode written in? There are also lots of device drivers that are essentially binary blobs where some HW guy has carefully tweaked settings. Sure, C & Linux can be used to deliver the binary blobs--but they are still binary blobs.
Some of the binary blobs configure very delicate internal circuitry that establish things like transmission frequencies (you know, things the FCC would care about).
My point is that there are all sorts of layers of "software" below the level of abstraction that software engineers are aware of. Smart people have concocted these layers so that you guys have a nice, relatively safe sandbox to play in. You have a clean programming model and you can't do too much damage. Firmware, however, is a different story. There are parts of firmware that are nasty and impenetrable and often require proprietary knowledge of the hardware to configure correctly and safely. There are parts of the firmware which, if misconfigured, can cause physical damage.
Unfortunately, the HW and firmware guys have done such a good job of hiding this nastiness from software guys that those software engineers have convinced themselves that the nastiness doesn't exist; and thus they lobby the government to please please force the hardware companies to give the software guys lots of rope to hang themselves with.
It's that simple. Yes, throw out your old crappy routers and pay more for routers which are properly supported by the vendor. The vendor has the expertise it needs to modify the firmware in a safe way.
As I said elsewhere in this thread:
"Sure a router (like a PC, btw) runs Linux and C programs, but there's also a BIOS layer below that and perhaps even a microcode layer below that. What language is the microcode written in? There are also lots of device drivers that are essentially binary blobs where some HW guy has carefully tweaked settings. Sure, C & Linux can be used to deliver the binary blobs--but they are still binary blobs.
Some of the binary blobs configure very delicate internal circuitry that establish things like transmission frequencies (you know, things the FCC would care about).
My point is that there are all sorts of layers of "software" below the level of abstraction that software engineers are aware of. Smart people have concocted these layers so that you guys have a nice, relatively safe sandbox to play in. You have a clean programming model and you can't do too much damage. Firmware, however, is a different story. There are parts of firmware that are nasty and impenetrable and often require proprietary knowledge of the hardware to configure correctly and safely. There are parts of the firmware which, if misconfigured, can cause physical damage.
Unfortunately, the HW and firmware guys have done such a good job of hiding this nastiness from software guys that those software engineers have convinced themselves that the nastiness doesn't exist; and thus they lobby the government to please please force the hardware companies to give the software guys lots of rope to hang themselves with."
The fundamental problem here is that software engineers are dangerously naive.
that hardware vendors should only be required to open-source the high-level [easily understandable and non-proprietary] parts? I wasn't claiming that all the software that runs on a given piece of hardware was deep and mysterious--but some parts of it definitely are, including parts that are of particular interest to the FCC.
it probably runs some form of microcode which is only modifiable by the vendor. Should that vendor be required to open-source the microcode?
I'm a HW engineer--I actually know quite a bit about a lot of types of firmware and I'm extremely qualified to have these opinions.
It's a layer of firmware sitting between you and the hardware, it's written by the vendor.
I never said anything about microcode being compiled from a high-level language--I said the opposite, that the existence of microcode is evidence confirming that there is some very common 'firmware' which isn't written in any soft of recognizable programming language.
I've actually designed a lot of hardware and I've written a fair amount of firmware in my life. Have you?
It is a layer of 'code' which tells a processor how to execute instructions. It generally gives the processor the ability to translate one opcode in the instruction set architecture into several interal micro-operations, and it usually has very raw access to the internal processor control (in some cases directly controlling internal HW muxes and whatnot). It's frequently used to permit emulation of otherwise deprecated instructions transparently to all layers of firmware and software above it. Generally there's some way to modify or patch the microcode post-silicon and thus it's a nice way for hardware vendors to fix silicon bugs in code--well hidden from all other layers of software.
I can't imagine how this doesn't fit anyone's definition of firmware. The proposed law can't just say "firmware", it has to actually define it. How would you define firmware in such a way that microcode isn't included?
Have you read -about- the proposal and not read the proposal itself?
The proposal specifically calls on manufacturers to prevent the use of OpenWRT, by name. OpenWRT is an operating system, not radio firmware.
Have you ever heard of Intel? Microcode is a form of firmware, by definition. In fact, IBM uses those terms interchangeably.
You are possibly the stupidest person I've ever met on /., and that's saying something.
It's that simple. Yes, throw out your old crappy routers and pay more for routers which are properly supported by the vendor.
... okay. I guess if a router is "properly supported", that means it doesn't have any bugs, so it will never need to be field-updated under any circumstances.
Also, if it's "properly supported", that means neither the manufacturer nor anyone in the supply chain will ever insert any kind of malware, so there's no reason to allow the code to be inspected for correctness.
Also, those 11 million VW diesel owners should have paid more for a properly supported car.
You've clearly thought about what would be reasonable for the FCC to do, given their mandate. You then assumed that they've done what would be reasonable. Here are the -actual- requirements which manufacturers must now include in their application for FCC approval. (Link to FCC application requirements document below). This one makes it pretty clear, doesn't it?:
2. What prevents third parties from loading non-US versions of the
software/firmware on the device? Describe in detail how the device is protected
from âoeflashingâ and the installation of third-party firmware such as DD-WRT
You said " would be extremely surprised if any language in the proposal itself could be interpreted as ... OpenWRT ". Well I guess you're surprised, because bam, they said it has to be protected from the installation of third-party firmware such an *WRT. Yeah, that's surprisingly unreasonable, which is why knowledgeable people are taking issue with it so much.
Here are a few more things that the FCC requires:
3. Describe in detail the authentication protocols that are in place to ensure that the
source of the software/firmware is legitimate. Describe in detail how the software
is protected against modification.
4. Describe in detail the verification protocols in place to ensure that installed
software/firmware is legitimate.
5. Describe in detail any encryption methods used to support the use of legitimate
software/firmware.
https://apps.fcc.gov/kdb/GetAt...
What you suggested, the -radio- settings being limited outside of the main OS on the device, is what I and other professionals are asking the FCC to do -instead-.
Your discussion of a general-purpose computer which happens to have an FCC-approved WiFi dongle (or mini-PCI card) attached shows how silly the FCC rule is, given that many routers in fact use FCC approved mini-PCI cards internally. Specifically, some Linksys models I've opened up have a standard mini-PCI card inside and it is (or possibly, was*) legal to sell the card without the plastic case and other bits that make up the Linksys router. Consumers could put that card onto any board, running any OS. But it's suddenly not legal to sell the same card preinstalled. That may sound too ridiculous to be true. Which is why we're trying to make it cease to be true.
* It's quite possibly illegal to sell the mini-PCI cards now because they are capable of generating beacon frames. The new rules say that anything which -can- generate a beacon frame is an AP. Which includes your Android phone that allows WiFi tethering. That's an AP now, and must have a locked bootloader. Yeah, that's beyond what the FCC should be doing to control radio power. It's a silly, ham-fisted approach. That's why we're writing the letters.
That's exactly what "properly supported" means in this context. You are intentionally being obtuse by claiming otherwise. It needs to be field updatable by the manufacturer. It does *not* need to be field updatable by the end user--that's a recipe for disaster.
I don't have any problem with the hardware device (including its code) being made subject to inspections & audits. It doesn't need to be open sourced for that to happen, the code doesn't even need to be made public--and you certainly don't need to enable any random C++ hacker to modify the firmware and upload that to the device.
What's happening with VW is what is supposed to happen, the standards and testing are becoming stricter (and may include design & code reviews) and the market is correcting and providing a strong disincentive for future tomfoolery. VW will have to pay to make their customers whole. This situation would be in no way improved by letting customers modify the firmware for the emissions control themselves.
The answer is to hold the vendors to a higher standard for compliance, not to enable end users to modify firmware for compliance. I think almost none of the energy behind the "force them vendors to make hackable hardware" movement has anything to do with enabling users to modify those devices to ensure compliance with FCC standards, and very little of it has to do with "reviewing those devices to make them more secure"--almost all of it is that software guys want to be able to hack every device because they think it's fun.
Thank god the world is run by adults and not by random software hackers.
Most of the computers (hell, most of the electronic devices) you've used in your life have some code running at some layer which [if written incorrectly] can do some physical damage. There is code that sequences power initialization, controls the voltage levels, controls clock rates, enables/disables over-temperature sensors, controls fan speeds, yadda yadda yadda.
You are unaware that this code exists probably because you've lived your entire computer life inside a safe little virtual world created for you by people who are a lot smarter than you.
Let me use a star trek analogy: You're in the holodeck and arguing with me that there is nothing outside of the holodeck. I find your argument unconvincing because I make holodecks for a living.
I admit, that document alone means absolutely nothing to me. I have no idea what a U-NII device is, or if one is present in my hypothetical raspberry pi plus wifi dongle setup. Without feeling the interest level to netsearch for U-NII, I'm going to still go ahead and presume that my worst case vision of everyone throwing their existing routers in the trash and replacing them with raspberry pi's with wifi dongles running debian is feasible. There are reasons I won't go into why I'm not interested in researching further at this point in time. Though if you want to walk me through it, showing me how that document is relevant to the raspberry pi hypothetical described, I'll be happy to continue supporting my prior points. I just can't honestly believe the FCC would attempt to, or could get away with, impeding the raspberry pi option as I described.
U-NII is the 5Ghz band, used by 802.11a and 802.11.
Your rPi will probably need to use an old WiFi dongle because for new sales, anything that is capable of sending beacon frames is classified by the FCC as an AP and must comply. The FCC has issued special guidance clarifying that items previously treated as client devices are now APs if they can beacon.
You'd think that if the FCC tried something so ham-fisted it would be news, it would be all over the tech sites. IT IS. The instruction to manufacturers is only two pages. You can read it as quickly as you can ponder about what it might say and discuss your guess.
I just reviewed the wikipedia on beacon frames to avoid saying anything too stupid. Please give me a citation for the "Your rPi will probably need to use an old WiFi dongle because for new sales, anything that is capable of sending beacon frames is classified by the FCC as an AP and must comply.". I admit that does sound worthy of complaining about, since AFAICT beacon frames should in no way be considered a spectrum violation. Please also give a link to the two page doc. I went to the /. engadget link and got the same 4 page U-NII doc you linked to, and the 89 page FCC-15-92A1 which a sampling of is what had formed my prior understandings of. I almost feel inspired to respond to their question at the end of paragraph 62, citing specifically the raspberry pi option, asking how it fits if in any way to that area of regulation. I can sympathize that there could be some issue with literally selling a product that is a single raspberry pi connected to 1000 usb wifi dongles. But I'd hope that if I only used one or two, I wouldn't need to get an additional FCC certification because that is well within the scale of ordinary general purpose computing. I.e. presumably the type of use the usb dongles were originally certified. And again, I really would be amazed if beacon frames on their own would require FCC certification. But there I can imagine the FCC trying to sneak a bit beyond simple spectrum patrolling. I mean, who is a beacon frame going to hurt?
I'm on my (small) phone right now, so I'm not going to look up links right now.
I don't think the FCC sees beacon frames as a big deal in and of themselves. Rather, they've decided to put strict controls on APs. That requires defining what an AP is. Beaconing is a defining characteristic of APs and that's the one that happened to choose for their regulatory definition. As I mentioned, they are aware that pulls in some devices normally considered clients, such as cell phones and simple dumb dongles, but they have to have SOME definition, and they chose beacon frames as their definition.
You think they can make mandatory regulations about APs without defining what they mean by AP? Of course they have to define which types of devices fall under which rules.
I speak as though this is largely a done deal for two reasons. First, the basic change officially went into effect June 2015 - the official time for comment is actually over and the rules are technically in effect. Secondly, the commission has indicated they aren't too open to different approaches- they pretty much plan to implement the rest of the proposal as-is. Hopefully that will change.
Exactly, IBM used the terms interchangeably.
They where wrong.
Hence it is not firmware.
Everyone else uses firmware as a term which is quite simple to understand: special code that the 'firm' which developed the device, put into the boot memory for that device to boot from (boot: cold start)
Uh ... in fact old IBM machines indeed could load micro code from the upper 16kB of the rom!!
So in terms of wording of IBM they did change the firmware and the microcode with a single patch, uh oh: nevertheless the rest of the world distinguishs between firmware and microcode.
Good luck in upgrading the microcode o your cPU in your PC with a firmware upgrade.
If your PCs CPU even has microcode (which I doubt).
Go back to design your hardware ... lucky for the world that you are not responsible in writing stuff that matter
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
makes then you'd be able to tell me what I said that was false. But you can't.
I never said that 100mW of RF could cause any human damage--I don't know if it could or not. I said that there are pieces of code running on computers and electronic devices that, if written incorrectly, can cause physical damage--which is why we shouldn't let /. morons anywhere near that code. My whole point is that just because something is technically "software" doesn't mean it's safe to let any jackass modify it.
that you don't realize that you just proved my point? You were able to modify setting that control thermal management. You probably knew what you were doing, or at least you understood that if the device caught on fire then you accepted the liability. But now you expect every hardware manufacturer to take on the liability for every internet idiot blindly modifying deep internal settings on devices they don't understand.
The 'firm' in firmware doesn't mean it was developed by the 'firm', it refers to the ability to change that code--as in, 'firmware' is harder to change than 'software' but easier to change than 'hardware'--get it?
Every Intel cpu uses microcode which is patchable after production. But you didn't understand where the 'firm' in 'firmware' comes from so I guess I shouldn't be too surprised that you are lacking basic computer knowledge like microcode.
The problem is that fucking morons like you are now trying to write laws that say that hardware manufacturers have to open up all software layers down to the hardware. Whether you consider microcode to be 'firmware' or not doesn't matter--it is clearly a software layer between the application and the hardware so it would get swept up in these stupid rules.
Well, again I wasted my time discussing with an idiot.
The difference between you and me is simple: I know what firmware is and you believe to know what firmware is.
Every Intel cpu uses microcode which is patchable after production.
In theory. In practice there is basically no computer board out there where a CPU soldered or plugged into it, can be altered after it is shipped.
The problem is that fucking morons like you are now trying to write laws that say that hardware manufacturers have to open up all software layers down to the hardware.
You are mistaken. I'm against such laws. You are an idiot.
Whether you consider microcode to be 'firmware' or not doesn't matter--it is clearly a software layer between the application and the hardware so it would get swept up in these stupid rules.
Double wrong.
No one would ship microcode in a firmware update for a router. Tripple wrong even: no router is able to upgrade the microcode of one of its processors, that would be much to expensive.
The main wrong is: 'microcode' is a software layer between the application and the hardware no it is not. Microcode determines how the CPU is interpreting/executing machine code instructions. From the point of view of the router running e.g. Linux it is no software at all. And it is certainly not in between the CPU and the software, it is below the CPU.
So much bullshit from a guys who claimed in several posts he is a hardware engineer and actually did _write_ microcode.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
in 'firmware' means. By your own admission you literally don't know what the word 'firmware' means.
> In practice there is basically no computer board out there where a CPU soldered or plugged into it, can be altered after it is shipped.
Microcode for both AMD & Intel cpus are frequently updated (patched) via BIOS/EFI or the OS update mechanism. On modern cpus, in modern operating systems (Windows/Linux/OSX). It's been like this forever.
> No one would ship microcode in a firmware update for a router. Tripple wrong even: no router is able to upgrade the microcode of one of its processors, that would be much to expensive.
You are talking about cheap wifi routers and I'm talking about all manner of computers and telecommunications equipment that would be covered by this law. It covers the client side, too--so that means laptops and desktops, anything that talks (or can talk) on FCC controlled frequencies.
> And it is certainly not in between the CPU and the software, it is below the CPU.
Wow.
Pay more for hackable hardware, or build the hardware yourself. But don't expect everyone else to subsidize your desire to fiddle with hardware.