Verifying Application Startup on Linux
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 62 | |
| Author | ||
| License | CC Attribution 4.0 International: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/59705 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
| |
| Keywords |
00:00
FreewareOpen sourceData storage deviceSoftwareCNNCASE <Informatik>SoftwareContext awarenessCartesian coordinate systemFront and back endsFunctional (mathematics)CASE <Informatik>BitSinguläres IntegralSlide ruleWordExpert systemLecture/Conference
02:17
ImplementationFunctional (mathematics)Normal (geometry)Fraction (mathematics)Different (Kate Ryan album)Standard deviationImplementationWordWave packetPlanningInheritance (object-oriented programming)Computer animation
03:28
System programmingOpen sourceFreewareMathematical analysisNormal (geometry)Different (Kate Ryan album)GradientControl flowFunctional (mathematics)BitLevel (video gaming)Frame problemInformation securityPhysical systemForm (programming)SubsetMereologyNeuroinformatikMedical imagingMultiplication signRight anglePattern languageBinary codeComputer hardwareCartesian coordinate systemDifferential (mechanical device)Arithmetic meanMathematical analysisWordBuildingMappingComputer animation
06:57
Demo (music)FingerprintReading (process)FreewareComputer programmingSystem callCASE <Informatik>Computer animation
07:48
Demo (music)WritingSicSet (mathematics)Process (computing)BitSemiconductor memoryDiagramComputer programmingEqualiser (mathematics)Singuläres IntegralFerry CorstenSpacetimeBinary codeStandard deviationSource codeProgram flowchart
08:40
Control flowLinker (computing)Binary codeStructural loadMultiplication signCodeParameter (computer programming)Functional (mathematics)Binary filePerspective (visual)Integrated development environmentCASE <Informatik>SpacetimeBitLink (knot theory)BootingLinker (computing)XMLProgram flowchartMeeting/Interview
09:53
Dynamical systemControl flowSheaf (mathematics)Linker (computing)Vector spaceVariable (mathematics)Stack (abstract data type)Binary fileData integritySheaf (mathematics)Cartesian coordinate systemMultiplication signLibrary (computing)Point (geometry)AreaSymbol tableINTEGRALLecture/ConferenceMeeting/Interview
10:54
Binary fileData integrityStack (abstract data type)Variable (mathematics)Vector spaceState of matterSpacetimeInformation securityData structureCartesian coordinate systemView (database)Semiconductor memoryTask (computing)Point (geometry)Computer animation
12:13
Stack (abstract data type)Binary fileData integrityVector spaceVariable (mathematics)Point (geometry)Integrated development environmentCartesian coordinate systemComputer programmingInitial value problemParameter (computer programming)Variable (mathematics)Computer animationLecture/Conference
13:15
Data integrityBinary fileStack (abstract data type)Vector spaceVariable (mathematics)Physical systemCartesian coordinate systemDifferential (mechanical device)Computer animation
14:11
Binary fileFocus (optics)Data integrityFreewareSheaf (mathematics)EmailDemo (music)Point (geometry)Focus (optics)Cartesian coordinate systemMultiplication signCodeFigurate numberDiagramBinary code
16:17
Demo (music)Game theoryWritingSet (mathematics)Reading (process)Structural loadFlagEmailBitComputer programmingDifferent (Kate Ryan album)File formatExistenceSource code
17:10
Open sourceFreewareRevision controlBinary codeComputer programmingEmailBoilerplate (text)Computer architectureInformationMeeting/Interview
17:54
Interpreter (computing)FlagGEDCOMDemo (music)World Wide Web ConsortiumDifferent (Kate Ryan album)Cartesian coordinate systemBitInformationSemiconductor memoryType theoryStructural loadEmailComputer programmingCompilerInterpreter (computing)
18:45
Sheaf (mathematics)MereologyMappingCompilerFinite-state machineStructural loadNormal (geometry)1 (number)InformationBitCodeSource code
19:47
Demo (music)Sheaf (mathematics)Sheaf (mathematics)Cartesian coordinate systemFile formatCodeInformationSemiconductor memoryDifferent (Kate Ryan album)
20:42
Demo (music)InfinityBitSheaf (mathematics)Computer programmingInterpreter (computing)EmailFunction (mathematics)Letterpress printingBinary codeInformationLibrary (computing)Singuläres IntegralHexagonCore dumpElectronic mailing listLecture/Conference
22:03
EmailSheaf (mathematics)Demo (music)CodeSinguläres IntegralData integrityBinary fileFormal verificationSemiconductor memoryCartesian coordinate systemBinary codeTable (information)EmailSheaf (mathematics)View (database)Computer programmingPhysical systemCodeCASE <Informatik>UsabilityMultiplication signBitState of matterSystem callSinguläres IntegralGraphics tabletComputer animation
24:36
EmailSheaf (mathematics)Singuläres IntegralCodeData integrityBinary fileFormal verificationSemiconductor memorySpecial unitary groupHill differential equationMathematical analysisLink (knot theory)INTEGRALMultiplication signGame controllerCartesian coordinate systemSinguläres IntegralInterpreter (computing)Correspondence (mathematics)Semiconductor memorySheaf (mathematics)Structural loadLibrary (computing)SummierbarkeitCondition numberBinary codeEmailMatching (graph theory)NumberPrice indexTable (information)Bit
28:53
Data integrityBinary fileLink (knot theory)EmailMathematical analysisGame controllerPoint (geometry)Cartesian coordinate systemSoftwareProcess (computing)BitLibrary (computing)Functional (mathematics)EmailSpacetimeFilm editingComputer animation
30:42
Point (geometry)Mathematical analysisGame controllerSoftware bugVideo gameBookmark (World Wide Web)Patch (Unix)SpacetimeBitSinguläres IntegralForm (programming)Validity (statistics)Reduction of orderEmailElectronic mailing listFunctional (mathematics)Cartesian coordinate systemMathematical analysisCodeComputer animation
32:09
Patch (Unix)SpacetimeBookmark (World Wide Web)Power (physics)Binary codeNormal (geometry)Sinc functionLipschitz-StetigkeitRight anglePhysical systemImplementationCompilation albumMappingDifferent (Kate Ryan album)Function (mathematics)Validity (statistics)EllipseSheaf (mathematics)InformationMultiplication signError messageStructural loadComplex numberAlgorithmFormal verificationSoftware testingBitCompilerSoftwareMoment (mathematics)Scaling (geometry)Semiconductor memoryFormal languageConstraint (mathematics)Standard deviationShooting methodMedical imagingSoftware developerCartesian coordinate systemMeeting/Interview
39:48
Witt algebraVideo gameCodeMoment (mathematics)Server (computing)BitMultiplication signPatch (Unix)Venn diagramLetterpress printing1 (number)WordState of matterFunctional (mathematics)Disk read-and-write headSoftware developerLine (geometry)Latent heatMathematical analysisInformation securitySoftwareDirection (geometry)Different (Kate Ryan album)Level (video gaming)Software testingElectronic signatureFormal grammarSlide ruleForm (programming)Singuläres IntegralStandard deviationCASE <Informatik>Binary codePublic key certificateCartesian coordinate systemBoss CorporationMereologyGame controllerMeeting/Interview
47:05
Meeting/InterviewJSONXMLUML
Transcript: English(auto-generated)
00:07
Hello everyone We'll start with the usual slide of who are we and what do we do?
00:22
We are Stefan Richards and making fun such words or as some people from the CCC context might know me tofu and Both of us are functional safety engineers in software with some background in Linux and Linux kernel And we work for Amlix
00:41
Which I think is hard to miss around here in the moon Who works in embedded Linux Linux BSPs and and? Linux around safety contexts With emphasis in cutting on Berlin and everywhere remote This talk in particular and the work that we're presenting in this talk
01:03
Has been created with our partner electro bit and we have experts in automotive safety and automotive software and Have worked with us on that and all of this is happening in a context of Embedded industrial and use cases so for those of you who work on maybe more
01:22
webby things or front-end II things what we mean with embedded industrial use cases and We think about all these Beautiful nice things and that might need or want Linux on them and can benefit from The possibilities of that and but have some more stringent
01:42
Requirements as to how you use Linux in that then you might do with and other bits of software So back to the topic of today's talk How can we start an application under Linux safely? and
02:01
For us the first question is and when I say safely What even is going wrong? but what what am I thinking about when I say what goes wrong and why do we even worry about that and Then bigger question. What do I even mean by safely because I think if we survey all of you about? What means safety and safely and we get very different answers across the board?
02:25
So when we talk about safety we come on along with the beautiful word of functional safety as Wikipedia defines freedom functional safety is freedom from unacceptable risk of physical injury or damage to health of people by the proper implementation of one or more automatic protection functions and
02:46
Because everyone would still understand something differently. There's a whole lot of different standards that Define a whole lot of things That you can do to mitigate your risk and think about risk and even assess your risk So the parent norm being the IC 61 508
03:04
Which is a more general norm and there's a whole lot of norms that roughly follow the six one five or eight for different industry standards the 26 262 or 262 62 depending on who you ask and being the car norm and then there's medical norms and then
03:22
Trains and planes I think And Then I think another very important bit when talking about functional safety is differentiating functional safety from other bits of safety and which I think often get mixed in and
03:41
Need a bit of differentiation. So when we talk about functional safety that doesn't mean that we solely think about things like security and particularly if you German speakers Pretty much all of this maps to the same German word and makes it hard sometimes to differentiate these so
04:01
Safety has different aspects security with the malicious and tenders one part of it but for us in functional safety that's a whole different thing because I'm thinking about much more things than malicious intent to my system and thinking about All the other things that could go wrong. There's my hardware die
04:21
Does a meteor hit my hardware maybe risk assessment not so likely. I don't care about Mater rights and then with the functional safety a lot of that works with repeating patterns of things Processes that we follow and the very central bit which we've come back to again and again is that we think about analysis
04:44
We analyze what is our risk we think about do we mitigate that or do we not mitigate it because the risk is is Acceptable we reduce our risk repeat and eventually we're happy and get the magical seal of approval
05:00
and With the whole thinking about risk Another important bit is there's different levels of acceptable risk Which most of you might have seen in some form or another with probabilities and assessments Over how much risk is tolerable over my risk and
05:22
Which gets you into certain? Gradings all the norms have their own gradings and in car norms that might be a so levels and I see norms That's just still levels And then you have to do more or less of those repeating patterns to mitigate more and more risk
05:40
So with that out of the way, let's get back to something more slightly more concrete and Now we've talked about safely but there's still a lot of uncertainty in how I can start an application on the Linux safely because where the hell the starting start and where the starting end and What even happens during starting and say?
06:03
For me as a functional safety engineer starting isn't I hit enter on my computer and it starts But there's a whole lot more that can happen before that has the engineer put in the right binary into my image Has I don't know the engineer Then other things or did the build system break all of those things fall into that
06:24
We won't go into detail of all of that as you can imagine that will break a lot of time frames with this but I just wanted to raise that there's a lot a lot of things to think about and there's a lot wider scope to think about then and one would first imagine when starting to think about that and
06:45
Before we look deeper into all of that Let's have a look at a very simple application that we want to dive in a bit deeper and and take that apart which There awesome, so we've built ourselves a very
07:04
simple program similar to something that most of us have seen I think before and We want to Compile a little program and then and we can throw an s-trace at that
07:23
Little program And then see a whole lot of syscalls And things that happen
07:41
And what I want to focus on and what we're going to look at and dive in now Is that we start with a nice call of xe which is a syscall that we use in that case to start our process and That will guide us through the further bits of what we're doing here, so
08:00
now we've got a process we want to start something and We enter the Linux kernel and have this beautiful diagram Which we don't think like we never expected that to be readable from the audience There's a whole lot going on we enter here our user space exit the e-call we go into a kernel space We dive in here and then down here
08:22
We have a whole sub bit where we load our actual binary and the whole things start here and so we simplified that a bit for Readability as a standard engineering practice we enter we allocate our binary program struct and M structs for the memories layout allocating different kernel memory bits and
08:47
Look at arguments environment Have initialized our struct here search for matching binary format load the binary return Execute startup code and go back or start executing the main, so there's a lot of stuff going on and
09:06
Again in the interest of time We could spend hours and hours talking about how we think from a functional safety perspective about all of these things and what can go wrong But that's not I think Useful feasible for today's talk so we're focusing on smaller bits and
09:25
before we look at smaller bits and That bit I wanted to quickly talk about a bit further so Back in the user space we also have some things to do as most of you might have seen We can either study link or dynamically link and then
09:42
If we've statically linked there's not a whole lot going on But if we have dynamically linked which will become important in a second we either use Our linker loader that's defined in the interp section and in the case of elf That's usually the LDS o and and then with the LDS o we can find and load shared libraries
10:02
Once we've done that we hand over to the underscore start section At the start symbol in the text section, and then we can enter main So now that we've defined all that and have a quick overview of what's going on More or less and we can start thinking about what's actually gonna go wrong, maybe
10:24
Which is where I hand over to Steph Hello so I'm gonna start trying to bring these two worlds together a little bit and So What are the problem areas that we can identify in the application startup?
10:44
So perhaps the first point is quite an important one. It's the integrity of the binary data and What this means is binary data we put in at compile time We want to make sure that when we get to load time. It's the same data. It's not become corrupted in some way or
11:02
From a security point of view you could save someone's maliciously changed it, but we're thinking about Kind of corruption not use malicious intent here Other problems that Could occur is we have these structures that we've loaded Initialized put values in either from the system or from the binary we're loading
11:25
We're setting up like the memory struct so that we know what the memory space is going to look like if that doesn't Get initialized properly then when the application is running we might have some problems So and the same with the task truck describing the actual
11:41
tasks in the application Yeah, so there's a bunch of things in memory and also the stack and registers initialization that we need to Think about like if there's something goes wrong, and if this doesn't get initialized how we expect it to
12:02
Then we have an undefined state in our application once it started so We're going through this idea of analyzing. What's a problem that could happen in the application startup and Once we've gone through the rest of the points here, we'll get to okay thinking about mitigations and
12:23
So we also could zero out our initial values so some of you might know when you load an application You might have some Uninitialized static data that you want to load up and You don't want this to just be random data because perhaps sometimes one in a million actually looks like
12:43
Real proper data and your program goes oh, I'm gonna use that because it's nice, and it turns out that it's not nice and undefined state or So we want to make sure we zero out every value that we don't trust or we don't know what it should be at the start And then data handover, so this is when you run an application
13:05
On the command line say you know you pass in some variables or some arguments and also it passes in a whole hope Whole bunch of environment variables and Those somehow go through the kernel and end up in your application and But we don't want someone coming and I don't know
13:23
Passing in malicious variables, and we also don't want them getting corrupted unmaliciously and so these are all the things we're thinking is What values could end up causing undefined behavior in our application? and How can we yeah mitigate these problems and the last one is slightly different and
13:47
So this is differentiate safe applications from non safe applications Yeah, this is perhaps saying We have a system where there's certain applications. We care about starting safely, so we want to actually verify
14:04
mitigate these problems we've talked about and then there's some applications that we don't care how they start and We don't worry about the safety with them. We do worry about whether they're allowed to run or not on our system But we don't have to verify their starting because they're not safety critical
14:22
So we can also say how do we think about the problem of differentiating? safe applications from non safe applications So what we're going to do in this talk is just focus on two of these points so this safe versus non safe because
14:42
Without being able to differentiate safe versus non safe. You could say oh, okay. Let's check everything Let's pretend everything is safe, and so we have to verify every application we start But we say it's nice to also have non safe applications running and Then the other point that we'll focus on is this binary data
15:04
hasn't become corrupted between build time and actually loading it into memory and Because yeah, we don't just want some undefined code perhaps or undefined data being used once you start your application
15:20
But in the interest of safety we would have to go back and look at all the other problems and Figure out whether they also need some mitigations and then provide those mitigations to reduce the risk of problems caused Yeah, so this isn't a full example of a solution, but this is What we have time for today to talk about
15:45
Yeah, so What we've seen so far is well we've seen roughly how an application that started on Linux But we haven't seen what an application looks like so you get given a binary
16:01
Probably you've heard of the elf binary format, but maybe you've not looked more deeply into it and So we have this nice diagram which Does kind of explain it, but I found it confusing when I first saw it so what I found easier was to actually
16:20
Take a program and pull it apart a little bit with Some nice tools that you get So we can use This read off tool and Read-off allows us to look at Well, it has a bunch of different things it does, but what we're going to use it for is just looking
16:41
What's actually in our binary and? What kind of things like Exist here, so we can see that this is got long addresses. It's a 64-bit binary perhaps starting at the top It tells us that we have 13 program headers. What does that mean?
17:05
So program headers are also called segments in the elf format and They start at an offset of 64 So they're not the first thing we find the first thing you'd find in an elf binary is the elf binary header which tells us and
17:21
Let's say less interesting information for this talk and just kind of what version of elf you running What's the architecture so it would say it's being compiled for 64-bit and other? boilerplate kind of information And then the next interesting header we get to is the program header table, which tells us about segments and
17:43
Then you can see here. We have program headers, so it's told us where's my mouse gone I Scroll so we have Is that how where did you put that?
18:01
okay, so It tells us about the different program headers We have it tells us where they are in the memory of the binary perhaps where we want to locate them when we load it and Other information which we won't go into here and but on this side quite interesting we have different keywords So load it's kind of self-explanatory. It's going to want to be loaded
18:24
Interrup is an interesting one which will come to you in a bit But that contains the information about which interpreter to use when we're starting our application and then there's a few other types of segment that we can have Note is just comments that the compiler can put in there
18:45
information and yeah But the ones that are interesting for us really are load and the interrup and Then we come down here to more information. So this is the section two segments mapping Now unfortunately segments and sections sound similar. It sounds like you could just interchange these words, but
19:04
They have two quite distinct meanings and as you can see here on the left We have the segments so 0 to 12 We have a 13 segments like we found before and then they have in each segment 0 or more
19:20
sections and and anyone who's programmed in C for a while might recognize things like text and BSS is here data and so code initialization data and Yeah, like normal stuff you'd expect to find and then also other
19:41
bits of information perhaps coming from compiler or from other parts of the system, which we won't go into but and Then you can if you remember From above we also had this interrup segment and there's also an interrup section Which
20:01
Is going to be interesting for us when we start looking at what happens when we try and dynamically link our application on startup So That's just to show you that there's yeah there's quite a lot of information going on and the way the L format kind of represents it is With these two different views, but it's important to note that it's actually the same binary data. It's just
20:26
segments are telling us Here's our chunks and these are actually the things that get loaded into memory and and sections are More related to the code or perhaps like the data or things that are going to get run by the
20:43
When we run the program And then one last command To get a bit more information out. I said this interrup section is interesting to us so we can use ob stump to actually just have a look
21:00
What's in this interrup section? For anyone interested, the J allows us to specify a section and the S just says print the whole section that I asked for And when we run this command we see a nice hex dump into the binary information But we also see a nice ASCII output of this
21:21
Interpreter that our binary is asking for so when it starts Goes through the whole kernel information and one of the last things it does in the kernel is say Oh, you want an interpreter you're dynamically linked when you return back to userspace it then goes to this path and says Please mr.. Interpreter find me my libraries that I need
21:42
So and perhaps also interesting to note is we say which interpreter we want to load the shared libraries We don't say the shared libraries themselves. We don't have a list of I don't know six different shared libraries that we want to load We allow the interpreter to figure that out for us
22:01
So yeah now back to this diagram, so we have the elf header at the start And then we have the associated program header table and section header table Pointing to the same information, but it just has two different views and is used slightly differently when we're loading our application
22:21
So now we know how? Roughly an application starts and also how an application binary looks We can start thinking about how to mitigate the problems that we identified and So Introducing our idea of an a salute our idea of a solution safe application startup its application startup made safe, yeah, and
22:47
If I accidentally call it is up to Because that's quite a long title so you know It was up soon save application startup, but the same thing and So what we can do is we can to mitigate these problems that we've identified
23:04
We can add some extra code into the kernel. We can also modify our off binaries a little bit build time so It allows us to actually build in kernel mitigations and to Oh, yeah, I wanted to say solve these problems, but we're not we're not trying to solve the problem of corruption
23:25
Application startup, we're just trying to detect application startup corruption, and then we can react in some way when we detect that and Then we're yeah to take it back to the safety world When we've detected it we can do something which then reduces the risk and and yeah, perhaps stops the system
23:43
Perhaps I didn't warn someone that something bad has happened and Yeah, so The first problem we had was how do we tell when we want to actually start an application safely and verify what happens against When do we not care when is it a non-safe application it can start how it wants and perhaps end up in an undefined state
24:06
And we also have this third case and which we didn't talk about before which is I don't know what this application is It's a forbidden application. We'll call it. It shouldn't be running on our system. We didn't put it there We don't know where it came from
24:21
and so the way we mark an application as safe versus non-safe is We can add a little marker in the elf header. It has a nice bit of unused padding which we can just add For example a four byte marker And we say if it has this specific value. It's a safe application. We know what's in there
24:42
We've compiled it under special conditions that are controlled by us We're happy for it to be started on our system, and it should be verified as a safe application while starting We can also say We can control non-safe applications at build time They don't need to be started safely, but they should have a marker that says it's non-safe
25:03
So it's still okay to run on the system And so we can write in there a safety marker a corresponding non-safety marker and then anything that doesn't have one of these two values We it's either become corrupted or Yeah, it shouldn't be on there in the first place And so it can be detected once the application is starting
25:24
It doesn't have a value that we trust and yeah, we can react in some way Now We add this safety marker to the binary that we want to run But we also have to add a corresponding safety marker and do
25:41
Corresponding controls on the interpreter that gets used because it doesn't make sense to start an application safely and Verify what's happening during the startup if the interpreter can do whatever it wants. So we also have to add a Corresponding control to the interpreter and likewise the shared libraries that might get loaded by
26:01
An application that we want to start safely as well So Yeah as a solution to the problem of starting application safely and how do we know whether we need to or not? We have the safety marker To the other problem that we had and how do we check the integrity of the binary data?
26:24
We Can add you can't really read it, but we've added our own section also in its own segment, but Which has check sums of all the other segments So a compile time what you can do is for each segment that you put into your binary
26:41
Take a CRC 32 or some other checksum over this data Add it in here. So yeah, we have the checksums over all of this and We add this segment section Into the corresponding tables as well
27:01
And then we add an extra bit into the kernel at load time Which will check that? When we're loading these segments We do the checksum again check it against the checksum that we have In the binary itself and make sure they match if they don't match for some reason then we can react again
27:23
So we know that yeah The data that we've loaded into the memory is the same as the data that was put there at compile time And you might say well what happens if one of the segments disappears? then Because we have a certain number of checksums. We also expect a certain number of segments and
27:44
So if those don't match then we can react and something in the header has become corrupted in some way which affects Like how the application is even going to be loaded and so it doesn't load The segments properly then we will see that as well because it's we're expecting a certain
28:01
match between the segments and the checksums and So it's quite nice. It gives us a Good indication that actually the data has been loaded correctly and it hasn't Hasn't become corrupt somehow or change somehow uncontrolled between compile time and actually loading it into memory and
28:21
And so we say yeah safe application startup mitigates these two problems by doing these two things and Obviously for a full solution, you'd have to go back through the other problems Create corresponding mitigations to each of those as well. And But now perhaps we ask the question
28:42
Does Pzapsu solve our original problem or our original problems? So Yeah, I think I already mentioned it but safe is a non-safe if the mark is corrupt So it's not safe or a non-safe marker. Then we can react if the shared libraries aren't marked correctly. We can also react
29:02
Yeah, if the checksums don't match or if the header comes corrupt and then has a different idea about how many segments we might Have then we can react in some way and Yeah There's a whole nother talk probably about how to react to these things and what you should do
29:20
When you detect problems like this, but again, we won't go into it here So, how do we link this back to functional safety so we've kind of gone through this Very cut down idea of what we do as functional safety engineers we analyze the problem space we say
29:41
How is an application starting? What could possibly go wrong when we're starting it? Which problems do we actually need to mitigate like do we really care if I don't know something completely unrelated to application startup happens probably not but once we have identified the risks that we want to mitigate we provide these mitigations and
30:02
Reduce our risk and then at some point we're happy with the solutions that we have and Yeah At that point I think I hand over back to tofu Thank you so Where does that leave us?
30:20
Now that we've gone through that process on the smaller example cut down our bits and What was it that we wanted to? Look at with this whole ordeal We wanted to Have a peek at functional safety because we think that's not that well integrated in a lot of first practice software mindset
30:43
And I reckon if we rock up with these patches that we've written for that to the kernel mailing list We will get asked for say an exploit or a life bug And then we say oh, we've done a lot of risk mitigation thinking these are all problems that we can think about But it's not a valid thing until I've written an exploit for it
31:03
so we want to start the discussion around that a bit and and look at that and maybe raise awareness of that a bit and the other thing is that we want to start looking at can we bring functional safety in Linux together because we think that's a very exciting and path to take towards And we've then also looked at a more concrete bit
31:22
What does application start when the Linux do and so maybe some of you? Not seen all of those bits of code and paths along the execution we've Brought along our favorite bit of analysis mitigation risk reduction and repeat which we can only repeat and repeat over and over again
31:41
and then maybe that gets us at the end to some form of Risk that we can control and then we end up with our magical to seal of approval Because that's what safety engineers care about a lot and then last bit as you can imagine this is only a small bit that we're starting with and
32:02
Because there's a whole topic and a whole wide thing that you can think about Once you you move into that space with Linux and a lot more patches to write and a lot more things to do and so there's a lot more talks to come I think in that space and patches and work and
32:20
with that I Am for questions and and I'll hand any question over to our two favorite colleagues Norbert and power Questions
32:55
So yeah, I think the reason is just simply that you can have end to end
33:01
mapping between segments and sections So I think it's the same. It's just the same information used in two different places and because Yeah, I Sorry, yeah, I think so
33:27
I Mean ellipses topic just as wide as the carnal is if you're thinking about that and
33:41
There's a whole lot more things to think about what can go wrong in a lip see and It's also That you are in the same memory space and as you are with your lip see as the application itself So that ends up changing your way of thinking a lot
34:09
Yeah, you can come over and waddle to the stand and we can sit down and talk about lip see bits of it because yeah anything I can try now to put into This is what I'm doing with lip see and we're just not doing justice for thinking about the scale of that
34:27
Any more questions
34:54
Yes in Any language you feel like and the IEC talks about some languages it likes and it doesn't like and
35:03
C and C++ without any constraints. It doesn't like for example unless you've put some constraints that you don't shoot yourself in the foot for obvious reasons, so and And the standards aren't that quick in picking up new developments Rusk is certainly very interesting thing to look at in that space because it does a lot of things and
35:23
But and here's the big but and You have to think about all of these things not just for your online tools So the things that go into your image that go into your application, but also some offline tooling Why do I know that my compiler outputs the right binary and since C has been around for a few years and
35:41
people have built and written and qualified and thought about risks of C compilers so I can easily go out there and Maybe buy a GCC or Something like that for C with rust being that new I'm not aware that someone's qualified a rust compiler and
36:02
So while rust is very exciting, I mean Not particularly keen at the moment on sitting down and writing a whole lot of this risk assessment for rust Compilers and the whole see rust standard lip which has the exactly same problem where I There is people out there who have qualified lip C's
36:26
Yeah I mean in principle you're free to put that into a compiler and but then
36:49
That means if you've bought a compiler, then you have to really think about the risk of your compiler. So Is
37:01
Probably the more cost-effective way of approaching that But then that gets you about thinking what can go wrong between my compiler and putting the checksums in there and then I want to think about I've run a whole lot of tests maybe big test systems and And really I want to only put the checksums in the market in there
37:21
once I've run the tests so that I know that the thing that's got tested is is The thing that has been used because if I put it in there before and then the tests go wrong and I know this this thing's Not not fit for service, then I've still got a binary that has valid checksums and markers So there's a whole lot of engineering going into what the IC norm calls the offline tooling bits around
37:43
Verification and risk mitigations around that where you have to think about what goes wrong in my testing system what goes wrong in my build system, and how can I make sure that there's Even some things like reproducibility or something like that when I think about that because yeah again, that's
38:01
Topics for five talks in that and as to how I think about build systems and what goes in there And feel free to want to pass the stand and ask more questions Yeah, just to add just one quick thing and a nice thing to think about with that as well as Having diversity in the checksum
38:23
Algorithms that you use so perhaps you might use a different Implementation to put the checksum in the binary in the first place then you use to recalculate over the binary at load time Because one thing you have to think about is systematic errors if you use the same checksum Algorithm implementation that has the same systematic errors it might tell you oh, yeah
38:44
Everything looks good because it's put the error there, and then it's missed it when it's recalculated So you can also Let's say reduce more risk by thinking about well. Can we use diverse solutions and Yeah Hopefully, that's also interesting. I don't know any more questions
39:07
Yes, the IC norm
39:36
Differentiates between pre-existing and newly created software bits, so the IC does
39:42
think about those things and Depending on how safety-critical your bit of software is there's a whole bits of things that you can do fringing from writing a specification for the whole thing yourself and then testing it to death and towards doing a whole lot of more formalized
40:02
risk analysis bits and then mitigating for bits and and maybe not even caring about what the software itself does if I just wrap it or if I just Put in enough diversity, maybe even By doing the same thing twice with different software bits, then that helps me
40:23
But in the end with the pre-existing bits of software you still will have to think a lot about the risk and Specifying certain bits of behavior that you expect because you unless you've written yourself a nice specification Then you're going to have a hard time differentiating from what's going wrong to what's going right and then
40:42
From that you can think about is it worth writing a test or is it worth mitigating that life or mitigating it other ways Yeah, does that give you I think if you want to run
41:06
Software that is not under your control at all under a zill level style thingy Then you're going to have a hard time convincing a tough assessor in pretty much all case If I have a binary that I have no clue what's inside it no standard and no specification
41:21
then I wouldn't trust my life to that and if I Like they know that someone else has done the same rigor and in thinking about that. So yeah, then by that time you can just either start writing tests on your own and but you're not going to get I think very far with a
41:41
full certification of that Yep, any more questions? Yes
42:00
So I think if we think about that we've broken the elf standard by changing our binary That implies that we've modified the kernel. There's some patches that need application to that kernel. And so it's not a mainline vanilla kernel and when we add those and and
42:20
Obviously You're not done when starting an application There's a whole lot of more things to think about than just a little bit that we've shown you there So there's a whole lot of more patches that you need for that to think about and one of those patches is thinking about how do I? handle when something goes wrong and what do I do with that and do I email my boss or
42:43
Whatever, you know print a warning with the cup server that I'm running which is certainly very safe to run but Yeah, there's Yeah, I think there's a talk to come when we go into more detail and again
43:02
We can I think talk endlessly about how do I mitigate things that go wrong during the life system? And a lot of the things won't end in emailing your boss, but it starts adding up
43:24
obviously and and And Since as I've started with this, you know that there's at the moment not that much Awareness for those kind of patches in a kernel then you're gonna think about
43:45
How do I maintain or which bits do I put where very quickly? But yeah, it's it's not just five lines of code that go into that
44:01
I Freeface this by saying I'm not so well up on the kernel development community like Yeah, but I think one nice thing you could have is some kind of reaction Which tells you or I found a problem because that's effectively what we're doing is we're finding problems in startup and saying
44:25
react to it somehow and you could perhaps have these patches in there and It's I don't know printing a warning or leads to a kind of panic or something. People can decide what they want it to do For us we would want to reach this gold standard safe state which functional safety talks about, you know, it's
44:45
For example in the medical community You have this kind of stop everything and don't let it continue because not doing anything is safe So perhaps we would compile the kernel and say okay, let's Stop whatever is running. That's our safe thing
45:01
But you could also make it useful for other people by them saying well, I just want a warning that gets printed out so I know Perhaps I've written the code in the first place even and no one's ever told me it's gone wrong but I can see the warnings now when I run it and So it might even be useful not in a fully functional safety
45:21
the German word is in my head back right area and but yeah, it can also be useful to other people perhaps when they say I Want to see when problems occur that don't necessarily get highlighted all the time More questions. I mean if you've looked at those slides the marker itself is some form of signature and the checksums
46:05
Go into directions of things that you think about in security as well and What we're saying is not security is exclusive to functional safety there's a very strong overlap in a Venn diagram between safety and security because Obviously one part of the risk in my functional safety is security and it's just not the whole thing
46:24
And so definitely when you do your functional safety assessments, you look at what has the security community done What do they do and what say? Things can I reuse that have been implemented since the kernel in particular has had a whole influx of bigger things in the name of security bits of
46:43
Or I want to take these things and put them over there and those things I want to put them over there and Certainly, these things are very useful and you look at them. Yeah and more questions Awesome, thank you very much
Recommendations
Series of 5 media