[HN Gopher] Firmware is on shaky ground - let's see what it's ma...
___________________________________________________________________
Firmware is on shaky ground - let's see what it's made of
Author : Sindisil
Score : 111 points
Date : 2023-04-17 12:49 UTC (10 hours ago)
(HTM) web link (www.theregister.com)
(TXT) w3m dump (www.theregister.com)
| mschuster91 wrote:
| Good article, but some points I disagree with.
|
| > but if you go anywhere except to the manufacturer when you
| update a motherboard, you deserve to be busted down to abacus
| operator.
|
| Well, good luck finding drivers and firmware. Realtek used to be
| real bad, Compal used to pull their archives for "discontinued
| models" the day the devices were EOL. Microsoft thankfully forced
| OEMs selling Windows PCs/laptops to provide Windows Update
| integration for drivers because the situation got out of hand,
| but for accessories it's still the Wild West and it's very
| difficult to find archives for stuff that's been discontinued or
| where the vendor went through half a dozen worth of mergers.
|
| Not to mention SEO scammers hijacking "<manufacturer> drivers"
| search terms to a degree that they get the first Google listing
| and then use dark patterns to get people to download malware. We
| can't expect users to be able to detect SEO spam, not in times
| where criminals clone entire newspaper or bank sites to pull off
| extremely convincing scams.
|
| > Companies like using firmware to lock down their devices to
| business models - even when, as Sonos discovered, those models
| can provoke customer rebellion.
|
| For some things, particularly anything involving RF
| communications, there are legal requirements to not let people
| access chips in a way that allows them to manipulate the signal,
| e.g. by using them as SDRs, using frequency bands not allowed, or
| using too much power for the amplifiers.
|
| In other cases, they're forced to do so because they wouldn't get
| content... Netflix and other streaming apps are really bad here,
| it's a constant hassle to get it running on rooted Android
| devices.
|
| And apps like in banking enforce un-modified firmware to limit
| legal exposure when people get hacked. It doesn't make sense
| because the risk model is just the same as online banking on a
| PC, but here we are... (conveniently ignoring the bullshit South
| Korean banks pull based on long-outdated laws).
| squarefoot wrote:
| I understand most of the concerns by hardware manufacturers for
| not publishing their firmware source code, however if they did
| that after the product is declared obsolete, or at least if they
| would unlock bootloaders and publish enough documentation so that
| new firmware could be developed, that would give the community a
| way to recycle old hardware without them surrendering most of
| their precious IP.
| 95014_refugee wrote:
| The suggestion that an individual or a community could actually
| build, let alone maintain, any of these OS distributions for
| older hardware is disingenuous.
|
| There is literally no chance whatsoever that, even with
| complete access to all of the sources, any individual or
| community organisation could build an iOS distribution; not
| even once, let alone on any sort of cadence that would make the
| effort worthwhile. The required build infrastructure is
| massive, and maintained by a dedicated priesthood whose
| existence and experience are an integral part of the machinery.
|
| Let's not even get into testing, or carrier qualification, or
| support, or ...
|
| This is _well known_ , and not a subject for meaningful debate.
| Any writer claiming that "just releasing the source" would
| result in any of the claimed benefits is lying in service of
| some other objective (or delusional, but probably just lying).
| yjftsjthsd-h wrote:
| > The suggestion that an individual or a community could
| actually build, let alone maintain, any of these OS
| distributions for older hardware is disingenuous.
|
| Well that's just objectively false, unless I'm
| misunderstanding you. I'm writing this message on a phone
| running an open source Android build, which I reasonably and
| with precedent expect to keep getting updates long after the
| manufacturer has abandoned it. The thing you say is
| impossible is done every day.
| Vrondi wrote:
| You are displaying your ignorance. I ran an AOSP build
| customized by volunteer enthusiasts on a smartphone that
| originally shipped with Windows Mobile on it. With zero
| issues. For _years_. The HTC Vogue lasted me from Windows
| Mobile through Android Cupcake, Doughnut, and Eclair, working
| perfectly all the while. It's completely possible if the
| manufacturers aren't sheer jerks. That enthusiast work
| combined with Open Source code kept me from creating at least
| 3-4 smartphones worth of ewaste by extending the life of my
| device, and it functioned better for most of that time that
| it originally had out of the box.
|
| There is also decent enthusiast/volunteer support for things
| like routers and other gadgets out there.
|
| The only reasons this isn't common are paranoia and desire
| for profit over all other customer and environmental welfare
| concerns.
| Krutonium wrote:
| I can't help but to disagree. Just look at Linux
| Distributions for an example proving you wrong, let alone
| things like TWRP; a recovery partition that with relatively
| little work builds and works on most any phone that will take
| it; or any of the big Android Distributions that deal with
| _hundreds_ of phone models. A custom build of iOS would be
| nothing by comparison.
| klyrs wrote:
| I agree with the principle, but I think your notion of
| "obsolete" doesn't really match the incremental nature of
| hardware/software development. When does an iphone go
| "obsolete"? Apple re-uses pieces, giving them minor tweaks
| along the way, and stops making and even supporting the old
| ones after a while. But the code in a phone I would call
| obsolete will still live on in a current phone. Companies
| worried about their precious IP will still have a valid excuse
| to not release the source.
| iforgotpassword wrote:
| Yes, unlocking bootloaders the moment you stop shipping updates
| would be an absolute no-brainer to require imo. I've so many
| older Android phones floating around that would still make for
| great backup phones or dedicated usage for stuff you don't want
| on your main phone, but they're stuck with horribly out of date
| Android versions.
| zkirill wrote:
| I was researching open source hardware and was surprised to find
| very few offerings: SiFive (RISC V) and Raptor Computing Systems
| (POWER9). Are there any other ones?
| whitehexagon wrote:
| MNT Reform looks like an interesting open hardware solution.
| JoeAltmaier wrote:
| Microprocessors in embedded devices are getting pretty capable.
| I've been asked to port FreeRTOS and Linux in about equal
| measure.
|
| What gets me is, if the schematic designer would annotate the
| schematic with address, busses, chip pin uses, then I could write
| a script to port a new design to a particular OS automatically.
| My job would be obsolete.
| markus_zhang wrote:
| Just curious, porting Linux or other OS to different chip
| sounds like a daunting job. How do you approach the task? And I
| guess it's mostly about the kernel? Thanks!
| davemp wrote:
| Not OP and haven't ported linux in a while but:
|
| Obviously some details are going to depend on the device, but
| it's essentially:
|
| - set up a (cross) compiler
|
| - configure&compile the kernel
|
| - write the device tree (so the kernel knows what/where
| everything is)
|
| - compile the boot loader (with the device tree)
|
| - cross compile the minimum userspace for the system to
| function
|
| - bundle everything so you can install/flash it.
|
| Yocto [0] is what most people use to manage all those steps
| atm.
|
| > And I guess it's mostly about the kernel?
|
| Afaik it's mostly writing the device tree (though it's often
| provided in a board support package) and setting up the
| toolchain.
|
| [0]: https://www.yoctoproject.org/
| markus_zhang wrote:
| Thanks! These are all strangers to me I think, except the
| cross compiling part. But it's good to know some pointers
| and go from there.
| markus_zhang wrote:
| Stupid question: which jobs port Linux or other OS or other
| sys software for a majority of their time?
| davemp wrote:
| Embedded systems or firmware dev
| matthewfcarlson wrote:
| Not to subtract from GP's experience, but here's a good
| journey of someone porting linux to an older device (Chumby)
| https://hackaday.com/2022/12/21/chumby-gets-new-kernel-soon/
| markus_zhang wrote:
| Thanks, this looks like an interesting project. I'll
| probably start small and get something into my Pico
| (without any modification as I know some people already did
| this) and dev from there.
| [deleted]
| JoeAltmaier wrote:
| A different chip is a big job.
|
| A different development board with a familiar architecture
| (e.g. ARM Cortex etc) is a matter of loading drivers for all
| the parts connected on the board. For that you create a
| 'device tree' which is a blob of text similar to javascript
| or json data definition, with many particular conventions for
| pins, addresses and busses. See any document on Device Tree
| formats e.g. from Freescale.
|
| It gets compiled into a .dtb blob which is 'device tree
| binary' which is flashed into the board next to the os. The
| bootloader or uboot image expects it in a certain place,
| loads it into memory and provides it to the booting kernel.
|
| Of course you need to know about the device tree, to use most
| devices. That's why you have to have an extra step to load -
| the bootloader is a flash image that has hardcoded a tiny
| subset of device information just for initial load.
|
| That's all I can say without launching into chapters of
| details!
| Krutonium wrote:
| Device Trees seem like such a step backwards compared to
| how it is on x86_64 boxes, where searching and discovering
| all your hardware has long since been standardized.
| rcxdude wrote:
| The main thing is there's relatively little incentive to
| standardise: the kind of hardware you write device trees
| for almost always isn't the kind of hardware you sell to
| customers to just load whatever OS they fancy on it, it's
| generally a special-purpose device which is intended to
| run one software stack. The fact that there's even a
| standard like devicetree is basically just the linux
| maintainers trying to avoid hardware companies writing a
| million custom initialisation routines. (AFAIK there is
| also some standardisation around providing a devicetree
| to the OS from the bootloader for ARM servers, where
| there is such an expectation from customers, though ACPI
| is also often used)
| mfuzzey wrote:
| PCs are far more _functionally_ standardised than
| embedded systems. And in fact modern PCs do use something
| similar to, but in fact far more complicated than, DTs -
| ACPI tables which not only contain static data but also
| callbacks to let system firmware do some of the work.
| Even on a PC there are still many things that are not on
| discoverable buses but I2C or SPI.
|
| The only reason it seems simpler on PCs is because the
| ACPI tables are supplied by the hardware vendor so
| they're mostly invisible to the end user. But that only
| works because they're mass produced and the variability
| between different manufacturers is fairly limited.
| Microsoft and Intel specified what the system firmware
| must do and enforced it through certifcations. Most PC
| firmware is also only tested for the case of booting
| Windows and Linux often emulates bugs...
|
| The same wouldn't work for embedded systems which need
| far more flexibility.
|
| Yes some ARM systems these days use UEFI and ACPI but
| that is for _server_ hardware which is basically a PC
| where the x86_64 processor has been replaced by ARM and
| it is desired to have it otherwise work the same.
| kevin_thibedeau wrote:
| PCs have a device tree too. It's just called ACPI.
| Everything post PnP relies on static descriptors to
| discover hardware.
| yjftsjthsd-h wrote:
| Yeah, but those descriptors are baked into the hardware
| so you don't have to hard code it into the operating
| system
| AlotOfReading wrote:
| Those tables are often wrong. That can cause all sorts of
| issues and a big reason why Linux tends to have sleep
| issues and why windows modern standby exists. When that
| happens you're either maintaining workarounds on the
| kernel side or patching the acpi table yourself
| (terrifying, see this example [1]). The hope is that the
| end user will eventually apply firmware updates that
| might not exist for months or years. With device trees,
| the kernel applies a patch and it rolls out with the next
| update.
|
| [1] https://www.reddit.com/r/XMG_gg/comments/ia9x6c/fusio
| n15_lin...
| JoeAltmaier wrote:
| Yeah, I guess it's to be distributed? There's no central
| driver repo to refer to.
| markus_zhang wrote:
| Thanks. Interesting process. I guess for new chips
| especially of other architectures it might require a lot of
| rewriting of the underlying code.
| [deleted]
| zwieback wrote:
| I've worked on firmware for mass-market consumer products and one
| point the article doesn't raise is that firmware often supports
| company intellectual property such as specialized hardware, ASICs
| and other custom circuitry. I'm all for separating out the upper
| levels and allowing users or enthusiasts to add their code.
| However, the explosion of cool gadgets in our pockets didn't
| happen because of tinkerers, it happened because massive piles of
| money could be made. Let's not disincentivize hardware
| development that requires billions of dollars in up-front
| investments.
| jimmyswimmy wrote:
| As an EE I love the idea of open firmware. I wish more companies
| would provide it - akin to the old TVs and other equipment that
| came with [full!] schematics inside. It would let me truly
| understand and modify the items that I purchased.
|
| There is definitely a cost to it to the companies, which I fully
| expect to be passed down to me, but not in the form of a license
| agreement - in the form of an increase in base price.
|
| The problem for companies is multifold. A big one is that the
| firmware is the piece that not only interacts with but also
| protects the hardware. If you are easily able to change the
| firmware, you are easily able to destroy the hardware, and if
| that's under warranty, companies are going to be concerned.
| They're also going to worry about IP; certainly I build products
| that lean on the work from previous projects. I would kind of
| hate handing that over to potential competitors. But some of that
| 'hate' depends on the fact that my competitors don't give their
| firmware code out either. Maybe I would love it if I could see
| how they implement things. Maybe it would push us all to deliver
| better things. Another impact - open firmware would definitely
| change sales models for equipment.
|
| I imagine that if I had to start delivering open firmware for
| designs, I'd need to push some of the software control over
| product limitations into hardware. That might cost more, but is
| better anyway. Usually. And I'd try hard to figure out a way to
| install a 'unverified firmware' hardware flag, maybe an efuse
| blown in a hard-to-replace component, so that we could know who
| broke things.
|
| But I do like the idea. I want the firmware for my ${everything}.
| mrwnmonm wrote:
| What is EE?
| soylentcola wrote:
| Electrical Engineer, most likely.
| mrwnmonm wrote:
| Got it, thanks.
| JohnFen wrote:
| > If you are easily able to change the firmware, you are easily
| able to destroy the hardware, and if that's under warranty,
| companies are going to be concerned.
|
| I don't think this reasoning makes any sense. The company can
| just declare that replacing or altering the firmware voids the
| warranty.
|
| > I would kind of hate handing that over to potential
| competitors.
|
| But you do that the instant that your product ships. I've
| shipped a lot of firmware in products, and it's very common to
| find my firmware reverse engineered and available within a
| month or so of the product being released.
| crazygringo wrote:
| > _I don 't think this reasoning makes any sense. The company
| can just declare that replacing or altering the firmware
| voids the warranty._
|
| It's still a cost, though. People are still going to file
| tickets for warranty replacements, it won't be until the
| company receives the broken item that they'll detect the
| firmware replacement (if they even can, what if the hardware
| damage broke the ability to check?), people return items to
| the store they bought them from where they can't even
| check...
|
| It's honestly a whole mess that will absolutely wind up
| costing the company money in support and returns. You can
| argue that it's still worth the cost, but just declaring that
| altering the firmware voids the warranty doesn't stop people
| from trying, which costs money.
| JohnFen wrote:
| Yes, it is a cost. I would argue that it's a reasonable
| cost of doing business, personally, but it is a cost.
| shadowpho wrote:
| >The company can just declare that replacing or altering the
| firmware voids the warranty
|
| How can they know/figure it out? (They can't/or it's
| prohibitively expensive/difficult).
|
| >it's very common to find my firmware reverse engineered and
| available within a month or so of the product being released.
|
| Sure, but it's hidden from 99.99% of your user base
| terribleperson wrote:
| Prusa (makers of the Prusa 3d printers) set it up so that
| you had to physically break part of your printer before you
| could flash custom firmware.
| yjftsjthsd-h wrote:
| You could also just blow a fuse; we do actually have ways
| to do write-once memory for this kind of thing
| nomel wrote:
| Could you describe a rough implementation, with the
| assumption that the vendor can still provide firmware
| updates?
| folmar wrote:
| You have it in any unlockable Android phone.
|
| In short - write the manufacturer public key in ROM and a
| fuse selects if signature check is enforce.
| yjftsjthsd-h wrote:
| Sure. The vendor firmware contains an option in the
| settings, "unlock flashing". Enabling this (after a
| confirmation) will blow the "user modified fuse". When
| the system boots, the bootloader checks that fuse; if
| it's blown, then the bootloader will boot any firmware.
| If not, only boot images signed with the vendor's public
| key are allowed to boot. When the vendor gets a warranty
| claim, they check if that fuse is blown; if the fuse is
| blown and the damage could be software induced, they take
| that into account (IANAL, but they might not be able to
| immediately legally refuse it, but they can at least ask
| pointed questions about what exactly happened; YMMV).
|
| Disclaimer: I didn't come up with this, I'm just
| summarizing approximately how I understand some Android
| devices to already work. This also makes me view this
| system as somewhat battle tested.
| JohnFen wrote:
| > How can they know/figure it out?
|
| That's not a difficult problem, technically. There are a
| number of ways it can be done. Anything from comparing
| checksums to eFuses.
|
| > Sure, but it's hidden from 99.99% of your user base
|
| Yes. My point is that avoiding open sourcing firmware
| because of the risk of piracy or reverse-engineering
| doesn't make sense because pirates and/or interested
| engineers will do it directly from the devices anyway.
| matheusmoreira wrote:
| > If you are easily able to change the firmware, you are easily
| able to destroy the hardware
|
| How could custom software destroy a phone, a computer, a TV, a
| printer?
|
| > if that's under warranty
|
| Just void it.
| p_j_w wrote:
| Just one example: the firmware for some piece of hardware
| could control the DC biasing of the device. Set the bias
| incorrectly and now you're drawing more current than is safe
| for the hardware and drastically reduce the lifetime.
| znkynz wrote:
| I'm not sure vendors can void warranties in all countries. If
| you make a product that advertises itself supporting custom
| firmwares, then your hardware should be capabale of doing so
| would likely be how it is viewed in my country.
| wtallis wrote:
| > How could custom software destroy a phone, a computer, a
| TV, a printer?
|
| The problem with your question is that you replaced the word
| "firmware" with the word "software" when the distinction
| between the two is the answer to the question.
| matheusmoreira wrote:
| I don't see the problem at all. Firmware _is_ software.
|
| I can see how defective software could damage industrial
| machinery but I'm having trouble imagining how some TV
| could possibly be damaged by software. Many consumer
| devices don't even have moving parts.
| rcxdude wrote:
| Here's one moving part: speakers. It's becoming more
| common in the chase for good audio performance from small
| speakers to have a driver which can easily burn out the
| speakers, when given the wrong audio signal on normal
| volume. The firmware needs to actively model the power
| dissipation and temperature in the speaker and limit the
| signal if it could damage the speaker.
| spc476 wrote:
| There was an early 8-bit home computer where you could
| reprogram the video controller chip to drive the
| TV/display out of its operating range (timings/video
| frequencies, etc.) where left too long (how long? I don't
| know---I'm a software engineer, not hardware or
| electrical) could damage the TV/display.
|
| Go back further, and you get to harddrive races, back
| when harddrives were washing machine sized devices, and
| if you get the heads going back and forth fast enough,
| they start shaking and could "walk" across the room. That
| doesn't sound like it's good for the harddrives.
| wtallis wrote:
| You're really not trying hard to think of any possible
| answers, are you?
|
| In most devices over a certain level of complexity,
| there's firmware involved in thermal management. Messing
| that up can easily lead to premature failure of the
| hardware, and in some cases very quick failure.
|
| Even for a TV which may not have much of a thermal
| concern for its processor (though I wouldn't bet on it
| with today's smart TVs), you can still expect there to be
| some screen burn-in mitigation.
| matheusmoreira wrote:
| > You're really not trying hard to think of any possible
| answers, are you?
|
| I asked a question because I don't know. I assumed you
| did. I'm trying to learn something.
| wtallis wrote:
| You're being passive-aggressively unimaginative and
| unwilling to seek out information for yourself, in a
| manner that is a common form of trolling. Even if
| trolling is not your intent, you should know that the
| idea of learning by asserting something wrong online and
| waiting to be corrected may make for a good joke but is
| not a polite and productive way to have online
| conversations.
| cesarb wrote:
| > Firmware is software. [...] but I'm having trouble
| imagining how some TV could possibly be damaged by
| software.
|
| It's not very hard to imagine. For instance, most
| embedded chips have several "general purpose" I/O (GPIO)
| pins, which can be configured as an input or as an
| output; their usage depends on how the chip was wired
| into the circuit, and very often, they're shared with
| "alternate functions" like a serial bus. Configure them
| incorrectly (as an output when they should be an input,
| for instance), and you can easily create a short circuit,
| burning that pin or even the whole chip.
| ska wrote:
| This is naive. There are tons of firmware changes that
| will render hardware unusable until the board is re-
| flashed (which you may not be able to do at that point),
| and even without moving parts the capability to damage
| components. Simple example, often firmware is the only
| thing that will stop your hardware from cooking itself if
| it is capable of doing so. Or if you mess with battery
| management you could conceivably get a fire. Or you mess
| with power distribution and send the wrong voltages,
| parts are fried. Or, etc. etc.
| xxpor wrote:
| Just tell the voltage regulator to output 12v instead of
| 3.3.
| petsfed wrote:
| It is very tempting (and very easy) to think about
| firmware as simply software that you can update willy-
| nilly and at will, and things will always go back when
| things go bad. But there is a reason that most embedded
| firmware engineers are on their org's hardware team, and
| not software team. If I push a change that requires a
| JTAG to reverse, then from the customer's point of view,
| it is damaged.
|
| The bootloader that allows you to revert back to prior
| firmware, is itself firmware. If that gets broken by a
| firmware update, then your device is effectively damaged.
| thomastjeffery wrote:
| What cost?
|
| Competition? That isn't definite.
|
| Support overhead? I don't buy it.
|
| > If you are easily able to change the firmware, you are easily
| able to destroy the hardware, and if that's under warranty,
| companies are going to be concerned.
|
| ...so void the warrantee when flashing 3rd-party firmware.
|
| How often, _in reality_ , are people going to fry their
| hardware? It's not as if 99.99999% of 3rd-party firmware users
| are _writing that firmware themselves_! Hardware damage should
| be expected as an extreme edge case, not a broad looming risk.
|
| ---
|
| If we are going to put this much effort into speculating cost,
| we should put equal effort into speculating _value_.
|
| Open firmware is significantly likely to reduce the costs of
| compatibility and edge-case support. It is also likely to
| increase the value of the product by making it auditable and
| maintainable. It also factors out the cost of anti-user-
| maintenance efforts like DRM.
|
| Most importantly, open firmware can _stabilize_ the value of a
| product, increasing its resale price and delaying price
| decline. Unfortunately, this is the point that many companies
| consider _negative_ , because they don't want to compete with
| themselves.
| mardifoufs wrote:
| What do you mean that isn't definite? I'm very in favor of
| open firmware, but there have been multiple examples of
| clones popping up whenever firmware is public and open
| source.
| LeifCarrotson wrote:
| > A big one is that the firmware is the piece that not only
| interacts with but also protects the hardware. If you are
| easily able to change the firmware, you are easily able to
| destroy the hardware, and if that's under warranty, companies
| are going to be concerned.
|
| Is that justifiable, though? I bricked a router some time ago
| messing around with ddwrt. I thought about soldering on a TTL
| serial adapter, to recover it, but didn't end up getting around
| to it, but never in my wildest dreams did I think of asking
| Netgear to replace the 8-year-old product I broke through my
| actions. I do know at least one person who is reckless with "no
| questions asked" warranties, and would ask for a refund with a
| straight face after trying to use a router to reduce spaghetti
| sauce spattering when he microwaved his dinner, but these
| people can't be that common...
|
| One area where it does seem slightly more justifiable is FCC-
| certified radio devices. If the transmitter power level is
| restricted by law, I'd prefer that end users/modifiers of the
| firmware be considered legally responsible for the consequences
| of their own actions, but I understand that pragmatically it's
| a lot easier to ask OEMs to lock down firmware after getting
| certified in a test lab than to monitor a million end users.
| petsfed wrote:
| >I do know at least one person who is reckless with "no
| questions asked" warranties, and would ask for a refund with
| a straight face after trying to use a router to reduce
| spaghetti sauce spattering when he microwaved his dinner, but
| these people can't be that common...
|
| There's common, and then there's common-enough-to-be-costly.
| REI had a notorious lifetime-return policy that they ended
| relatively recently because of abuse. How common was the
| abuse? No idea. I don't know many people who would Return
| Every Item (as the joke went), but it was common enough that
| there was always some really beat-up climbing shoes at their
| member garage sales.
|
| And anyway, there's (at least) 2 kinds of costly: cost of
| returns, and cost to reputation when unqualified people brick
| their device, then tell all their friends that their
| router/refrigerator/laptop stopped working.
| VLM wrote:
| I was messing around with an I2C controlled lithium battery
| charger on a raspi last night (long irrelevant story) and
| found out it does NOT support "fast charge" (probably not
| enough thermal monitoring?) but it does support larger
| capacity batteries that coincidentally permit higher
| currents. So the short version is I can charge a battery
| twice as fast by lying to the charge controller that it's
| twice as large. On average, probably 99% of people can get
| away with that, the problem is 1% set the battery on fire or
| otherwise burn out the battery.
|
| No matter how smart you make the controller you can't
| outsmart the user; to the battery charge controller, a 1 aH
| battery being treated as a 2 aH battery behaves like a 2 aH
| battery that's at 50% capacity due to age or whatever issues.
|
| I would imagine, as long as I can keep it cool, I could
| install a 50 mAH micro battery and tell the charge controller
| its a 2 aH battery and it would charge very fast indeed.
| Perhaps only once, but it would be very fast. I suppose the
| worst case scenario is some kind of virus/cyberattack
| reprograms the FW to believe the battery is either 65536 mAH
| or 1 mAH, either way the battery would appear "dead" to end
| users.
|
| Another common problem is marketing and mgmt may be a LITTLE
| over optimistic about a feature; imagine if your IoT cigar
| humidor (made up idea; probably does exist LOL) has a
| hardware barometric sensor on the I2C. I2C is famous for
| dodgy hardware being able to 'jam' the bus. Ah no problem
| nobody needs a baro on a humidor anyway, we'll just delete it
| from the marketing materials and remove it from the firmware,
| no need to e-cycle otherwise good first batch of boards. Well
| if someone uploads custom firmware and the baro is polled
| every hour and it randomly jams the I2C once every hundred
| polls, "must be a thermal issue the CPU crashes" nobody might
| ever understand the problem. I mean, its gotta be a hardware
| bug worthy of a return, everyone knows if the code compiles
| and passes unit tests and works for a couple minutes, it must
| be good, right? But if the I2C protocol is interrupted due to
| a wifi interrupt in the middle of whatever it crashes the
| whole bus so randomly every couple weeks it locks up.
|
| Some big expenses are not brick fails but "it burst into
| flames while on an aircraft" or "everyone knows the hardware
| locks up randomly every couple weeks" causing all kinds of
| crazy bad PR.
|
| Then there's interference with marketing models. Well,
| technically the hardware for rev1 and rev2 are the same, its
| just rev2 has more features because we eradicated bugs, so
| please pay us again, don't just download new FW.
| RobotToaster wrote:
| I imagine there's upstream issues too, with NDA's for hardware
| interfaces, and obviously proprietary OS like VxWorks, MS
| ThreadX, etc.
| pixl97 wrote:
| I was about to say that a lot of this is completely ignoring
| the few network vendors/chip vendors that have completely
| locked down hardware/chips that you're buying from them and
| effectively acting like a value added reseller for companies
| like broadcom.
| hinkley wrote:
| This is going to be the openWRT argument all over again. Linksys
| mid-tier and low-end hardware were somewhat differentiated by
| what the plastic looked like and which firmware version you had
| on the box. Most boxes got a lot of new functionality once you
| installed the open firmware. And once Cisco bought Linksys that
| whole problem just got worse.
|
| So they won't want to do it.
|
| Anyone doing Consumer Protection or Right to Repair should - at a
| minimum - request that all of the firmware for devices be
| transferred into escrow, to be released upon end of life for the
| product. Ideally that would be released when the product ships,
| but I don't think you'll be able to get that out of the gate.
|
| What I'd really like is for all appliances to utilize a standard
| microcontroller design and pinout, similar to arduino or
| raspberry pi, and day-of-release firmware availability.
| juancn wrote:
| First of all, firmware bugs can physically damage some hardware,
| some might even be dangerous to use (e.g. overheat and catch on
| fire).
|
| It just increases support costs and liability for the
| manufacturer for little or no gain.
|
| On the security front, having the source code leaked makes it
| much easier to develop APTs and deep implants.
|
| So it's easy to see why it's not something most manufacturers
| embrace willingly.
|
| The nerd in me really would love to have access to more open.
| firmware, but I get where the apprehension comes from.
| iforgotpassword wrote:
| > First of all, firmware bugs can physically damage some
| hardware, some might even be dangerous to use (e.g. overheat
| and catch on fire).
|
| Doing random crap to my car's engine when I have no clue what
| I'm doing poses all of the same risks if not more, I can still
| do that. It doesn't mean it's covered by the manufacturer's
| warranty.
|
| > It just increases support costs and liability for the
| manufacturer for little or no gain.
|
| You got a device sent in from a customer that bootloops because
| they flashed some garbage? They can get it back for a service
| fee of 20$ or you'll dispose of it for them.
|
| The case deforms where the camera is mounted and dust and water
| can get in (hello Pixel 4)? Replace it since this has nothing
| to do with firmware but is a plain old manufacturing defect.
|
| > On the security front, having the source code leaked makes it
| much easier to develop APTs and deep implants.
|
| See article. Normal users get firmware through official
| channels anyways, and targeted (supply chain) attacks are run
| by people who either already have access to the source code or
| got the resources to do the reverse engineering, so it doesn't
| really matter whether it gets easier.
| ChrisMarshallNY wrote:
| There's actually an industry, based on modding car software.
| I have a friend that does exactly that, as a hobby.
|
| They mess with the firmware (usually by changing coefficients
| and thresholds), to make the car more performant (and
| probably fall foul of various environmental and safety laws).
|
| And, then, there's VW's clever tweaking of their (completely
| legal) firmware...
| bri3d wrote:
| And, especially in European cars, car software modification
| has been aggressively locked down, mostly for emissions
| compliance, anti-reversing, and warranty reasons. Just like
| any other device firmware.
|
| The "I can modify my own car, so why can't I modify my own
| device firmware" analogy for firmware really falls over
| here, honestly, because cars _are_ firmware these days and
| it 's locked down and protected the same way as any other
| firmware.
| AdamH12113 wrote:
| > But then, firmware is weirder than we give it credit for. It's
| even hard to say exactly what it is. That used to be easy -
| firmware was software built into hardware (don't mention
| microcode.)
|
| Maybe this is just my bias as a low-level MCU programmer, but I
| wonder if this isn't a definition problem more than anything
| else. To my mind, if your code has problems like this:
|
| > We notice the old devices piling up in a desk drawer, hardware
| perfectly fine but with ancient firmware that just won't play
| with modern services.
|
| Then it's not firmware, it's full-fledged software, and ought to
| be treated as such. Calling a smartphone OS "firmware" is
| particularly odd to me -- it runs on a general-purposes computer!
| It takes up gigabytes of storage space! It updates itself over an
| internet connection that it also manages! -- and I think it gives
| the wrong idea about the system it's installed on and the nature
| of the software itself. In particular, anything that needs
| regular updates is not "firm" in any sense.
|
| It is hard to draw a firm line somewhere between the code in a
| tiny microcontroller running a battery charger and the operating
| system running on a general-purpose application processor.
| Motherboard BIOSes are a bit of a marginal case. But I think
| there is a useful distinction between "acts like part of the
| hardware and never needs to be changed" vs. "is the core of the
| product and when it stops being updated the product quickly
| becomes useless". Very few people are clamoring to hack on the
| firmware for their PC's power supply or their car's air
| conditioner.
| rubatuga wrote:
| I think firmware has a distinction that it isn't updated as
| much as software, and will be a read only file system.
| thrashh wrote:
| I think we should drop the word firmware. Firmware is just
| software.
|
| And to be honest, the distinction has never been so much a
| technical one but more of a ownership one. Firmware is really
| software that you take for granted and "software" is the
| software on top that you can maybe configure yourself but that
| line is so blurry.
|
| Firmware vs software has more meaning when applying for jobs
| but it kind of comes down to an indication of culture more than
| technology.
| petsfed wrote:
| I disagree. The distinction is very valuable when it comes to
| how you design the system for maintenance.
|
| Firmware is not simply software that you take for granted,
| its software that is designed and tested prior to release
| such that updates and maintenance are very rare. Its possible
| that updating by the user is impossible. Example: I worked on
| a swarm of environmental sensors that reported via bluetooth.
| In principle, you could send out a new firmware package over
| the air, but rewriting their ROM required more current the
| the coin cell could provide. These devices were meant to be
| in hard-to-reach places, so updating the firmware on a fleet
| of them (a few thousand in an average warehouse) was a pretty
| onerous task, involving recovery, disassembly, and
| reprogramming using specialized equipment. When we pushed out
| generation 2 of these devices, we addressed the issue with
| over-sourcing current, but it was still understood that there
| was some non-zero possibility that an update could brick the
| device, necessitating the onerous process to recover. The
| takeaway: if it really hurts to update, its firmware.
|
| I do get irritated that I have to read quite a ways down a
| job description before they indicate something like "embedded
| Linux/Windows/AmigaOS/etc", because when I call myself a
| firmware developer, I think embedded C on a mirocontroller
| with at most a simple RTOS.
| AdamH12113 wrote:
| That is a good point that I didn't touch on in my comment.
| Although, oddly, a lot more software used to work that way
| before the internet. Console video games in particular went
| from "there might be different versions of the cartridge
| ROM or disc but you won't ever know" to "download the day
| one patch if you want the game to work and download the
| next two patches if you want it to work well" practically
| overnight once they got internet connectivity.
|
| Maybe the real distinction today should be between
| internet-connected systems and non-internet-connected
| systems.
| wtallis wrote:
| I think any firmware that's complicated enough that the
| manufacturer gets it _wrong_ should be open-source. Especially
| if the manufacturer is deliberately crippling the product with
| bad firmware rather than just accidentally through
| incompetence. And firmware that 's too simple to screw over the
| user is probably too simple to be eligible for copyright
| protection to begin with.
|
| A motherboard BIOS is not at all a marginal case. BIOS bugs
| abound, as can be seen by booting Linux on almost any PC and
| looking through the kernel logs for ACPI table errors and
| various other workarounds and quirks being activated.
| AdamH12113 wrote:
| By "marginal", I was thinking more of whether a BIOS is
| possible to ignore. The vast majority of PC owners never
| update their BIOS at all. If you buy a motherboard a couple
| years after its release, there may not be _any_ significant
| updates from the manufacturer. It 's not like the OS where
| you're downloading updates multiple times a month.
|
| This is separate from the question of whether the BIOS should
| be open source. I'm inclined to think that it should,
| especially after the motherboard has been out for a few
| years.
| ac29 wrote:
| > The vast majority of PC owners never update their BIOS at
| all.
|
| I wonder if this is true now that Windows will do it
| automatically. I have been more than once surprised to see
| a computer updating its firmware after a Windows reboot.
| petsfed wrote:
| I think you're talking past the parent's point here.
|
| Firmware as _I_ understand it (also as a microcontroller
| firmware programmer) is about the same as what the parent
| understands.
|
| I think your metric about "too simple to screw over the user"
| is sort of weird, when in the context of my work and the
| parent's work, "screw over the user" might well mean
| "disabled the oxygen pump on the user's space suit".
|
| It is in _that_ sense that motherboard Bios is a marginal
| case. It is marginal in the sense that BIOSes are clearly at
| the margin between embedded microcontroller firmware and
| full-blown general-purpose-computer operating system. If I
| have to update the BIOS on my computer every month (or every
| week) just for it to boot into any operating system, then
| something is incredibly wrong, even as modern BIOS have
| become several orders of magnitude more complex today.
| wtallis wrote:
| Firmware problems don't have to be severe enough to put
| human lives at risk to be a real problem. There are tons of
| examples of bad firmware leading to broken power or thermal
| management leading to crippled performance or battery life
| or excessive fan noise. WiFi NICs have subsumed large parts
| of the network driver stack and in doing so have made it
| impossible to implement effective QoS, leaving users stuck
| with stupid radio behaviors that hurt the performance of
| every device operating on the same channel.
|
| None of what I'm proposing would lead to a bios update
| every month, except in the initial period of fixing the
| worst of the manufacturer's mistakes. "Firmware" as I'm
| using it would still be trying to present a stable
| interface to the rest of the system and not inherently be a
| moving target of constant feature creep in addition to the
| bug fixes.
| passwordreset wrote:
| > In particular, anything that needs regular updates is not
| "firm" in any sense.
|
| It's really not about the updates that makes something "firm".
| Hardware is hard because it's a real physical thing. Software
| is soft because it's a non-physical thing, a set of
| instructions. Firmware is firm because it's less physical than
| hardware, and is more physical than a set of instructions.
| Firmware is software, in that it's a set of instructions, but
| additionally it needs to be loaded or flashed or programmed
| into the hardware, and stored either on-chip or in some ROM or
| NVRAM nearby, differentiating firmware storage from software
| storage on disk, tape, or some other peripheral storage. At the
| time, this made pretty clear sense, but over time, things were
| made murky by multifacted uses of NVRAM and peripheral storage.
|
| So, "software built into hardware" is a pretty good definition.
| When you say something isn't firmware, it's software, that
| seems mistaken. All firmware is software, not all software is
| firmware. The size doesn't matter. Whether it's an application
| or a device driver doesn't matter. What defines the "firm" part
| of firmware is whether it's "built into the hardware". That's
| it.
|
| So, yeah, you're having a definition problem. If you keep
| whatever definition that you currently have, then you're gonna
| have a bad time. If you try to "draw a firm line somewhere
| between the code in a tiny microcontroller running a battery
| charger and the operating system running on a general-purpose
| application processor", with this new definition, the question
| becomes "where is this code stored?". It doesn't matter how
| large it is, whether it's 100 lines of code in your battery
| charger or 1,000,000 LOC for your OS. If it's in on-board
| storage, it's firmware. If it's in peripheral storage, it's
| software.
| mfuzzey wrote:
| The difference between "software" and "firmware" is mostly
| relative to your view point. It's another level below the stuff
| you work on yourself.
|
| For example many modem modules these days have fairly powerful
| ARM SoCs running Linux and they also have another smaller
| processor running a RTOS or bare metal that does the radio
| stack. The whole module could be integrated into a larger
| device itself running Linux too (such as a payment terminal).
|
| The terminal owner will probably consider the entire terminal
| software as "firmware" (since it's in a device and pretty
| opaque to them and they likely can't update just some
| applications like on their PC).
|
| The developpers working on the code in the terminal will
| probably call what they do software and consider the stuff that
| goes in the modem module to be "firware" (and probably not
| differentiated between the Linux based and RTOS based parts of
| the modem).
|
| The developpers working on the Linux part of the modem will
| probably consider what they do to be software and the firmware
| to be the RTOS based stuff that runs on the baseband processor.
| mikestew wrote:
| I don't know if you're right or wrong, or if there even is such
| a dichotomy, but I struggle with the same thing with one of our
| products. It's basically Linux running on an ARM chip, with our
| stuff on top. We call if "firmware" for what are probably
| reasons of habit, because all of our other products actually
| _do_ use what I would call firmware. And when we hire for the
| team, we specify "embedded programmers". But I dunno, this
| board (single-core though it might be) would have suited me
| just fine as a desktop box twenty years ago. It runs a full OS,
| it runs a web server for the UI, services in the background;
| it's a reachable server in a teeny-tiny box if you ask me.
| Writing code for it is much like writing any other Linux app.
| Is it really "firmware"? Do we really need "embedded
| programmers"?
|
| I would argue "no" on both points.
| pabs3 wrote:
| There is precious little open firmware out there already, but
| even the stuff that is open has various problems; builds require
| proprietary tools, the hardware requires vendor signatures etc.
|
| https://wiki.debian.org/Firmware/Open
| what-no-tests wrote:
| An oldie, but a goodie:
|
| > Hardware met Software on the road to Changtse. Software said:
| ``You are Yin and I am Yang. If we travel together we will become
| famous and earn vast sums of money.'' And so they set forth
| together, thinking to conquer the world.
|
| > Presently they met Firmware, who was dressed in tattered rags
| and hobbled along propped on a thorny stick. Firmware said to
| them: ``The Tao lies beyond Yin and Yang. It is silent and still
| as a pool of water. It does not seek fame, therefore nobody knows
| its presence. It does not seek fortune, for it is complete within
| itself. It exists beyond space and time.''
|
| > Software and Hardware, ashamed, returned to their homes.
|
| ...from The Tao of Programming [0]
|
| [0] http://canonical.org/~kragen/tao-of-programming.html
___________________________________________________________________
(page generated 2023-04-17 23:00 UTC)