Automotive Microconference Notes

Welcome to Linux Plumbers Conference 2014.

Please use this etherpad to take notes. Microconf leaders will be giving a summary of their microconference
during the Friday afternoon closing session. Please remember there is no video this year, so your notes are
the only record of your microconference.

Smart system shutdown: Colin Guthrie, Timo Mueller

Basic use cases
	* do not shutdown the car system while a phone call is still going on. e.g you arrived home,
	stop the engine and are still on the phone. 
	* user initiated an emergency call, user presses the SOS button, do not shutdown the system
	even if the battery is almost empty
	* automatic initiated emergency call, after a car crash, shutdown the system as soon as
	the emergency call is finished

Could this be achieved by using systemd's inhibitors?

What are inhibitors:
	* a framework implemented inside systemd
	* it's a project of its own, not PID1 itself.
	* the origin is in logind
	* a proxy for the raw
	* 2 types of inhibibors: delay and block
		* delay: things needed to be done before going to sleep (lock screen, ...)
		* block: prevents the transition, stop logind proxying request to PID1

Example: call in progress: using block inhibator: 
    systemd-inhibit --mode block --what shutdown:sleep:idle  --who "telephony" --why "call in progress"

Should we use block or delay?
	* loooong delay might be better than block. delay tracks if the user application (e.g telephony software) 
	dyies and frees the resource (unblocks) the transition
	* While you are blocking a shutdown, you do not get notified if someone actually requested a shutdown

Implementation:
	* When you register an inhibitor you'll get an open file descriptor. Once your done you close it to release the inhibition
	* the inhibitor framework has good documentation (man pages and wiki site)
		* http://www.freedesktop.org/software/systemd/man/systemd-inhibit.html
		* http://www.freedesktop.org/wiki/Software/systemd/inhibit/

Q: What about the GENIVI node state managers? Have you look at it?
A: Nope

GENIVI node state manager (http://projects.genivi.org/node-state-manager/)
	* a framework which supports sessions, and state machine for live cycling. Allows to program all the logic you need
	for service startup and stop.
	* Uses systemd's D-Bus API to orchistrate the shutdown behavior, without actually issuing a shutdown until the
	very end. This is done because a shutdown in progress you need to be able to stop the shutdown and start the
	system again. (Do a "U-Turn" on shutdown)

Q: Can you register another delay inhibitor when you are currently delaying the shutdown
A: Potentially it could work but need to check the implementation. 

Q: What about switching into a emergency level instead of blocking the state change? Especially if there is an emergency?
A: This will help to do more than just keeping the current state. E.g. cleanups and other shutdown routines.

Q: Is this only for emergency call?
A: No, there are more triggers for a transitions

Q:  Are you able to express dependencies? What about expressing targets in way to check them formaly?
A: Inhibitors are treated equally, no differenciation between inhibitors at this point.

Remote Vehicle Interaction Archicture RVI: Rudolf Streif
RVI is a project from JLR enabling remote control
	* 80% of the communcation framework is the same for everyone
	* Sharing a platform/API is better for everyone (OEM)
	* How do we allow an in-vehicle application to exchange data with other devices and services? Build an open source
	technology to handle authentication, authorization, discovery, data exchange

Features
	* P2P, no central service necessary. This is a bit a different to MQTT. 
	* Provisioning: servers and nodes can be added and deleted from the system
	* Authentication & authorization
	* Service discovery
	* Doesn't need to be tcp only. SMS messages for starting a service remotely is also supported

Status: AGL expert group formed and running
Program language: Erlang

Q: Do you use higher level description of services(IDL)?
A:  No, the communication is defined at the JSON-RPC level

Planned features/demo: remote CAN monitoring, software over the air, control navagation remotely (POIs,...)
 
Architecture:
API based, Data Router (central component on a node), shield the network compelexity
	* Data router: service edge, authorization, schedule, data link, service discovery, protocol
	* Services: global namespace for all services (worldwide), localizes service discoverying
    url: jlr.com/vin/sajawaw48383843/body/lock
    organization, vin sub-tree, vin, service name, command
	* authorization: certificate based, self-carried authorization (a node presents its certifcates to another node to access its
	services, without provisioning server connection), service specific certificates (encodes the command which is allowed)

Q: How is authorization handled (is there a PKI infrastructure)?
A: No certificate store so far. Needs more thinking on this, e.g. integrate into Android etc. 
Trying to avoid different behaviour for the different plattforms

Future plans 
	* widen the scope to IOT
	* Started discussion and try to join efforts with the joynr project
  
Q: Is Flexray in scope?
A: yes, sure, it's 'just' another transport.

Q: Do you plan to get it certified as a GENIVI component?
A: We want to build the platform (write the software) first and than investigate this further

Q: What about SmartDeviceLink? Is this related?
A: SDL only locally links between smartphone and the IVI system. RVI allows more communcation configurations. 

Q: Are there plans to use this for on-board communcation?
A: Yes.

Q: How about dependabilty in the board communcation?
A: Depends on the channel, what it provides. RVI is not really designed for mission critical systems.


Process isolation for autonomous driving: Tilman Ochs
Target: Use the Linux System for ADAS and automomous driving

Currently there are different systems
	* tiny resource ECU with hard realtime (e.g. AUTOSAR systems)
	* IVI systems
	* Some kind of autonomous driving systems with lot's of computational systems which are good for dependability
	* Systems taht will heavily communicate with backend systems

Major Challenges
	* several software components
	* some components are saftey critial
	* interferences needs to be reduced
	* random bug crashes on component in an unspecified way and this needs to be isolated

Basic architecture:
	* Have a Basic platform that works on arbitrary hardware (ASIL qualified)
	* "Personalities" on top of this platform, providing functionality (ROS or AUTOSAR)

Virtualisaion vs. Proces Isolation
	* Full Virt
		* + strong islolation
		* - more sw components than cores
		* - lot's of overhead
		* - less flexible (reconfigure partitions, for example)
	* Process Isolation
		* + sufficient isolation 
		* + more resource efficiency
		* - no off-the-shelf solution for safety
	* OSLevel virtualisation (docker, LXC, ...)
		* + large communities
		* - slight runtime overhead (docker runtime) this is not needed for safety stuff

There are a lot of relevant features
	* Kernel features: seccomp, jailhouse, netfilter
	* Containers features: how strong is the isolation?
	* Research: memguard (memory bandwidth reservation)

What would we need to looking up?

Q: Do you expect rt requirements
A: yes, there are rt requirements that should be doable with preempt_rt
But some some systems need a lot of memory (mostly with heavy computational effort)
Plan B would be to use plain linux and features like jailhouse

Q: Do you expect the kernel to be ASIL-B or C compliant?
A: yes, and this is currently worked on with OSADL 
Special configuration of the kernel is worked on that can be ASIL-B
Confident that is will be possible, but needs process isolation
Could also be achieved by saftey kernels or something like jailhouse
Configuration is pretty small (you need to get rid of the drivers and
put them in the userspace)
Kind of like a microkernel approach
"Tannenbaum must be really happy now"
Minix dosn't solve it because we want to support different hardware
and large parts like memory management is largely tested in field with
linux kernel

Q: Are there members involved who backup this confidence
A: yes, already being worked on with TÜV
Of course saftey people need to be convinced
All standards have ways to qualify an existing software.
"Following the standard process the kernel it be possible to qualify
the kernel"

It's possible to qualify for ASIL-B, not always needed to qualify
everything and still show that the overall system is right. 

Linux will play a part in the system, but it will definitely not be
possible to qualify the whole thing 

Linux containers might be interesting using mandantory access controls

Q: are the current access controls suffient or are there other interferences
A: unsure, Matthew Garret showed some effect
e.g. when you stress 3 cores hard enough the temperature rises and
affects the 4. core. So the pure software isolation is affected

Q: Safety or Security, what are you targeting?
A: Both. Difference -> with safety the attack spot is random

Q: could chroot solve something
A: might work on the filesystem level and blocking specific system calls.
This is essentially SECCOMP
Android acutally patched the socket code to limit application from opening specific sockets

Q: Does Tizen Security use specific patches to create security
A: couple of D-Bus patches, nothing on the kernel side. kdbus might solve some problem