Assembled cognoscenti I was watching a documentary on the fabulous gee-wiz world of autonomous cars; which is apparently going to lead to super safe car journeys and a revival of automotive manufacturing in places where it has been abandoned ! "Autonomous cars are coming, and it's time for everyone to just accept it." http://www.roadandtrack.com/car-culture/features/a26991/autonomous-cars-the-... But then I remembered mention of automotive OS hackers taking over control of a vehicle, http://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/ and all of a sudden the night-mare possibility of 'driving' in a vehicle which has the reliability of a Windows PC, augmented with the capacity to crash and kill me; struck full force [apologies to those who retain the original usage of hacking as 'DIY OS and IT enthusiasts'; this is obviously the more modern denigrating usage of 'OS cracker vandal etc'] In http://www.wired.com/2012/12/automotive-os-war/ there is mention of QNX, Windows and Linux. I guess the question which is bothering me; is in these automotive and perhaps (aeronautical ?); applications of OS's where bugs, hacks and security holes really are' life and death' issues; are the security holes which have been found; just programmer carelessness or reflective of the seemingly never ending generation and discovery of bugs and security glitches ? Will we finish up with something like Qubes; http://www.linux-magazine.com/Online/Features/Qubes-OS where Debian VM's are the security weak point ? regards Rohan McLeod
On Sat, 7 Nov 2015 02:37:11 PM Rohan McLeod wrote:
But then I remembered mention of automotive OS hackers taking over control of a vehicle, http://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/
and all of a sudden the night-mare possibility of 'driving' in a vehicle which has the reliability of a Windows PC, augmented with the capacity to crash and kill me; struck full force [apologies to those who retain the original usage of hacking as 'DIY OS and IT enthusiasts'; this is obviously the more modern denigrating usage of 'OS cracker vandal etc']
There are already many computers controlling essential parts of cars. If the engine control system (which is a standard feature of every car since about 1990) was to stop working on a freeway it could be fatal. ABS and ESC increase the risk. For large scale risks the computers at all nuclear power plants are probably just as vulnerable to a Stuxnet type attack as the Iranian centrifuges. The risk of wholesale death from a series of Chernobyl type events is probably greater than that of small numbers of deaths from cars. It would be possible to implement an emergency stop system in autonomous cars. Press a button and a secondary computer that has no direct access to the primary computer takes over and slows the vehicle to a stop while broadcasting a warning to surrounding vehicles.
I guess the question which is bothering me; is in these automotive and perhaps (aeronautical ?); applications of OS's where bugs, hacks and security holes really are' life and death' issues; are the security holes which have been found; just programmer carelessness or reflective of the seemingly never ending generation and discovery of bugs and security glitches ?
A microkernel OS would probably be a good option. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
Russell Coker wrote:
I guess the question which is bothering me; is in these automotive and perhaps (aeronautical ?); applications of OS's where bugs, hacks and security holes really are' life and death' issues; are the security holes which have been found; just programmer carelessness or reflective of the seemingly never ending generation and discovery of bugs and security glitches ? A microkernel OS would probably be a good option.
Russell I am quite surprised to hear you suggest this, as it would seem to eliminate: -obviously Windows; but also Linux leaving only QNX from the group of OS's mentioned . I have come to associate your name with SELinux a byword for, security and stability .Is it the need for a real-time OS in such applications rather than the requirement, for security and stability which is the basis for this suggestion ? Curiously there seems to be a convergence here with such science-fiction proposals as 'fly-by-fibre' which envisage the replacement of the weight and topological complexity of the aircraft wiring harness with a single ultra-high performance fibre optic net work and a single high voltage DC supply with solid-state DC-DC conversion at each controlled device. Can't find the original reference to such an idea but it cetainly seems implicit in: http://www.avoptics.com/fohec/2012/Presentations/05.pdf regards Rohan McLeod
On Sun, 8 Nov 2015 10:00:37 AM Rohan McLeod wrote:
Russell Coker wrote:
A microkernel OS would probably be a good option.
Russell I am quite surprised to hear you suggest this, as it would seem to eliminate: -obviously Windows; but also Linux leaving only QNX from the group of OS's mentioned . I have come to associate your name with SELinux a byword for, security and stability .Is it the need for a real-time OS in such applications rather than the requirement,
Real-time isn't the main issue here. While some things in car computers require hard real time the vast majority don't. In a car of the future you might expect computers to have hard real-time (engine control), soft real-time (autonomous driving where you only have to reliably beat human reactions) and no real time (car entertainment). Micro-kernel OSs allow least privilege in "kernel" code which is a good thing for security. We already have the Debian HURD project, adapting SE Linux access controls to HURD wouldn't be THAT difficult by the standards of SE Linux development (IE it's easier than some of the things that have already been done). I'm surprised at your surprise. I've mentioned the benefits of micro-kernel OSs in more than a few lectures about SE Linux - including the one I gave this month. The design of the Linux kernel (and all monolithic kernels) limits what can be done with security. The design of some microkernel systems (EG everything based on the "BSD Single Server") has all the same issues. You could possibly consider the Xen kernel to be a micro-kernel if you look at it a certain way and don't take "micro" too literally. It does give some benefits in that regard.
for security and stability which is the basis for this suggestion ? Curiously there seems to be a convergence here with such science-fiction proposals as 'fly-by-fibre' which envisage the replacement of the weight and topological complexity of the aircraft wiring harness with a single ultra-high performance fibre optic net work and
Not a single fiber! I believe that the consensus among pilots is that a twin engine plane is a lot better than a single engine plane as a single failure is less likely to cause a bad result. For things that have life or death issues you need at least twin redundancy and preferrably better. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On 8 Nov 2015, at 10:00, Rohan McLeod <rhn@jeack.com.au> wrote:
I guess the question which is bothering me; is in these automotive and perhaps (aeronautical ?); applications of OS's where bugs, hacks and security holes really are' life and death' issues; are the security holes which have been found; just programmer carelessness or reflective of the seemingly never ending generation and discovery of bugs and security glitches ?
... Curiously there seems to be a convergence here with such science-fiction proposals as 'fly-by-fibre' which envisage the replacement of the weight and topological complexity of the aircraft wiring harness with a single ultra-high performance fibre optic net work and a single high voltage DC supply with solid-state DC-DC conversion at each controlled device. ...
http://www.wired.com/2015/05/feds-say-banned-researcher-commandeered-plane/ I don't foresee automotive (or terrifyingly, aircraft) manufacturers avoiding a lengthy 'hardening' period like we've experienced in general purpose computing.
participants (3)
-
Edward Savage -
Rohan McLeod -
Russell Coker