02 Apr 2025 - elisa-tech/tsc GitHub Wiki

Roll call

** indicates TSC voting members*

Host

  • *Philipp Ahmann

Attended this meeting

  • Pierre Brangier
  • *Alessandro Carminati
  • *Luigi Pellecchia
  • *Matthew Weber
  • Patrick Uven
  • Henrik Brandle
  • Pete Brink
  • *Igor Stoppa
  • *Gabriele Paoloni
  • *Kate Stewart
  • *Paul Albertella
  • *Sudip Mukherjee
  • Qasim Majeed
  • *Olivier Charrier
  • *Christopher Temple

Regrets

  • *Nicole Pappler

Attended recently in the past

  • *Christopher Temple
  • *Nicole Pappler
  • *Olivier Charrier
  • *Kate Stewart
  • Pierre Brangier
  • Patrick Uven
  • *Paul Albertella
  • *Igor Stoppa
  • *Alessandro Carminati
  • *Gabriele Paoloni
  • *Matthew Weber
  • *Matt Kelly
  • *Sudip Mukherjee
  • *Lukas Bulwahn
  • Henrik Brandle
  • Patrick Uven
  • Sebastian Hetze
  • Panos Kalorog
  • Pete Brink
  • Michael Mahoney
  • Jaylin
  • Naresh Ravuri
  • Elana Copperman
  • Steve VanderLeest
  • Qasim

Topics & Notes

Check past action items

  • Action items in github issues
  • https://github.com/elisa-tech/tsc/issues
  • AI-Paul: Discuss in OSEP WG meeting where to put the "good practices for Open Source" document
    • Discussed, but not a proposal yet
  • AI: EMQ SDV WG ideas to be added to one of next TSC meeting agenda
    • Follow up between Philipp and Jaylin during March.

Minimal Application Feature Requirement Update from LFSCS

  • update from Alessandro during TSC meeting planned

    • slides will be shared later.

    • Work entry point: https://github.com/elisa-tech/wg-lfscs/tree/main/min_prog_trace

    • Purpose: Minimal features for a minimal program.

    • Feature means Kernel subsystems

    • Not academic, but base for any use case. Systems all have own requirements, but all share to run an application.

    • So what are the minimal features to run an application is analyzed.

    • min.c is the program which starts a loop, not more.

    • When looking at unexpected function call, there is no claim on completeness. It is more on what function calls are there which are not expected from our understanding of what subsystems may be involved. Example: Random number generation (igor: used to provide a randomized offset to the logical beginning of the stack, to prevent attacks through the environment variables).

    • Combination of ftrace and ks-nav to analyze what is going on in the kernel.

    • Userspace size decreased where possible using Buildroot.

      • Userspace filesystem in initramfs to reduce block device usage

    • fork/clone syscal not analyzed. execve syscall is the core to process execution.

    • chacha_block_generic is needed as a crypto API in any system (igor: it is part of crypto, but it is used for the random offset generation mentioned above).

    • Is the removal of the crt.o realistic? Meaning, is that representative of any application?

      • Wanted to see the bare minimum program, but did not seek realistic scenario. It is the bare minimal.
      • c runtime does not have to be used in any use case. Sometimes it is rewritten or a subset of it.

    • Is the stack size larger than a single page grounds for concern from a safety perspective?

      • The application was not thought to exceed the stack(igor: actually, the surprise was that the application sometimes would start with 1 page of stack, sometimes with 2, and this behavior appeared weird and nondeterministic, till it was found out that it is intentional - see again random stack offset).
      • No unwanted swap expected (igor: this is not an issue).

    • Voided runtime linking, but a normal developer who creates application without knowing this stuff would require glibc to be in as it has runtime linker.

    • In this case swapping will not happen. There is a lot of unused space an many memory and caching available.

      • Read only memory may be dropped and not put to swap.

    • Stack is not the only part of the memory process. E.g. there is also data.

    • This is the minimal set to execute any function (not related to safety).

    • in order to have a safe system at least this has to be safe. Then you can start to thing about a real use case as a part of the system.

    • This can be the list of subsystem which could be seen as high priority for creating requirements inside the kernel.

    • Making things safe by putting them in user space is not a good argument, because these things presented will still be there.

    • Function can be found here:

    • https://github.com/elisa-tech/wg-lfscs/blob/main/min_prog_trace/min.c

      int _start() {
  int a,b,c;

  a = b + c;

  while (1);

  return a;
}

    • And https://github.com/elisa-tech/wg-lfscs/blob/main/min_prog_trace/min.large.c

    • ftrace is nice, but you need sysfs. Impact of what vfs would be enabled in a minimal configuration would be interesting to see. Kernel testing also has dependencies on sys/debugfs as well and a safety subset of tests might need other methods to allow verification with out additional kernel cfg.

    • If you fit code in a 4k page. Everything is allocated through exceptions.

      • (igor: just the first 4k (usually it's 4k) pages for code and stack are pre-allocated (and VSDO) - everything else is allocated on-demand when the processor generates a bus access and this triggers a page fault

    • Architectures have high influence on feature utilization. Some things are very different between x86 and arm.

      • Example is fixed to one architecture and to certain extend even hardware (qemu)
      • Block devices also have influence on how things are handled. SCSI can be an example here. (igor: the size of the block determines how many pages worth of data and/or code are preloaded)
      • This example is not accessing any device, so it is not SoC dependent. Other use cases will make the analysis change.

    • This is an entry point for someone who wants to work with Linux in safety applications and derive the use case from there. This will always be there, so it has to be studied in detail and start with a subset even there. Maybe not all features are needed of these subsystems.(igor: but they are enabled and present, so they cannot e just omitted from the safety analysis without a justification. Furthermore, many other features that we know are involve were not triggered, because the system happened to be in a pristine state, where e.g. page caches were already populated, and this avoided having to consider the wider effect of activating the deeper layers of the memory management)

Next ELISA WS finalization

Best practices in OSS standard

News from AGL SDV EG reference system

Optional: Short status from WGs (skipped)

Up to 3 bullet points

  • Aerospace/Space
  • Automotive
  • Medical
  • Arch
  • Linux Features
  • OSEP
  • Tools
  • Systems

AoB

Announcements

Topics for seminar series

  • To be defined: SDV seminar by EMQ to motivate the update and cloud part of HPC systems
  • RT webinar once PREEMPT_RT as last patch is mainline.🥳
  • Past webinars on website: https://elisa.tech/seminar-series/
  • Later this year:
  • ELISA user story by a company.
  • Julia Lawall about formal verification (derived from Lund Linux Con presentation)

Upcoming events

  • 14-15 May - Linaro Connect
  • 20-21 May - safe.tech by TÜV
  • 27-28 May - Lund Linux Con

Remarks

Collaborative editing: https://mensuel.framapad.org/p/elisa-tsc-minutes-a9tp?lang=en