Dominig, >>> >>> As long as Genivi is happy to work without any security, that will >>> work. >> That's a very silly statement, Dominig. Are you nowadays trying to make >> cooperation difficult, or is it only by mistake? > > It might just be control of nuances in language, I do like to been seen > silly but in my experience, today most of embedded projects are not setup > with an internal security model. Trusted Boot and closes input/output has > delivered what was needed until now. Running all a system as root is still > a common practice from many well respected project.
I suppose you are right - it was just not on my radar to do it that way so I didn't understand that anyone believed that is the way any GENIVI systems intend to be built. Note for example that there has been threat model analysis done in GENIVI that led to an LSM/MAC inclusion as a required part. We are all on the same page there. Implementing access controls according to the needs the product builder has, and definitely running processes with the minimum required privilege - it is indeed the guiding principle. It should not be believed that if the GENIVI specification does not today mention some part that the alliance recommends to leave it out of a final solution. All not mentioned parts are simply not defined by GENIVI, as of today. The compliance specification is currently component based which makes it difficult to expressly describe all details. That is why a "reference architecture" and "system design guidelines" are on the agenda, but preceding that is really some significant analysis of systems that already exist in our industry (a moving target). Things that are missing in spec are usually because enough alignment is not yet achieved. There are multiple ways of doing it all within the GENIVI ecosystem, which you are a part of -- standardizing on one specific MAC, or one application framework has not been possible for example but the analysis work continues. I am convinced that in the meantime we can together find ways to ensure as much compatibility as possible. > > I am not willing to make things difficult, I just wanted to express that > not implementing an > internal security model was still a valid option and plenty of people were > still happy with it. > >> After all it's not the >> first instance in recent times I hear you using misleading language >> constructs >> in some apparent attempt to discredit GENIVI. Do you see the GENIVI Alliance >> a competitor to Tizen or something? When we have talked before I thought you >> understood what GENIVI actually does, so I don't understand why you would >> think that now? > > I would hope that this is not the case, I have been putting a lot of effort > and involved several of Tizen engineers to make sure that Tizen model was > well understood and that we were understanding your requirement in order for > Tizen to remain compliant with Genivi specifications. Tizen has no goal to > write Spec neither to create certification. Tizen is proud to claim it's > compliance with Genivi, it would be silly to discredit it. > >> It also makes little sense, so it seems you took the chance to comment for >> another reason. I know you understand as well as anybody that particular >> implementation details should be kept independent of the general build >> instructions, such that generic layers are possible. > > We discussed Genivi model in Vannes and I understand that Tizen position is > simpler because, we can afford direct choice. Tizen goal is to be Genivi > compliant not to be Genivi spec. > >> If any security related >> details ultimately _must_ influence the original component (its source or its >> build recipes) then this ought to be carefully designed taking into account >> the upstream where the shared home is. Meta-openembedded is one of the >> defacto homes for shared Yocto build recipes and I see no reason why it could >> not continue to play a part in a secure system considering the ability to >> design using both .bb and .bbappends. But if you can, please provide more >> explanation, leaving out any childish cheapshots. > > This was the topic of my presentation at Linux Con in Düsseldorf, so I can > only agree with you, it can be done but it is invasive, so you cannot bolt it > after the fact. > >> At another time maybe there is time to explain what GENIVI actually does in >> terms of security work which is significant but I don't know if there is >> interest to listen. > > I am interested enough to have taken the time to provide feedback on your > initial spec. It is in my (and Tizen) interest that security become > important in Genivi because it would drive both of the projects to focus on > a key common ground. I agree, and rest assured that we share this goal. GENIVI compliant platforms and final products should be built using state of the art principles. Let's work together to align where we can, and the result of that work can be reflected in our specification too. > >> Everyone would have to stop throwing around this big word "security" however >> and starting saying _access control_ when we are talking about that, and use >> other precise terms when we are talking about other things. > >You are right, the short cut is a bit simple, but some time simple word helps >to keep focus. A trade off which is not always ideal. > >In the mean time, if my response was badly received, I would like to apologize >for the lack of clarity. Tizen interest is to work with Genivi and we still >aim at not only be compliant but to be the most attractive implementation of a >Genivi compliant system. > OK, Dominig - let's do it. - Gunnar > >Dominig > -- Gunnar Andersson Lead Architect, GENIVI Alliance Infotainment, Volvo Car Corporation _______________________________________________ IVI mailing list [email protected] https://lists.tizen.org/listinfo/ivi
