USB device bootloader: which method do you prefer?

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
I'm designing a small electronic gadget with a USB device port.

Now I'm thinking about a good method to upgrade the firmware through the  
USB. The process should be as simple as possible for the user.

I think there are three main method, each one with pros and cons.
In all of them, the user should only press a button while the device is  
connected to the host (so powered up). At startup, the switch is sensed  
and, if pressed, the bootloader enters or stop running the application.

CDC
The device is seen as a COM port from the host. IMHO this is the  
simplest method for the developer, but has many cons.
First of all, the user should be able to read the COM port number  
assigned by the host to the device.  However I don't know if it is  
really true. Is it possible to write a software that automatically  
detects if my USB CDC gadget is connected and automatically communicate  
to it without knowing the COM port number (or automatically detect it)?
Second, the user should install a driver when the device is attached (at  
lest in Windows, the driver is a .inf file only).
Third, a software must be installed on the host to communicate with the  
bootloader.

DFU
It seems USB defined a DFU standard for firmware upgrade through USB  
connection. If I understood well, even in this case the user should  
install a driver and should use a custom tool to manage the firmware  
upload process.

MSD
I think this is the simplest method for the user.
The host sees the device as a removable disk with a virtual filesystem  
in it (usually it is FAT12 that is the simplest to implement in the device).
The firmware upgrade process is only to drag the new file to the root  
folder.
The only issue I see here is how to report the result of firmware  
upgrade (success or error) to the user. He can only see a list of files.
I can think to create a virtual file, such as SUCCESS.TXT or ERROR.TXT  
or other similar names, when the firmware upgrade ends.  However the  
host OS could cache the content of the virtual disk, so hiding the new  
virtual files.

Maybe there are other methods. Which one do you prefer?

Re: USB device bootloader: which method do you prefer?
Am Mittwoch, 7. September 2016 09:57:45 UTC+2 schrieb pozz:
Quoted text here. Click to load it

Cypress uses HID for the PSoC devices, and we are using it, and it works ok.
No driver needed, some libs on Linux.  

Andreas

Re: USB device bootloader: which method do you prefer?
Il 07/09/2016 10:44, acd ha scritto:
Quoted text here. Click to load it

Interesting. Anyway the user should install/launch a custom host  
software to upload the new firmware, shouldn't it?

How the host software recognize the correct HID device? Should the user  
select the device by a string (name) or some other identification mechanism?

I think many HID devices could be connected to the host (mouse,  
keyboard, joystick, ...)



Re: USB device bootloader: which method do you prefer?
Il 07/09/2016 11:44, pozz ha scritto:
Quoted text here. Click to load it

Maybe the host software searches for the exact VID/PID.


Re: USB device bootloader: which method do you prefer?
Op 07-Sep-16 om 9:57 AM schreef pozz:
Quoted text here. Click to load it

Make your device a HID and you don't need any drivers at the host side.

Wouter "Objects? No Thanks!" van Ooijen


Re: USB device bootloader: which method do you prefer?
Den onsdag den 7. september 2016 kl. 17.20.03 UTC+2 skrev Wouter van Ooijen:
Quoted text here. Click to load it

you won't need drivers but you'll need some kind of program to send the firmware.  



Re: USB device bootloader: which method do you prefer?
Quoted text here. Click to load it

Do you have enough memory to cache the file before writing, or do you have
to write as you go?  I'd want to check the hash/signature of the firmware
before committing to write it, in case the user does something stupid like
accidentally dragging the wrong file or not properly dismounting the disc
resulting in a partial write.

Such mistakes are less of a problem if you have a special flash program that
can display the appropriate skull and crossbones.

Quoted text here. Click to load it

Do you not have any out of band channel?  LEDs you can flash in a special
pattern or something?  You're right that the OS is likely to cache.  If not
I suppose you could hotplug something else - another MSD with title of
Success/Fail perhaps.

Theo

Re: USB device bootloader: which method do you prefer?
This decision is more based on what resources the target has.
It's also about the use cases for updates you expect to support.

Not to be snide, but I prefer to make things that work and don't
have to be updated. It's cheaper that way. I know this
isn't always possible but I bet it's more possible than you think.

Weasel out of iffy requirements with configuration, mostly. Test the
crap outta the thing - it's always cheaper  than you think.
If an "update" is shooting a new set of config options at the target,
your life is less interrupted.

If you need to make that look like an upgrade, then do that.

pozz wrote:
Quoted text here. Click to load it

You can't reliably know which COM port will be assigned on the host
computer. There may be notification schemes in play ( usually a
popup happens on Windows at least ).

This being said, Arduinos use this and it works well.

http://stackoverflow.com/questions/4199083/detect-serial-port-insertion-removal

Quoted text here. Click to load it

SFAIK, this may preclude using the USB port as a serial port. It may
not.

Ardunios use essentially an FDTI driver for both. It's a good
approach, IMO. But Ardunios don't have a file system and use what
appears to be a monolithic download image.

Cubie boards ( and I believe Beaglebone Black ) use this as an OTB port.  
You can then reflash ( soft-debrick ) the unit that way. I forget what  
happens when that goes wrong, you may need a JTAG/ODB type thing.

Quoted text here. Click to load it

If you have the resources, sure. You still need a debrick strategy.

Quoted text here. Click to load it

Prefer? Something more like bootp. SLIP[1] the surly bonds
of serial ports.... then when you plug it in, it Just Updates.

[1] or PPP...

This may be a challenge for cases where users or techs have to update  
units in the field. But maybe you have an Official(tm) Li'l Upgrade Box
or something.

--  
Les Cargill

Re: USB device bootloader: which method do you prefer?
On 9/7/2016 12:07 PM, Les Cargill wrote:
Quoted text here. Click to load it

+42

Too often, APPROACHING a product with the "upgrade path" foremost
in mind suggests a lack of confidence in:
- knowing what the customer wants
- knowing what the product should *be*
- your implementation
- some combination of the above

IME, "upgrades" are stressful experiences to most users.

The process is *rarely* "well documented" (i.e., instead of
saying "wait for the light to start blinking", you should
be saying "wait 7 seconds (not 6 and not 8) for the light
to start blinking".  *All* the details need to be nailed
down so the user doesn't wonder "how long should I wait?",
"is it doing what it *should* be doing?"  etc.

[I recently bricked a print server because "wait for the
device to reboot" REALLY meant "wait for the better portion
of a *minute* for the device to reboot".  AND, the device
had no provision for resuming an aborted update:  start it
and you are committed to finishing it!]

It typically takes a fair bit of time to update *a* single device:
- discover that an update is available
- decide if the update is worth installing
- discover if the update is *applicable* (version currently running?)
- download the update (make sure the download protocol alerts the
   user if the download was prematurely aborted!  make sure BINARY/ASCII
   mode doesn't impact the payload; etc.)
- set up the update environment (special cables?  disconnect peripherals?)
- perform the update
- verify the result (you *did* include a means whereby the user can
   identify the NEW version of the software installed, right?)
All assuming nothing goes wrong in the above.

If (when!) something goes wrong, is there a way to recover?  To restart
the upgrade (have you documented EVERYTHING the user needs to do in
order to restart?  E.g., my print server case required me to reset
the deviec so it would repeat the BOOTP discovery sequence)

If (when!) something goes wrong, is there a way to return to the previous
configuration?

If you later decide the upgrade was a "mistake" (you are not happy
with it -- or, it is buggier than your previous version, you've lost
some capability, etc.), is there a way to DOWNgrade?

Are all of your configuration choices seemlessly propagated forward to the
new implementation?

Repeat this for (potentially) *all* of your customers.  How many will
pick up a phone and call "support" somewhere in this process?  Or, send
an email asking for clarification/assistance?  How many will render their
devices useless?  How many of those will complain to you about your
"crappy software"?  What will all of this cost *you*?

And, more importantly, what will it cost *them*?  How eager will you be to
move yet another upgrade out to them?  How eager will they be to go through
this effort AGAIN?  When will they start thinking, "Why didn't the device
ALREADY have these features/capabilities WHEN I BOUGHT IT?"

Quoted text here. Click to load it

If you're confident an upgrade will NOT be needed to fix a latent bug
in your code, then put your money where your mouth is:  challenge your
colleagues to see if they can find any bugs (in the product's use
*or* from an inspection of the sources).  I routinely bake goods for
friends/colleagues willing to spend some time hammering on something I've
decided is "done" -- a reasonably fair trade (a few hours of their time
vs. a few hours of me baking).  If someone finds something significant,
it would be a BARGAIN to treat them to a steak dinner -- "out".

If you find yourself "buying lots of dinners" -- or, "rationalizing
their (legitimate) comments away" -- then your process needs some serious
rethinking!

*Cherish* your customers' time -- because *they* do!  Treat them with
disdain and a competitor will lure them away in a heartbeat ("Our
product WORKS!")

Re: USB device bootloader: which method do you prefer?
Quoted text here. Click to load it

Unfortunately, if your device has connectivity this doctrine no
longer applies.  In the brave new IoT world security threats will evolve and
vulnerabilities will happen.  While there are sensible mitigation
strategies, you can't plan for the discovery of vulnerabilities in advance.

Therefore you had better get used to an upgrade path and make it bomb-proof
because you will be using it.  Or if you aren't you're almost certainly
should be.  Unless you have a really good threat model as to why your gadget
isn't worth targeting (including using it as a springboard to attack other
things).

Quoted text here. Click to load it

To be honest UIs on these things are often terrible.  If you really want to
communicate with the user, put a display on it and tell them, don't try to
use Morse code.  But that costs money.

Theo

Re: USB device bootloader: which method do you prefer?
On 9/7/2016 4:47 PM, Theo Markettos wrote:
Quoted text here. Click to load it

The first thing you can do is implement ONLY what is needed.  And,
UNDERSTAND that implementation!  I.e., if you're just "lifting"
code (e.g., a network stack) out of "something else" (FOSS),
then it's probably safe to say you've got more cruft than you
actually need!  More things that can contain latent bugs; more
levers that exploits can flip.

Ask yourself OBVIOUS questions:
- do you need support for all these protocols?
- will your device NEED to talk to a wider ecosystem?  Or, just
   other devices of YOUR design/manufacture?
- will you NEED to support N concurrent connections?
- is your deployed environment STATIC?
etc.

Chances are, you've got far more cruft in your device than
you actually *need*.

By eliminating cruft that you *don't* need, you eliminate
things that you (should, otherwise) understand!  And, things
that you WOULD, otherwise, have to test.

E.g., my home automation devices KNOW they will never be talking
to anything other than my OTHER home automation devices.  No
need to support name services, filesystems, exports, etc.  No
need for an ARP cache -- its contents should be const!  etc.  As
a result, I can apply really robust tests to network transactions
and KNOW that anything out-of-the-ordinary is either:
- a bug
- an attempted exploit
There are no other "benign" possibilities (that a more generic
network implementation would "tolerate"):
    "Um, why are you sending me these ICMP messages?  That's
    not part of the product specification.  Go away, bad thing!"

Quoted text here. Click to load it

Even where the UI already exists, "upgrades" are seldom painless.

I have to upgrade the BIOS on a bunch of little diskless workstations
I have, here.  I can plug in a keyboard, mouse, display, etc.
I can boot a full-fledged OS, etc.  Yet, it's taken me several
hours to figure out why the upgrades won't install!  Even googling
for an explanation of the error message turns up nothing.
(Hence my admonition to document EVERYTHING)

If I was *reliant* on this upgrade (e.g., to patch an exploit as you've
outlined above), I'd be increasingly "anxious" that the upgrade
wasn't "taking".


Re: USB device bootloader: which method do you prefer?
Theo Markettos wrote:
Quoted text here. Click to load it

Oh, I know. I suppose there's some fun in that but I'm doing everything
in my power to avoid the entire edifice. And I mean "avoid" in both the
consumer role and as a developer.

Alphabet's "retirement" of that Nest thermostat tells me everything I
need to know about that niche. It's not designed to create consumer  
surlpus at all, but to appeal to the ego of what passes for "tech  
companies" these days. Gotta keep the l33t hax0rs busy; idle hands
you know...

Second, when people did on the high seas what system crackers do
over the internets, it was called "piracy". At least the British
Empire had "ships of the line" to hunt them down and hang them
from yardarms.

Instead, we treat them as clever children and encourage them.

Heads on pikes outside the city gates, I say. Invoke Mossad-style
hit squads...

Quoted text here. Click to load it

Not so much; no. I can check for WiFi or Ethernet and simply *not buy*  
the damned thing. Or cut certain traces is you can't avoid it any more.

Quoted text here. Click to load it

I think you've made an excellent case for *not* needing it.

Quoted text here. Click to load it

Horrid. That's why the best UI is no UI at all.

I dunno if you've looked at TR-069 but Good Lord, what a  
cluster[expletive deleted]. Oh yeah, that's So Much Better than, say  
SNMP....

Quoted text here. Click to load it

:)

Quoted text here. Click to load it

--  
Les Cargill

Re: USB device bootloader: which method do you prefer?
On 9/9/2016 1:11 PM, Les Cargill wrote:
Quoted text here. Click to load it

Nest's stupidity was in designing the device with the intent of
it talking to a server that *they* controlled.  And, coming up
with a rationalization for why that would be "necessary".

Philips has some lighting products that have headed down the
same path.

Why can't *I* talk to *my* devices without THEIR needing
some intermediary?

Quoted text here. Click to load it

Ocean is a lot smaller than the Internet!  And, relatively easy
to identify "ports of call" that they MUST routinely visit to
resupply.  A pirate operating on the east coast can't "suddenly"
move to the west coast cuz the heat's turned up (but a hacker
can appear on the other side of the globe, in an instant!)

Quoted text here. Click to load it

We also do nothing to REALLY motivate designers to design more
robust products.  If my router gets hacked, can I recover damages
from the manufacturer?  If my bank account gets hacked?  If
my medical records?  Voter registration?  etc.?

Quoted text here. Click to load it

Unfortunately, you may not have that option if, for example,
those traces bring some "needed functionality" to the device.


Re: USB device bootloader: which method do you prefer?
Don Y wrote:
Quoted text here. Click to load it

And if Annhauser-Busch built a bar, what sort of beer you think they'd  
sell?

Quoted text here. Click to load it

Yup.


Derp de derp de derp derp derp!

Quoted text here. Click to load it

Nonsense. It's that same damn thing. Oceans got progressively smaller  
anyway.

DID NOBODY READ HORATIO HORNBLOWER BOOKS AS A KID?

Geez :")

Quoted text here. Click to load it

I don't care where they are. I'd just support their... elimination,
toothsweet.

Consumerism is hanging by a thread; if anything was in the public
interest, the rapid and efficient dispatch of network pirates would
seem to be .. one of those things.

Unless you think that advancing the interest in Security(tm) to
toasters somehow creates you a business model...

This is what's called a "bootleggers and baptists" situation.

Quoted text here. Click to load it

Of course not. And why would we? I just do it out of stubbornness.

Quoted text here. Click to load it

Then I shall do without it.

--  
Les Cargill



Re: USB device bootloader: which method do you prefer?
Am Donnerstag, 8. September 2016 01:47:05 UTC+2 schrieb Theo Markettos:

Quoted text here. Click to load it

Doesn't the capability to update the firmware open a plethora of security risks
that are even more difficult to fix than that of your application?

Andreas

Re: USB device bootloader: which method do you prefer?
Quoted text here. Click to load it

That's easy to fix.  Just use signed firmware, and check the signature before
updating.

It does require a bit of care with your signing keys but it's not rocket
science.  Though it doesn't necessarily prevent regression to older firmware
(which might contain vulnerabilities).

(putting aside for a moment the argument that I as purchaser should have the
right to determine the software running on hardware I own)

Theo

Re: USB device bootloader: which method do you prefer?
On 9/11/2016 10:47 AM, Theo Markettos wrote:
Quoted text here. Click to load it

A "version number" tag in the file could be examined to ensure this
isn't allowed.

Or, a key in the new image can effectively render all but the *next*
(sequential) upgrade "incompatible".

But, there's still no guarantee that you won't get pwned.  Note how
many "big players" seem to be unable to prevent their products from
being repurposed, rooted, etc.

Quoted text here. Click to load it


Site Timeline