LLSOFTSECBOOK: LOW-LEVEL SOFTWARE SECURITY FOR COMPILER DEVELOPERS
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 |
| |
| Alternative Title |
| |
| Title of Series | ||
| Number of Parts | 287 | |
| Author | ||
| Contributors | ||
| License | CC Attribution 2.0 Belgium: 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/56884 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Discrete element methodFreewareSigma-algebraCompilerSoftware developerExpert systemInformation securityLevel (video gaming)DataflowExploit (computer security)Web pageMereologyProjective planeInformation securityCompilerSlide ruleFocus (optics)Physical systemMultiplication signExpert systemForcing (mathematics)Operator (mathematics)outputLevel (video gaming)Online helpForm (programming)Point (geometry)Bit rateUser-generated contentBitSystem softwarePlanningTheoryCASE <Informatik>WebsiteDecision theoryDescriptive statisticsComputerWorkstation <Musikinstrument>SoftwareOpen sourceArithmetic meanCompilerStrategy gameCausalityRevision controlInternet forumOrder (biology)INTEGRALContent (media)ImplementationSocial classCodeProbability density functionInformationFirmwareContinuous integrationCommitment schemeAttribute grammarKernel (computing)Engineering drawing
06:33
Software developerSoftwareInformation securityCode generationCompilerBinary fileSimilarity (geometry)CodeMathematical analysisCompilerVariety (linguistics)Level (video gaming)Compilation albumVideo gameFilm editingRevision controlWeb pageProjective planeSheaf (mathematics)BitShared memoryData structureFeedbackMathematicsSlide ruleInformation securityBit rateBuffer overflowMereologyFitness functionPhase transitionOnline helpSocial classBuffer solutionChainExploit (computer security)CompilerVulnerability (computing)Semiconductor memoryContent (media)Intrusion detection systemEmailSoftwareThread (computing)Source codeComputer animationJSON
09:02
Web pageTerm (mathematics)Student's t-testView (database)Logical constantSoftware frameworkRight anglePhysical systemHypermediaGoodness of fitProcess (computing)Latin squareOpen sourceInformation securityRevision controlSystem callError messageArmMessage passingVideoconferencingCuboidMereologyBitProjective planeRule of inferenceData structureCompilerContent (media)Compiler constructionChainDisk read-and-write headOnline helpMultiplication signComputer animationMeeting/Interview
12:22
Boiling pointMoving averageTraffic reportingNatural numberMultiplication signRight angleMeeting/Interview
13:25
MereologyQuicksortSheaf (mathematics)Data storage deviceSimilarity (geometry)Right angleType theoryDifferent (Kate Ryan album)CompilerMeeting/Interview
13:51
Side channel attackMereologyChainContent (media)Sheaf (mathematics)Term (mathematics)CompilerInformation securityWebsiteDifferent (Kate Ryan album)Meeting/Interview
15:00
Open sourceTerm (mathematics)Projective planeQuicksortMaxima and minimaMeeting/Interview
15:20
ArmTerm (mathematics)Video gameFocus (optics)Information securityPoint (geometry)System softwareDescriptive statisticsParticle systemMaxima and minimaCausalityMereologyResultantStudent's t-testStability theoryRange (statistics)Moment (mathematics)Component-based software engineeringProjective planeRight angleMultiplication signAbsolute valueRevision controlStandard deviationMeeting/Interview
17:09
Term (mathematics)QuicksortData structureContent (media)Information securityMeeting/Interview
17:39
Data structureCycle (graph theory)Information securityWordFeedbackSet (mathematics)Right angleSheaf (mathematics)Computer scienceInformationFlow separationAreaHypermediaMoving averageExpert systemPlanningSide channel attackCompilerLine (geometry)Boundary value problemCache (computing)MereologyIntegerCategory of beingSemiconductor memoryMeeting/Interview
19:30
Online chatType theoryQuicksortRight angleMathematicsMultiplication signGroup actionMeeting/Interview
20:27
Cache (computing)Numerical taxonomyWeb pageOpen sourceMultiplication signCompilerInformation securityProjective planeBitContext awarenessRight angleData structureGroup actionVotingCodecMeeting/Interview
21:31
WordRight angleMeeting/Interview
21:54
Key (cryptography)Content (media)Web pageLatent heatCompilerInformation securityProjective planeFeedbackRight angleWritingTrailWater vaporMeeting/Interview
23:12
Meeting/InterviewComputer animation
Transcript: English(auto-generated)
00:11
Good afternoon, my name is Christoph Beels. Today I'm going to talk about a new open source project we've been starting. The project's aim is to create a book that describes what most compiler developers should know about security.
00:26
The name of the project is LLSoftSecBook, which is short for Low Level Software Security Book. Let me start with summarizing the key aspects of this new open source project. I'll then go into more detail in the following slides.
00:43
The aim of this project is to create a book to educate compiler developers on all aspects of software security relevant to them. We do hope that the book will also be of interest to other developers working on system software. The reason we decided to start this project is that as compiler developers, we
01:02
see that in recent times we end up working more on security related aspects. While working on those, at least some of us feel we could use deeper expertise from time to time. After having looked around, it seems there is no great educational material available specifically for compiler developers.
01:22
So we thought it would be a good idea to try and create such material. We also thought it would be good to create it as an open source project. By enabling more experts to contribute and by making it freely available, we hope we can multiply the positive impact this book can have.
01:40
The status is that we really just started this project. Some initial pieces of content are written, but probably more than 90% of the content still needs to be written. Maybe the main reason I'm talking about the project today at this early stage of development is that we are looking for help. We welcome help in the form of reviewing existing or new content, suggestions for improvements, and new pieces of original content.
02:08
In the end, our goal with this open source book is to make compilers better. More specifically, we hope that this book will help raise the security-related expertise with many compiler developers.
02:22
In turn, we hope that will result in better implemented security features and in fewer attacks succeeding in breaking hardening features. Let me go into a bit more detail on the reasons why we started this open source book.
02:40
We've observed that many of our compiler developer colleagues more often work on security-related features than in the past. We also observed that from time to time, we're missing some deeper insights into how hardening features do block attackers both in theory and in practice. Or at least sometimes we feel we don't have enough background insights to be
03:03
sure enough about the design and implementation trade-offs we're making when implementing security features. This seems to be true not only at the company I work for, but across the industry. In some cases, it may be that there simply isn't any theory or enough practical understanding by anyone to be fully comfortable about a particular design decision.
03:26
But in many cases, we probably could make more informed design decisions if the collective knowledge about security aspects of code generation were more easily available. After looking around, we did not find great educational material to help us overcome the lack of expertise.
03:44
We did find a lot of detailed descriptions of how a specific exploit manages to work around a hardening feature implemented by a compiler. But we did not find much material that explains on how to think about a class of exploits or how a particular code generation strategy may affect the probability of success for a class of exploits.
04:07
More than a year ago, I thought I just write up what I thought was relevant for myself, and I initially thought it could fit on a few pages. But I quickly realized there was probably on the order of a hundred pages to be written, even when sticking to essentials.
04:22
I also realized that by trying to write up an easy to understand description of what I thought I knew, there were gaps in my knowledge in the details. So trying to write up how classes of exploits work and how to mitigate against them helps me to understand the issues better. I believe that is called the Feynman technique to learn something.
04:44
I do believe it's worth creating a book describing what compiler developers should know about security aspects of code generation. First, as already said, compiler engineers are working more and more on security related features. Secondly, by making the book publicly available, rather than just write something up
05:03
for myself or my close colleagues, it can have a much wider impact. Thirdly, by making the book not only public, but also open source, we can get input from other experts more easily. That can make the book only better. I also hope that by creating one more forum where experts can discuss publicly, it
05:25
could also help a bit to further strengthen the community of low-level software security experts. While the book is focused on compiler developers as the target audience, I expect that many of the topics covered will also be interesting to other system software developers, such as firmware or kernel developers.
05:43
To make it as easy as possible both to contribute to the book and to consume it, we thought the most recent creative commons attributions license was best suited for this book. It's also known as the CC BY 4.0 license.
06:02
We've created the project on GitHub a few months ago. The URL for it is github.com slash alalsoftsec slash alalsoftsecbook. Since then, my initial focus was on implementing the basic build system for the book. The book is written in Markdown.
06:21
Pandoc is being used to convert that Markdown source to both an HTML and a PDF version. Continuous integration has been set up to check that the book builds correctly on every pull request and commit. A live copy of the latest version of the book is automatically published as a GitHub Pages page, at the URL shown at the top of the slide, alalsoftsec dot github dot io slash alalsoftsecbook.
06:50
The majority of the chapter content and sections still needs to be written. We expect that as we write more content, we may discover that it will be best to make some changes to the overall structure of the book.
07:02
As of now, the book has the following structure. It starts with an introductory chapter. Then there is a chapter on everything related to memory vulnerabilities such as buffer overflows, ROP, JOP, DOP attacks, and how the various classes of mitigations work to block those exploits.
07:20
The third chapter aims to describe how covert and side-channels work. With the next two chapters then covering attacks making use of side-channels, I've decided to split this into two chapters. One for side-channels where the attacker needs physical access to the system, and one where the attacker does not need physical access.
07:41
A sixth chapter covers supply chain attacks, which have been in the news a lot recently. And then there is a chapter for all other relevant topics that do not fit the other chapters and may not need a full chapter on their own. I hope that in the past few minutes I managed to explain why we believe we need to write a book on software security for compiler engineers.
08:05
The project is currently in an early phase of development and we're looking for help. You could help in various ways, which include, but are not limited to, sharing your IDs for new content, sharing your IDs on any other way the book could be improved,
08:22
reviewing existing and new content, writing new content, and sharing this project and talking about this with everyone you think could be interested in it. Some ways you can reach out are by raising a GitHub issue, raising a pull request, or starting a discussion thread.
08:44
You can also reach out to me personally at the email on the slide. I hope I convinced you of the usefulness of the project and I'm looking forward to hearing your feedback. Thank you for listening.
09:50
There is a message box below and perhaps just to get us started, Christoph, if you want to just expand a little bit about the GitHub page and where do you see the future of this textbook in the long term view?
10:08
Right, right. My thoughts on creating this is basically, me myself, I want to learn more
10:21
about how to, as a compiler writer, know all the things I should know about security. I know a thing or two, but not all the things. That's why I'm really motivated to create this open source project. So what's there right now is the framework for a book with a few pieces of content filled in.
10:42
Me and a few other people I work with, we're writing some pieces bit by bit still, so probably I'm expecting in the coming week one or two more pieces to be up for review. So it's not set in stone what the best structure for this book is. We're having an incremental development process, so to speak.
11:06
So as we write, maybe we discover that there's new pieces of content that we need to write. Or maybe we should structure it a bit differently and that it's easier to have a nice structure that you can keep in your head about all aspects of security that the compiler writer should know about.
11:23
I can say that already, for example, we now have the start of a chapter on supply chain attacks, like in the very first version that was on GitHub that wasn't there. It was someone else working in compilers, working on supply chain attacks, thinking, suggesting, hey, maybe that should be honest.
11:42
And so basically, we're looking for help from anyone to contribute ideas on what should be there, ideas on what can be improved in the book, how the structure could be improved, even just reviewing what's there. Probably as you can all hear, I'm not a native English speaker, so I'm very
12:01
sure that everything I write, even just grammatically, there are things that could be improved. So all of that is fairly welcome. Cool. Awesome. We do have a question asking about, is there a rough timeline for this project? And when do you see other milestones you've planned or others? What do we call a finish, for example?
12:21
Right, so I'm not going to put any dates on it. Like a true open source project, this is based on how much time people have available to contribute. I know I am reserving some of my time to make sure that we get the ball rolling. And there's one or two more people currently reserving some of their time to get the ball really rolling.
12:46
And personally, I think it would be awesome if, like, by next year you would have a first draft of the basics of everything that we should mention are in there. That would be awesome. But it boils down to the more contributors, reviewers, people filing book reports or ideas for improvements.
13:09
It boils down to, will there be enough people helping with that? So that will be the thing that mainly determines how quickly we progress.
13:24
Right. Yes, another question we have is, what would be the advice for different sort of compiler engineers working on different parts or sections of the book? Are they mostly going to be different or can they sort of write parts of the
13:41
book and then will be similar type of sort of things they write for another part? Or is there anything they can, they should know before they dive into the book itself? That's an interesting question. I hadn't thought about like a front-end engineer or a back-end engineer. Do they think differently about security or should different parts of the book be interesting to them?
14:02
It might be like, I'm trying to think out loud, like I'm guessing that things like cash side channels might be more interesting to like back-end engineers because to mitigate that you work more closely like the individual instructions. Then some other parts might be more relevant for other engineers like example for supply chain attacks.
14:26
Maybe I'm guessing that maybe that's. Well, it's probably relevant to all compiler engineers that they may be specifically relevant to maybe whoever is managing the development of the tool chain and everything around that and that kind of thing.
14:43
So I do think that the different sections of, well, I would expect that there will be some contents that will be relevant for no matter exactly where your expertise is in developing a component. Cool. And yeah, what about in terms of the use of this book in the long run or maybe after it's finished or perhaps while it's almost finished?
15:11
Where do you see, because it's open source then, where do you see the majority of the users will be and what sort of impact will it have? Well, so with this open source project really being at the start, I can only dream for like what's the maximum impact this book could have?
15:32
Like in my wildest dreams, this becomes like a standard textbooks for students studying security and system software. That's in my wildest dreams. So even if that doesn't become reality and if this just becomes like a really good resource
15:51
for our component developers that need to know about security, then I think the project is already wildly successful if we achieve that.
16:02
I do think that the book probably will never be actually finished. Like new security aspects get discovered pretty quickly. So I do think that's important. There is life. So I talked about there being a live version. I do expect that the live version will be like the most up to date, the most valuable version.
16:26
At the same time, I do expect that at some point we will get to the point where we think like we've given a basic description of the main concept that we think everyone should know about. It's been reviewed by quite a few different people. Those parts are getting stable.
16:43
Maybe at that point we can have a 1.0 release or something like that. But I haven't really thought about that. At the moment, my main focus is on let's get the development of the book going, get that going well. And really, I don't expect that there will be an end point as new security related insights do pop up all the time.
17:08
Right. Absolutely. And what about in terms of the actual content of the book, what do you think would be the general structure or content of the book look like?
17:23
Is it going to be as important, for example, for certain definitions to be laid out as an introduction and then sort of followed by maybe some examples or exploring some of the most recent security updates and security knowledge?
17:41
I don't think like there's one structure that will definitely be better than a whole number of other structures for the book. And so what we have right now is just one way of organizing stuff. So basically right now it's something along the lines of memory vulnerabilities, a huge category of security issues that compilers have a role to play in.
18:04
And then there's a side channel attacks, also a huge area compilers have a role to play, and then a number of other attacks. We also have discussed like, what's the amount of knowledge that we can assume a reader to have like, what should we start explaining?
18:22
And that's like it's all set in stone exactly where we should draw the boundary. So actually right now I'm writing a part for cache side channel attacks. So for example, I'm planning to actually write like, what's the basic structure of the cache?
18:42
There are some cache sets, there's associativity, this is how it works, because you need to know the details of how that works to understand like, how could you make an exploit like this work? And then you have to know that to know how could the mitigation work? And so we I think we will assume some basic computer science knowledge background.
19:08
But yeah, it's also that also depends on feedback. So basically, we welcome very much feedback. What readers say, oh, we could use more detailed information here or actually this whole section seems to be too basic
19:22
to me that everyone knows that you can remove that or just put it in the panic or something like that. Right. Okay, I think we've got about three minutes. Are there any additional questions from the audience?
19:41
Feel free to type in the chat. Is there anything else you would like to share, Christoph? And maybe about sort of during the I assume, of course, this is perhaps not the
20:01
first day that you've thought about this book, you probably have thought about it for very long. What are some of the other any sort of interesting things that is it? Well, I guess I mean, I one thing I could ask is, is the book that we see right now the same as sort of when you thought of it the first time? Like, has anything changed so far? Like, because I can imagine with S, you know, so many technology updates that there must be changes.
20:25
Yeah, so I started thinking about this about a year ago. And I wasn't even thinking about the source project or even thinking about the book. I just thought like, oh, yeah, I get a lot of security related compiler security related questions.
20:42
And every time I have to like do a context switch in my head, then I want to have a bit more structure and write it up. And I thought, oh, you know what? Everything that's related to security compilers, I'll just write it up very briefly on a few pages and then I have a taxonomy of it. And then that's free for me. That will make it easier to understand.
21:01
And then as I started writing, when I just started writing something about cache side-channel attacks, I quickly ended up with 10 pages. And that's when I realized, OK, I won't be able to come up with a summary in a few pages that is turning into a book. And then the idea developed for, oh, maybe I should make this an open source book.
21:24
And so that's how the idea developed in the past year. Yeah, that sounds very interesting. Yeah, we've got about just around one minute left. Let's see if the crowd has any more questions.
21:42
If not, I'll probably leave some last words to you to give a quick summary. All right. Well, if there are no further questions. So, yeah, in summary, if you think there is value in creating a book that summarizes the
22:06
key aspects, the key security and compiler aspects that engineers should know about, then please do provide feedback. It's very valuable to us, the few people that are currently contributing to the book.
22:20
If you want to contribute yourself, you can do that by reviewing. You can do that by sharing ideas. Just leave it an issue on the GitHub page and the issue tracker or reach out to us in any other way. If you want to write content for a specific topic, that's very welcome.
22:41
Also, again, please do reach out to us so that we don't have multiple people not knowing about each other writing the same content. So, yeah, this is really the start of the project and we very much welcome any and all feedback. And if you think this idea is interesting, do share it with everyone who might also be interested.
23:07
Thank you for listening, everyone. Yeah, thank you very much.