From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 30AFDD54 for ; Wed, 12 Sep 2018 10:35:21 +0000 (UTC) Received: from mail-it0-f65.google.com (mail-it0-f65.google.com [209.85.214.65]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C1DB1798 for ; Wed, 12 Sep 2018 10:35:20 +0000 (UTC) Received: by mail-it0-f65.google.com with SMTP id e14-v6so2317943itf.1 for ; Wed, 12 Sep 2018 03:35:20 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Linus Walleij Date: Wed, 12 Sep 2018 12:35:07 +0200 Message-ID: To: tiejunc@vmware.com Content-Type: text/plain; charset="UTF-8" Cc: ksummit-discuss@lists.linuxfoundation.org Subject: Re: [Ksummit-discuss] [TECH TOPIC] A Safety-critical Linux system architecture List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Wed, Sep 12, 2018 at 3:18 AM Tiejun Chen wrote: > software contexts need to be certified according to different specifications > like ARINC 653, Automotive Safety Integrity Level, and so on. So we > need to explore making Linux itself certified. There is a bunch of these certifications and specifications. Many of them include manual review of "all code on the system", which is why several approaches to this includes stripping down the kernel source to only the code (after removing all Kconfig buzz and ifdefs) that will compile and run on the target. This should of course be possible to integrate into the existing Linux build system, like "make sources" that would create a reduced kernel tree that will also compile (russian matroska dolls come to mind). I think such projects exist in Japan but I haven't heard from them recently. My pet peeve is that the review process appears to be something along the lines that a "certified person/consultant" who has training in this standard is supposed to review all the code for safety, so after reviewing IMO we should work on (A) making sure that these reviews and comments and the exact lines of the kernel and which version/commit ID of it it pertains to is made public and (B) that the review persons statement be merged into the kernel git log as some kind of annotation along the lines of: Reviewed-for-ISO-26262-by: Linus Walleij This way we can help the safety community by making the safety critical review process more open and public, and also making these reviewers put their personal names behind it. If they also propose patches and follow up on them: even better. The idea is not (as one could maybe think) that of public shaming for all the stuff these people invariably are going to miss, but to create a space where they can learn about the kernel and the weaknesses pertaining to safety critical deployments and also spread this knowledge to kernel maintainers instead of keeping it all in their private safety engineering bubble. Yours, Linus Walleij