Re: [Ksummit-discuss] Linux and Safety Industry reviews, was: Self nomination

[Darren Hart <dvhart@infradead.org>]

On Wed, Jul 27, 2016 at 01:46:02PM +0000, Jason Cooper wrote:
> Linus, Darren,
> 
> I'm also tangentially interested in this discussion from a security point
> of view.  Failing in a deterministic way is a desirable trait in both
> the security and safety industries.

I'm considering proposing a tech topic, sounds like there may be sufficient
interest.

> 
> On Wed, Jul 27, 2016 at 11:25:52AM +0200, Linus Walleij wrote:
> > On Wed, Jul 27, 2016 at 6:46 AM, Darren Hart <dvhart@infradead.org> wrote:
> > 
> > >   - Developing a "safety culture" and any overlap that may have with security
> ...
> > My loose thoughts on the issue is twofold:
> > 
> > - We will have an influx of professional safety reviewers that do not
> >   share their review comments with us, instead apply fixes locally and
> >   not upstream. This is potentially dangerous if the next reviewer for
> >   a safety-critical system misses the same bug. 
> 
> I thought the safety reviewers were an independent third party?  Wouldn't

Yes, the various German and Switzerland TUeV organizations for example.

> the company attempting to get the product certified be the one making
> the changes?

That's the traditional approach, but that is impractical for something as
complex as Linux. Like most arguments for open source software, it behooves the
industry to collaborate on the common needs, such as a compliance route, data
package, evidences, and argumentation for the Linux kernel, glibc, and basic
runtime environment. This is the goal of the OSADL SIL2LinuxMP project:

http://www.osadl.org/SIL2LinuxMP.sil2-linux-project.0.html

> 
> Regardless, identifying these third party reviewers and asking them to
> 'Cc linux-safety@v.k.o' or similar on bugs they find may be a good place
> to start.  The trick is increasing our awareness of bugs with the least
> impact to their workflow.

This sounds like a good idea to me, I'll discuss with the OSADL safety
coordinator and see if he has any concerns.

> 
> We would also need to anticipate that a significant number of those
> reports would be located in non-upstreamed vendor drivers/features.

Like bug against non-upstream drivers, there isn't anything we can really do
there. Also, the compliance route for Linux will depend heavily on code that is
upstream as the development process and requisite code review, static analysis,
etc. is part of the evidence that will be used to complete the data package for
qualification. Non-upstream code will not be able to use the same compliance
route, and will most likely have to take a more traditional route.

> 
> > - Can we record external inspection-only code reviews done by these
> >   independent code reviewers (post-minimization) into the kernel (etc) git?
> >   That I guess is pretty useful for building formal trust for the code,
> >   but I never heard of git annotations to some random code lines like
> >   that.
> 
> How do they mark up $codebase currently?  It would be helpful to hear a
> walk through of their typical workflow.

I'll follow up.

> 
> > - Should minimization be a part of the kernel standard tooling for use
> >   cases like this?
> 

Yes. A team at Hitachi is also working tooling which performs some preprocessing
of the code to further minimize and remove used code. They are an active
contributor to the SIL2LinuxMP project and presented their work at the
Automotive Linux Summit in Japan earlier this month.

> I think so.  This also has other benefits.  I've been putting some
> thought towards "how to make the engineers job easier when justifying a
> kernel update"  If a vendor has a minimal config for their current
> version, I could imagine a 'git diff v4.6..v4.7 | ./scripts/configdiff
> ...' that would trim the diff between two kernel versions down to only
> the config-enabled code.  Bonus points for taking 'git log --oneline
> v4.6..v4.7' output and trimming to relevant commits.
> 
> This would reduce hours needed to review the changes, help focus QA
> testing, and quantify the benefits of upgrading.  All of which makes it
> easier for vendors to update kernels instead of getting 'stuck'.
> 
> thx,
> 
> Jason.
> 

-- 
Darren Hart
Intel Open Source Technology Center