Topics

Kernel Configurations in the Tool Investigation and Code Improvement Subgroup


Lukas Bulwahn
 

Dear all,

In the last meeting, it was requested to share the kernel
configurations the Tool Investigation and Code Improvement Subgroup is
using.

We currently use:
- x86-64 tinyconfig: this can be created with 'make tinyconfig' for
initial investigations of tools (to get a small overview of the number
of findings on a very small config.)
- x86-64 defconfig without DRM, SOUND, USB for the CI system. You
can obtain the config with:

for clang-analyzer:

make CC=clang defconfig
scripts/config -d CONFIG_DRM
scripts/config -d CONFIG_SOUND
scripts/config -d CONFIG_USB_SUPPORT

for smatch:

make defconfig
scripts/config -d CONFIG_DRM
scripts/config -d CONFIG_SOUND
scripts/config -d CONFIG_USB_SUPPORT

If you have any feedback on this kernel configuration, please let us know.

As of now, it looks like a manageable code base to continue our investigations.

Best regards,

Lukas


elana.copperman@...
 

Following initial discussion with Lukas, here is a summary of some relevant guidelines:
  1. tinyconfiig is ok but still needs some tweaking so that you can boot the system (e.g., add support for initrd; printk output during kernel boot; ELF binaries; procfs; sysfs).
    Also, there have been some customized patches introduced over the years, so that tinyconfig does not exactly match default Linux release.
    You should work with a kernel that is standard, minimally bootable and supports kernel boot output. 
      
  2. Strategy:
    a) ELISA alone will never be able to fix all bugs at a faster rate than natural kernel growth introduces new bugs.
      Try to quantify your bug handling capacity and aim to have a kernel on which you can fix bugs at a faster rate than new ones are introduced on average as the system grows.
    b) Remove subsystems methodically (so that we have a clear scope of what is / is not covered), bringing it down to a size for which the number of errors is reasonable and scalable.
    c) Publicize your work and create incentive for others to tackle additional subsystems for their own needs, so that this can become a community effort.
      
  3. Candidates for removal from your test scope.  After a first scale down, compare output to capacity (see point 2 above), and we may then repeat the process until we get a kernel with which we can work effectively.
    a)  All architecture specific settings (including all Android settings)
    b) All vendor specific hardware interfaces.
    c) USB, DRM, sound as well as HI subsystems.
    d) Plug-n-play (PnP) device interfaces
    e) Deprecated ETH protocols (e.g., RARP; EGP; IGRP) as well as protocols which are relevant only with deleted subsystems (e.g., UCAN).
    f) Bluetooth functionality 
    g) Debug functionality
    i) Common functionality which is also removed from tinyconfig.  These may be needed, but according to our plan - whoever complains, is invited to do the work on any subsystem:
  • BLOCK
  • MULTIUSER
  • TIMERFD
  • MEMBARRIER
  • COMPAT_BRK
  • PROC_SYSCTL
  • Enable CONFIG_PREEMPT_NONE
Regards
Elana


From: devel@... <devel@...> on behalf of Lukas Bulwahn <lukas.bulwahn@...>
Sent: Monday, November 30, 2020 2:01 PM
To: devel@... <devel@...>
Subject: [ELISA Technical Community] Kernel Configurations in the Tool Investigation and Code Improvement Subgroup
 
Dear all,

In the last meeting, it was requested to share the kernel
configurations the Tool Investigation and Code Improvement Subgroup is
using.

We currently use:
  - x86-64 tinyconfig: this can be created with 'make tinyconfig' for
initial investigations of tools (to get a small overview of the number
of findings on a very small config.)
  - x86-64 defconfig without DRM, SOUND, USB for the CI system. You
can obtain the config with:

for clang-analyzer:

make CC=clang defconfig
scripts/config -d CONFIG_DRM
scripts/config -d CONFIG_SOUND
scripts/config -d CONFIG_USB_SUPPORT

for smatch:

make defconfig
scripts/config -d CONFIG_DRM
scripts/config -d CONFIG_SOUND
scripts/config -d CONFIG_USB_SUPPORT

If you have any feedback on this kernel configuration, please let us know.

As of now, it looks like a manageable code base to continue our investigations.

Best regards,

Lukas






Lukas Bulwahn
 

On Tue, Dec 1, 2020 at 12:38 PM Elana Copperman
<Elana.Copperman@mobileye.com> wrote:

Following initial discussion with Lukas, here is a summary of some relevant guidelines:

tinyconfiig is ok but still needs some tweaking so that you can boot the system (e.g., add support for initrd; printk output during kernel boot; ELF binaries; procfs; sysfs).
Also, there have been some customized patches introduced over the years, so that tinyconfig does not exactly match default Linux release.
You should work with a kernel that is standard, minimally bootable and supports kernel boot output.

Strategy:
a) ELISA alone will never be able to fix all bugs at a faster rate than natural kernel growth introduces new bugs.
Try to quantify your bug handling capacity and aim to have a kernel on which you can fix bugs at a faster rate than new ones are introduced on average as the system grows.
b) Remove subsystems methodically (so that we have a clear scope of what is / is not covered), bringing it down to a size for which the number of errors is reasonable and scalable.
c) Publicize your work and create incentive for others to tackle additional subsystems for their own needs, so that this can become a community effort.
Thanks, Elana. This will be our strategy.

We will start tracking and fixing all new bugs on tinyconfig for a
small selection of tools, which should be doable by the current group
(I think it is doable with a few hours of work each week).

Then, we continue to add selectively more functionality and code that
we can handle, if the group of participants grows.

Lukas