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

[Jason Cooper <jason@lakedaemon.net>]

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.

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
the company attempting to get the product certified be the one making
the changes?

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.

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

> - 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.

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

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.