I need a mechanism to allow for software updates to be installed. The (abused) "on-line" approach is unacceptable (it forces the device to be "exposed" and makes updates too easy (which seems to mean too frequent!). Pisser is that I need a mechanism that will be supportable for 20-30 years. This likely rules out many commodity approachs (will we be using NANO-SD cards? PICO-SD cards? will USB A/B have given way to C? Or D/E/F?) If you assume updates are few and far between, the cost of the transport medium has little impact on TCO (unlike on-line updates which have a big impact on TCO!). And, if you further assume that the time to perform an update is immaterial (because they are infrequent and because the system allows updates to happen WHILE it is in use -- unlike "reboot to complete your update"), then you don't need a fast interface to deliver the new content. So, it seems that a reasonable approach could be a "module" that talks to the product using an existing communications medium inherent in the product's design (in my case, wired or wireless ethernet). The design of the "update device" can then change with each update -- so long as the system interface remains constant. A dog slow "processor" that can push packets from some storage medium out to the system interface offers lots of design opportunities for processing (dedicated logic) and storage (media devices). Because it is active, it can also make note of how and when it was "consumed" (should reuse want to be discouraged) As it's only a one-time use device, there's no need to make it serviceable -- discard when done. (no desire to have it returned for reuse as it's cost would be a handful of dollars; likely less than the price of a first class *stamp*, soon) Any problems with this approach? Export controls may be an issue but I can leave that to someone else to sort out; maybe just ignore those markets? (I've had to work in markets where you had to smuggle EPROMs through customs...)
Long term software update mechanism
Started by ●November 24, 2023
Reply by ●November 24, 20232023-11-24
On 25-Nov-23 10:09 am, Don Y wrote:> I need a mechanism to allow for software updates to be > installed. The (abused) "on-line" approach is unacceptable > (it forces the device to be "exposed" and makes updates > too easy (which seems to mean too frequent!). > > Pisser is that I need a mechanism that will be supportable > for 20-30 years. This likely rules out many commodity > approachs (will we be using NANO-SD cards? PICO-SD cards? > will USB A/B have given way to C? Or D/E/F?) > > If you assume updates are few and far between, the cost > of the transport medium has little impact on TCO (unlike > on-line updates which have a big impact on TCO!). > > And, if you further assume that the time to perform an > update is immaterial (because they are infrequent and > because the system allows updates to happen WHILE it is > in use -- unlike "reboot to complete your update"), > then you don't need a fast interface to deliver the new > content. > > So, it seems that a reasonable approach could be a "module" > that talks to the product using an existing communications > medium inherent in the product's design (in my case, wired > or wireless ethernet). The design of the "update device" > can then change with each update -- so long as the system > interface remains constant. > > A dog slow "processor" that can push packets from some > storage medium out to the system interface offers lots > of design opportunities for processing (dedicated logic) > and storage (media devices). > > Because it is active, it can also make note of how and > when it was "consumed" (should reuse want to be discouraged) > > As it's only a one-time use device, there's no need to make it > serviceable -- discard when done. (no desire to have it > returned for reuse as it's cost would be a handful of dollars; > likely less than the price of a first class *stamp*, soon) > > Any problems with this approach? Export controls may be an > issue but I can leave that to someone else to sort out; > maybe just ignore those markets? (I've had to work in markets > where you had to smuggle EPROMs through customs...) >I wouldn't want to rely on wireless ethernet - there's too much in there that could change over time to the extent that no then available device could talk to it. Preventing managers from causing on-line update to become available is really difficult as long as software can do updating, since even if on-line update is not implemented from day one, it could be implemented via the last non-online update. The solution is a device that is physically incapable of updating itself unless some local action is taken, such as pressing a button. As long as no one implements a remote button-pressing device. Sylvia.
Reply by ●November 25, 20232023-11-25
The idiot Sylvia Else <sylvia@email.invalid> persisting in being an Off-topic troll... -- Sylvia Else <sylvia@email.invalid> wrote:> Path: not-for-mail > From: Sylvia Else <sylvia@email.invalid> > Newsgroups: sci.electronics.design > Subject: Re: Long term software update mechanism > Date: Sat, 25 Nov 2023 11:05:54 +1100 > Lines: 62 > Message-ID: <kscs31F66frU1@mid.individual.net> > References: <ujrafj$2gf17$2@dont-email.me> > Mime-Version: 1.0 > Content-Type: text/plain; charset=UTF-8; format=flowed > Content-Transfer-Encoding: 8bit > X-Trace: individual.net rDAKk/p80ahAuOyreqglRwODgCyyiFGoPMV5B5rN7vuObKYaZd > Cancel-Lock: sha1:IxqlpO6k0LxADXqrLtDB/xMlRRY= sha256:D5s9zx7ZQmydI9qJXpN/oaMITEk+tJ/yIvrgDbolerc= > User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 > Thunderbird/102.15.1 > Content-Language: en-US > In-Reply-To: <ujrafj$2gf17$2@dont-email.me> > X-Received-Bytes: 3733
Reply by ●November 25, 20232023-11-25
The arsehole Don Y <blockedofcourse@foo.invalid> persisting in being an Off-topic troll... -- Don Y <blockedofcourse@foo.invalid> wrote:> Path: not-for-mail > From: Don Y <blockedofcourse@foo.invalid> > Newsgroups: sci.electronics.design > Subject: Long term software update mechanism > Date: Fri, 24 Nov 2023 16:09:30 -0700 > Organization: A noiseless patient Spider > Lines: 46 > Message-ID: <ujrafj$2gf17$2@dont-email.me> > MIME-Version: 1.0 > Content-Type: text/plain; charset=UTF-8; format=flowed > Content-Transfer-Encoding: 7bit > Injection-Date: Fri, 24 Nov 2023 23:09:41 -0000 (UTC) > Injection-Info: dont-email.me; posting-host="6f5b1a0178efa4f620cd38698cdeb5ed"; > logging-data="2636839"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+9rjAEDZfHs21SL5I0Y+oS" > User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101 > Thunderbird/102.2.2 > Cancel-Lock: sha1:ZdSS3m+PMFjQdXP0pKljPgl0M8o= > Content-Language: en-US > X-Received-Bytes: 3093
Reply by ●November 25, 20232023-11-25
On 11/24/2023 5:05 PM, Sylvia Else wrote:> On 25-Nov-23 10:09 am, Don Y wrote: >> I need a mechanism to allow for software updates to be >> installed. The (abused) "on-line" approach is unacceptable >> (it forces the device to be "exposed" and makes updates >> too easy (which seems to mean too frequent!). >> >> Pisser is that I need a mechanism that will be supportable >> for 20-30 years. This likely rules out many commodity >> approachs (will we be using NANO-SD cards? PICO-SD cards? >> will USB A/B have given way to C? Or D/E/F?) >> >> If you assume updates are few and far between, the cost >> of the transport medium has little impact on TCO (unlike >> on-line updates which have a big impact on TCO!). >> >> And, if you further assume that the time to perform an >> update is immaterial (because they are infrequent and >> because the system allows updates to happen WHILE it is >> in use -- unlike "reboot to complete your update"), >> then you don't need a fast interface to deliver the new >> content. >> >> So, it seems that a reasonable approach could be a "module" >> that talks to the product using an existing communications >> medium inherent in the product's design (in my case, wired >> or wireless ethernet). The design of the "update device" >> can then change with each update -- so long as the system >> interface remains constant. >> >> A dog slow "processor" that can push packets from some >> storage medium out to the system interface offers lots >> of design opportunities for processing (dedicated logic) >> and storage (media devices). >> >> Because it is active, it can also make note of how and >> when it was "consumed" (should reuse want to be discouraged) >> >> As it's only a one-time use device, there's no need to make it >> serviceable -- discard when done. (no desire to have it >> returned for reuse as it's cost would be a handful of dollars; >> likely less than the price of a first class *stamp*, soon) >> >> Any problems with this approach? Export controls may be an >> issue but I can leave that to someone else to sort out; >> maybe just ignore those markets? (I've had to work in markets >> where you had to smuggle EPROMs through customs...) > > I wouldn't want to rely on wireless ethernet - there's too much in there that > could change over time to the extent that no then available device could talk > to it.I (currently) only use wired connections. This for several reasons: - requires physical access for tampering/interception/DoS - allows power to be distributed remotely - high bandwidth regardless of scale But, I can't rule out someone, eventually, opting for a wireless connection (with caveats) within the system -- for some special need.> Preventing managers from causing on-line update to become available is really > difficult as long as software can do updating, since even if on-line update is > not implemented from day one, it could be implemented via the last non-online > update.The bar is set pretty high, for that. I don't use a TCP/IP stack so anyone wanting to talk to the outside world would have to undertake the task of integrating that functionality and associated "capabilities" (permissions) as well as determining who/what would use them. (The hardware to do so is a relatively trivial undertaking) Additionally, developing (and validating) a mechanism to protect the rest of the system from any potential hostile actions that the new attack surface makes possible. And, of course, committing to supporting an update server (and policy) at a well-known address for a substantial period of time. If you "run the numbers", it's cheaper to make a semi-disposable device to do this (that gives you the ability to keep revising subsequent devices as different storage media come into fashion)> The solution is a device that is physically incapable of updating itself unless > some local action is taken, such as pressing a button. As long as no one > implements a remote button-pressing device.New devices ("nodes") are introduced to my system by exactly such a mechanism. The admission terminal is intended to be located someplace physically secure (so the initial communications with the device can be secure and so only trusted personnel can perform said actions). The device's identity and capabilities are discovered through this admission process, followed by KEX and the registration of the device in the system's configuration. Thereafter, the ultimate network location of the device is discovered when it finds it's ultimate home. I was thinking of using the same mechanism, protocol, etc. for an "updater" device -- whose function is to deliver new software to the system. As this is of a transitory nature, the device need never "appear" anywhere other than the admission terminal and, there, only for the time it takes to dump its contents.
Reply by ●November 25, 20232023-11-25
On 25-Nov-23 4:30 pm, a a wrote:> The arsehole Don Y <blockedofcourse@foo.invalid> persisting in being an Off-topic troll... >That seems rather harsh. The line between hardware and software has become rather blurred, with many devices that Joe public would think of as just electronics actually containing some software elements. Sylvia.
Reply by ●November 25, 20232023-11-25
On 11/25/2023 12:34 AM, Sylvia Else wrote:> On 25-Nov-23 4:30 pm, a a wrote:I'm surprised ANYONE still sees posts from "a a"!> That seems rather harsh. > > The line between hardware and software has become rather blurred, with many > devices that Joe public would think of as just electronics actually containing > some software elements.I suspect there are far more "deeply embedded" devices in existence, today, than "pure electronic" devices -- both in numbers and designs. It seems far too easy to put a processor into a design rather than a few discretes (and then let feeping creaturism do the rest!) In fact, the question centered around a physical DEVICE to deliver updates -- instead of the ubiquitous "software service" that is used, nowadays. (I actually suggested it could be "dedicated logic") [I guess it takes a certain level of intelligence to be able to perceive that (likely "a a" doesn't rise to that level). But, that's what you'd expect from folks who live under bridges...]
Reply by ●November 25, 20232023-11-25
On Friday, November 24, 2023 at 3:09:47 PM UTC-8, Don Y wrote:> I need a mechanism to allow for software updates to be > installed. The (abused) "on-line" approach is unacceptable > (it forces the device to be "exposed" and makes updates > too easy (which seems to mean too frequent!). > > Pisser is that I need a mechanism that will be supportable > for 20-30 years. This likely rules out many commodity > approachs (will we be using NANO-SD cards? PICO-SD cards? > will USB A/B have given way to C? Or D/E/F?)Futureproofing is an unsolved problem. Backstop for such issues, is swapping major parts of the device back to the factory. This assumes the factory with the update is not in a war zone or supervolcano caldera.
Reply by ●November 26, 20232023-11-26
On 24/11/2023 23:09, Don Y wrote:> I need a mechanism to allow for software updates to be > installed. The (abused) "on-line" approach is unacceptable > (it forces the device to be "exposed" and makes updates > too easy (which seems to mean too frequent!).An Ethernet socket and a dedicated line to connect it to whatever hardware du jour happens to be? I can't see physical wired Ethernet going away any time soon. (other cheap fast serial protocols are available) I still have the odd thing hanging around that requires it's firmware to be bitbashed down a bidirectional parallel printer port (remember them?). I keep one such machine with that, RS485, an ancient SCSI card and even more antique IEEE488 card for just such occasions. The one that really annoys me is my high end internet radio tuner (early adopter) the BBC has effectively bricked it since they changed their streaming format and the device now more than 5 years old is no longer supported. It is a *BIG* problem with so-called "smart" devices :( It still works fine for ROW programme content. -- Martin Brown
Reply by ●November 26, 20232023-11-26
Martin Brown <'''newspam'''@nonad.co.uk> wrote:> On 24/11/2023 23:09, Don Y wrote: >> I need a mechanism to allow for software updates to be >> installed. The (abused) "on-line" approach is unacceptable >> (it forces the device to be "exposed" and makes updates >> too easy (which seems to mean too frequent!). > > An Ethernet socket and a dedicated line to connect it to whatever > hardware du jour happens to be? > I can't see physical wired Ethernet going away any time soon. > (other cheap fast serial protocols are available) > > I still have the odd thing hanging around that requires it's firmware to > be bitbashed down a bidirectional parallel printer port (remember > them?). I keep one such machine with that, RS485, an ancient SCSI card > and even more antique IEEE488 card for just such occasions. > > The one that really annoys me is my high end internet radio tuner (early > adopter) the BBC has effectively bricked it since they changed their > streaming format and the device now more than 5 years old is no longer > supported. It is a *BIG* problem with so-called "smart" devices :( > > It still works fine for ROW programme content. >Gee, Martin, what part of “move fast and break things“ didn’t you get? ;) Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics
