7 Nov
2015
7 Nov
'15
2:37 p.m.
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
7 Nov
7 Nov
8:33 p.m.
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/
8 Nov
8 Nov
10 a.m.
Russell Coker wrote:
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
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.
5:54 p.m.
On Sun, 8 Nov 2015 10:00:37 AM Rohan McLeod wrote:
Russell Coker wrote:
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.
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
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/
7:38 p.m.
On 8 Nov 2015, at 10:00, Rohan McLeod
<rhn(a)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.
2695
days inactive
2696
days old
4 comments
3 participants
participants (3)
-
Edward Savage -
Rohan McLeod -
Russell Coker