Embedded Systems December 2000 Vol13_13

Issue link:

Contents of this Issue


Page 95 of 197

MURPHY'S LAW . Now that we have seen that our mind game with maliciously inclined soft- ware can correspond to real failures, what can we do about it? Double checks in software w. iII only give us limited protection, and it is always possible that our malicious program will disable that check at the most important time. software was rese L. IL was also assumed that an operator was pre- senL-otherwise who would turn the device off and on? The safeL y valve software has halted, the alarm code may nOL geL a chance to run again . So a single poin t of failure has led to o ur control mechanism going out of con- Lrol and our moniLoring system being di sabled . Maybe you sho uld SLOp read ing fo r a mome nt and considel- if a similar failure could occur on your curre nt proj ect. A mo re malicious failure would not just hal t the monitoring system, but also di splay misleading data o n th e user inte rface. Explicitly te ll ing the user thaL everything was fin e , whe n just the opposite is Lrue lures th e user into a false sense of securi ty. In o ne in cide nt, an a nesLhesiologisl became suspi cio us whe n a blood pressure monito r di splayed dala th aL did not fiL WiLh the pati en t's other symptoms. Whe n th e moniLor 's dis- play was examined more care full y, iL lurn ed out thal the wo rds "Demo mod e" appeared occasiona lly in small pri n t. 1 The mo ni to r had bee n placed in thi s mode durin g a ro utin e se rvice, and Lhen pUL in to use . The indica- ti o n o n th e di splay that it was oper- ating in demonstratio n mode was smail and inte rmitte nt-not eno ugh to attract atte n tio n in a busy wal-d . "All , but," objects lhe sofLware e ngi- neer, "iL was not a bug. They we re jusL not usin g it pro pe rl y." T hat obj ec Li o n does not holdup. So ftware e ngineers are not just respo nsible fo r writing software that conforms LO requireme n ts , but th ey must ensure tha t th ose require men ts a re safe. In thi case, th e requirements should have sta ted that the user in te rrace should make it very obvious at all times when the device is in demo n- stratio n mode. Now that we h ave see n thal our game with ma liciou sly min d inclin ed software ca n co rrespond to real fa ilures, wha t can we do abo ut it? Do ubl e checks in software will o nly give us limited pro tectio n, and it is always possible LhaL o ur mali- c io us program will di sabl e tha t check at th e most importa nt tim e . So the soluLi o n has to be o utside of software. A mechani ca l o r electro ni c mecha nism tha t restri cts th e acti ons LhaL software can take is call ed an in te rlock. This is a lock that pre- ven ts ce rta in actions" or makes o ne action de pende nt on a ce rtain sta te , o r fo rces a ce rta in combinati on of actions to happe n in a parti cul ar o rde r. One example is e levato r doors. When the doors are o pened the eleva- tor will often be electrically inhibited from movi ng. Simi larly, train doors prevenL the u-ain [rom moving if they are open. Lock-in and lock-out Going back to our medical ventilator example, one of the compone nts was a safety valve tha t wo uld ope n if the a ir pressure reached a certain thresh- old . Software could insu-uct the safeL y valve to o pen at a lowe r pressure i[ it detected pressure rising too quickly. Software could also close the valve, so long as the valve had been ope ned by software. Once the safeL Y valve had o pened because iL had reached its mechanical crackin g pressure, it remained ope n unLi l the power was cycled. Effeclive ly, th e valve was mak- ing the decision that the software could not be tru ted , on th e grounds that pressure had reached a value that wo uld nOL have been reached with software executing its control loop properl y. Once a power cycle occurred, you could be sure th at th e 94 DECEMBER 2000 Embedded Systems Programming was a limiting component, but it also provided a lock-o ut. Once soflware allowed the controlled activiLy to go o utside of its operating envelope, it was locked out, and was not allowed to control the process again until some kind of human inte rve ntion took place. Some devi ces clever ly restrict yo u to a ce rtain mode on ce you are the re. Many MCUs come equipped with a wa tchdog time r.2 Typicall y, the device can o perate in one of two modes. In watchdog-enabl ed mode, lhe softwa re must se t some registe r o n a regular basis as a confirma tion tha t the software is sLi ll running nor- mally. In watchdog-disabled mode the software does not have to pro- vide this strobe. For a safe ty-critical system, you always want to ope rate in watchdog-e nabled mode. Howeve r, you have Lo contend with o ur imagi- na ry ma li cio us programme r, and assume Lh at o ne of th e first things he wo uld do, once he has take n control, is turn tha t wa tchdog time r off. This is why many MCUs that employ a wa tchdog time r use a lock-in. Once you e nable the watchdog, you can- not disable it without a processor reset. So long as your software func- tions correctly up to the poin t whe re the watchdog is enabled, you are gua ranteed that it will be enabled from th at tim e forward, regard less of any bugs you may have. As we ll as having a lock-in for cer- ta in modes, you may wa nt a lock-out fo r othe rs. Let 's re tunl to the exam- ple of the pa tient mo nito r that was left in demonstration mode. To th e designers' cred it, they realized that it wo uld nOL be a good th ing if the o pe ra tor accide n ta lly e n te red demo nstra tio n mode while the device was in use. So th ey put pass- wo rd protection on th e demonstra- Lion mode. Typically, service techni- ci ans wo u ld kn ow the password,

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems December 2000 Vol13_13