Skip to content

Minutes 25 Apr 2024

Jump to bottom
Paul Albertella edited this page Apr 25, 2024 · 2 revisions

Host: Paul Albertella

Participants: Florian Wuehr, Igor Stoppa, Pete Brink, Sebastian Hetze, Daniel Weingaertner, Mikel Azkarate, Oscar Slotosch, Michael Armbruster

Agenda

  • "Overall engineering approach" and next steps

Discussion

Need for a workflow / collaboration arrangements between working groups discussed in TSC

  • Raised by LFSCS group - should OSEP be defining AOUs, risks, etc to inform WGs?

Igor: Define a problem and assumed context, then feed this to other WGs as inputs

  • Pete: Is documenting the complete context always necessary?
  • Igor: Needs to be some understanding of the architecture under consideration, and the understanding that informed the analysis

Sebastian: Spoke to Alessandro - he wanted some inputs as to what his WG should be investigating in terms of specific Linux features

https://github.com/elisa-tech/wg-osep/wiki/Process-for-ELISA-working-group-activities

  • This is a general guide to what to record / consider when undertaking a ‘study’ activity
  • Could OSEP give an example of what this looks like?
  • This might also give us the opportunity to illustrate how Igor’s checklists, etc can inform

Igor: Have previously discussed using the userspace corruption example to do this

  • Many different ways to prevent / mitigate this e.g. don’t include the ‘broken’ kernel or device driver in the first place
  • But: nature of Linux means that we can’t easily guarantee bug-free, comprehensively tested
  • Can however understand the possible types of interference that bugs can cause and how the kernel design might evolve to prevent or mitigate these

Igor: Suggest that we focus on the problems in OSEP, let the Architecture group to identify which components are involved and LFSCS explore the kernel features

Paul: My concern is that having an expectation of work flowing between workgroups, with a sense of dependency, may not fit with how ELISA is constituted

Sebastian: Suggest that we discuss this in the workshop to work out what a working pattern

Paul: Suggest that we move forward with Igor’s suggested topic;

  • ACTION Igor to send the details to the OSEP WG mailing list

Igor: Another topic for future discussion: You don’t even need a ‘bug’ or fault per se in a component in order for interference to result in a critical function - this understanding is an important consideration when devising testing strategies, and why fault injection is arguably a necessary strategy in this context

  • Have a specific example of this that can share
Clone this wiki locally