[Ksummit-discuss] Linux and Safety Industry reviews, was: Self nomination
Darren Hart
dvhart at infradead.org
Fri Jul 29 17:11:27 UTC 2016
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.
>
> 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 at 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 at 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.
A response from Nicholas McGuire (SIL2LinuxMP Safety Coordinator) responded
with:
"
We are feeding all findings back as much as we can - regarding the
cert data package its a lot on the process we run and the evidence
we gather - so most of that will not go into the kernel documentation
in any resonable form - but it could help to cleanup the DLC a bit
mostly small things like
"
He also said he would be willing to join us in Santa Fe for a TECH topic. I'll
write one up quickly to get it in today.
>
> > - 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.
>
--
Darren Hart
Intel Open Source Technology Center
More information about the Ksummit-discuss
mailing list