Safety starting scope proposal

[simhein]

Introduction

To start working on the safety part of zephyr a safety scope needs to be defined in detail. This is a proposal for a minimal scope definition to start with.

Problem description

Safety cannot and will not be applicable to all components of Zephyr, therefore a specific scope must be defined in which work towards safety goals in the project can begin. While an initial scope has been defined, it is too extensive for the start, and the definition of the scope should occur in smaller iterative steps.

Proposed change

The proposal is to start with a very small scope that only includes a few basic functionalities of the RTOS. This small scope should be used to begin working with safety in the project and to gradually expand the scope as needed.

Detailed RFC

In this section of the document the target audience is the dev team. Upon
reading this section each engineer should have a rather clear picture of what
needs to be done in order to implement the described feature.

Proposed change (Detailed)

To get to the following small scope I started with the philosophers sample (samples/philosopher) because it is a classic multi-thread synchronization problem and it includes some basic functionality of a RTOS like scheduling, threads with coop priorities and preemptive priorities as well as synchronization between the threads. Another plus was that mainly kernel components are used in the sample.

After analyzing the compile_commands.json ( sample build with: west build -p auto -b native_posix samples/philosophers/) I came up with following starting scope which I propose to use in the safety working group as well as in the safety committee to start the safety work and extend it as needed.

Note: The Boxes are not in any specific order!

Plain file list:

• sched.c
• sched_priq.h
• ksched.h
• timeout_q.h
• idle.c
• thread.c
• thread.h
• thread_stack.h
• timeout.c
• errno.c
• stack.c
• mempool.c
• system_work_q.c
• kheap.c
• sem.c
• queue.c
• mem_slab.c
• mutex.c
• mailbox.c
• work.c
• timer.c
• condvar.c
• device.c
• device.h
• fatal.c
• fatal.h
• main_weak.c
• msg_q.c
• version.c
• version.h
• init.c
• init.h
• banner.c
• kernel.h
• kernel_internal.h
• kernel_structs.h
• kernel_version.h
• kswap.h
• wait_q.h

The proposed scope and file list is far from completeness but it should be the starting point for further action points like:

• Analysis of unnecessary dependencies and includes between configurations
• Requirements
• Coding guidelines

Another point in favor of the minimal and extensible approach is that architecture diagrams needed can be create in parallel with the dependency analysis.

Concerns and Unresolved Questions

Shall be discussed in this Proposal

[tobiaskaestner]

This sounds like a very sensible approach to me and I like it very much.

@simhein I came to similar results when doing pretty much the same exercise. Actually I stepped down even further and used the minimal project as the starting point based on the assumption that every other config of Zephyr would always include these files ... if you enable multithreading and timers in the minimal example the list comes out roughly the same though. Now I am wondering if by actually adding some more Kconfig options to exclude some IPC mechanisms would reduce the effort for the initial analysis in a helpful way. Mailboxes and Cond Vars come to mind as many applications could be written without... and probably it also makes sense to start with one scheduling algorithm (the simplest, i.e. the dumb) and rather state explicitly the assumption of some upper bound on the number of threads or whatever ... Sure this would put strong design constraints on downstream projects but it would still be light years ahead of other offerings. And it creates incentives if later people have a desire to relax these constraints even more so when there is a proven to work process in place.

On the inclusion of unnecessary files we did a PoC on using google's Include-What-You-Use tool to get the headers straight (turns out there are a couple of circular includes). If that's of interest we can share how far we got and what could be done next.

[simhein]

@tobiaskaestner Thanks for the reply and also good to know that I am not that far off with my analysis If someone came to the almost same conclusion.

On the inclusion of unnecessary files we did a PoC on using google's Include-What-You-Use tool to get the headers straight (turns out there are a couple of circular includes). If that's of interest we can share how far we got and what could be done next.

That would have been the next step to figure out the unnecessary inclusion of files in this minimal scope. It would be great if you could share how far you got with that and maybe what problems you faced.

[nashif]

@simhein it would be much easier if we could just mark complete folders and subsystems as part of the scope, i.e. 'kernel/' and figure out what belongs there and what not based on analysis and optimize for self-contained scope. Doing this this based on files is going to be very low level and very "dynamic"

[tobiaskaestner]

@simhein We did run Include-What-You-Use against one of our downstream projects not yet including the zephyr upstream code base. The biggest problems we were running into were

• the tool needs clang, so whatever arch/board you have in mind it needs to be supported by clang
• KConfig is a challenge if tokens conditionally include other files etc.
• last but not least there are some inconsistencies in the use of #include <> vs. #include "" , the tool assumes the former to be includeded via -isystem and the latter to be included via "" which often is not the case

That all said, I think adding the tool to the static code analysis suite is both doable and a wortwhile addition

[tobiaskaestner]

@nashif that seems the right thing to do but also quite ambitious. Just inside the kernel folder there a several IPC primitives, at least three different scheduling algorithms (not including the no-multithreading option) and three different waitq algorithms, too. All these things naturally fit into the kernel folder and would need to be covered at once. That seems a lot of effort to me before something useful would come out of it that could be tested for suitability by a first downstream project.

IMHO, the narrower the initial scope the sooner real feedback could be obtained on the overall process.

[nashif]

@nashif that seems the right thing to do but also quite ambitious.

I think this is far less ambitous than having to disect the kernel and pick/choose micro features to be part of some scope that would need to be isolated to the unit level and verified/tested at that level. In other words, a reimplementation of the kernel or any other subsystem we treat the same way.

[tobiaskaestner]

Not sure I managed to convey my actual intent. I wasn't proposing to treat some parts inside kernel within scope and others not. I was referring to initial scope, i.e. what particular configuration should be taken as the baseline for the safety case to generate the first content for. Also, @simhein lists is pretty much the content of the kernel folder anyways. My point is that compiling the safety case for a single configuration is already big effort (that's what most (if not all) commercial vendors offer), multiple configurations don't make things simpler for sure and incorporating the entire KConfig (micro)feature system is a complete different thing again.

[simhein]

@simhein it would be much easier if we could just mark complete folders and subsystems as part of the scope, i.e. 'kernel/' and figure out what belongs there and what not based on analysis and optimize for self-contained scope. Doing this this based on files is going to be very low level and very "dynamic"

I was thinking about the same approach as I looked at the file list a second time. As @tobiaskaestner mentioned my initial file-list is nearly the kernel and I did a diff to my actual list. The conclusion is that if we add following files to the initial scope :

• atomic_c.c
• compiler_stack_protect.c
• events.c
• futex.c
• gen_offset.h
• kernel_arch_interface.h
• kernel_offsets.h
• kernel_tls.h
• mem_domain.c
• mmu.c
• mmu.h
• offsets_short.h
• pipes.c
• poll.c
• smp.c
• statistics.c
• usage.c
• userspace_handler.c
• userspace.c
• xip.c

we could say starting scope is the folder kernel/* and I'm totally fine with that.

I was referring to initial scope, i.e. what particular configuration should be taken as the baseline for the safety case to generate the first content for. Also, @simhein lists is pretty much the content of the kernel folder anyways. My point is that compiling the safety case for a single configuration is already big effort (that's what most (if not all) commercial vendors offer), multiple configurations don't make things simpler for sure and incorporating the entire KConfig (micro)feature system is a complete different thing again

I feel like this approach fits more to the further action point: "Analysis of unnecessary dependencies and includes between configurations" where such a safety case could be tried to be compiled within this starting scope. Or do we have different understanding of scope?
Because what we also try with this scope, to start working on the quality goals like coverage and coding guidleines and requirements and in this case limiting the scope to a specific configuration would be unfavorable.

[simhein]

@tobiaskaestner any thoughts on my last comment part?