Making C Less Dangerous in the Linux kernel

welcome back everyone those of you who are fortunate enough to see Casey shelf let's talk before lunch titled because making the kernel harder make making the kernel harder I'm sure you will also agree that this would make an excellent follow-up to that talk is this talk is titled making Seeley's dangerous and then the next kernel can I get your order please welcome please hi thanks for coming after lunch this is one title I have another title screen because there wasn't room for URL on the prior slide so this is making C less dangerous in the Linux kernel my name is spelled that way which is the Dutch spelling but it's just pronounced case I respond to whatever though but if you want to follow along I have some links some of the bullet lists and things have links and other things you might want to click through I'll have this up and you can get it but if you want to follow along right now it's at that URL so as as mentioned this presentation is about the Linux kernel and of the use of C there because well most people will agree that C is a crazy and dangerous language it is somewhat difficult to change a multimillion line codebase away from c so we have what we have so I'm going to talk a little bit first about the kernel self protection project and that C is just a fancy assembler and then a bunch of things we've looked at as far as avoiding the pitfalls of using C itself so in 2015 watching the general rising tide of interest in security especially in the kernel I kicked off the kernel self protection project as a way to try to herd all the cats together to try and work on defenses in the kernel specifically I wanted the project to focus on protecting the kernel from user space rather than protecting user space from itself and all the things that the kernel can do to support the defenses in user space because there are a lot of those already and I felt like catching the kernel up in defenses was was a needed area and I'm the numbers are getting harder and harder to count because there are so many things going on but roughly speaking participation the in the projects has been pretty decent I've had like about 12 organizations and ten individuals working on like I don't know 20 technologies it's pretty scattered but I like to sort of think of the project as you know slow and steady in the the kernel hardening buff just before this I talked a little bit about you know even if we see something that's gonna take oh man it's gonna take forever for us to do that it'll take three years for this or that it's like okay that's fine I just want to start the clock because if we never actually start the timer we'll never get there so I'm gonna break some of the catch-22s in implementing these things by just starting now and eventually will finish and then we'll have it because we can't just magically wave a wand so as many of you are probably aware see is from a certain perspective a fancy assembler you're very close to machine code and this is a reasonable choice for the kernel because it wants to be fast and small and it's close to the to the to the machine code as possible and you want to do really architecture specific things there is no C API for setting up page tables and switching CPU modes and doing all these things that are implicitly machine code and in fact sometimes we are using literal machine code in the kernel to do these things and wrapping C around it but there is no a specific C API now with the fancy assembler comes undefined behavior so the the C language has a huge history and a lot of operational baggage and even weak standard library libraries and things like that those questions over well what about the contents of uninitialized variables well it's undefined but there's still behavior with that whatever was in memory before is what's in your uninitialized variable so it is quite initialized you just don't know necessarily with what someone very interested in taking advantage of that may spend the time to figure out what it's been initialized with and figure out a way to control it also going from C to assembly you have void pointers but you can call functions through a void pointer so all the type information about what arguments are going in and out of that function what the return value is all of that semantic information is lost when you go down to machine code and you get weird standard library things I'll come back to this one but mem copy has no concept of the destination buffer size you say how much you want to copy that's nice but how do you know what's at your target there's nothing implicit in the API to support that and a wonderful wonderful blog which this shirt is from was with undefined behavior anything is possible which is not great if you would if you want to control the behavior of your system against people who would like to subvert it one of the first things I want to talk about was variable-length arrays and alakay which is effectively the same thing it's dynamic allocation of a stack variable space on the stack so if you have an unbounded VLA or you don't check the lengths of your of your stack allocations like this you end up you may exhaust the stack and start writing over whatever followed the stack that's the first diagram is sure I have a giant buffer but my stack is a limited size in the kernel so I'll just keep writing across it and into whatever's next so okay fine we can we can stop that kind of linear overflow by adding a guard page between so you go writing along and then you fault and you're good well what if it's an array and you just jump over the garden page to do your writing well that's not great either and of course stack protectors like like stack cookies don't help in this situation because you as the attacker you're actually controlling the size of the stack and the cookie is going to be after that so your no protection there either the nice thing is compilers let you actually find these because they're annoying for a compiler to deal with too and they would like to have you not do it so if you compile - warn VLA you'll at least find them and if for some reason you can't just get rid of these and you're an user space not the kernel you can do use GCC's stack probing feature this was from the stack clash attack where the idea is you never noticed that the guard page ran into something because you just do this giant growth of the stack so the stack clash protection actually will probe the stack in userspace every page size it'll try to read out the memory and that'll slowly push the guard page into colliding and exploding instead of magically jumping past everything so if you're an user space not the kernel please use that flag if you can't just get rid of relays completely and in recent news alakay is what end up breaking system d recently they had an unchecked size there so just don't use V LA's they're bad and dangerous as it turns out they are also slow this was sort of an implicit realization like oh yeah there's going to be more code to check the size and grow it yeah it's probably a little bit slower to use of the LA but in the process of doing VL a removal there was the original code and on stack relay ran at about that speed and then with a fixed size like I want the stack to always be this big because I'll never use more than that was one solution and the other one was to do a dynamic memory allocation and the fixed stack size turned out to be something like 13% faster which seemed way higher than oh yeah added a couple instructions so this is some nice actual benchmark information on the fact that the VLA usage is actually slow - in addition to being security scary I wanted to go visualize that why why was it so slow this is a bit of an exaggeration because this is without optimization but still it's still large even with o2 so it's the same it's the same code and both sides except one just has a dynamic array size and you can look at the assembly here and it's just this massive amount of code I don't even know why unoptimized it's this bad but you get a sense that there's definitely a lot happening so that's why it's slow yeah it's terrific it's completely horrific with-with-with - OH - it's it's definitely shorter but is a little bit hard harder to compare because the preambles and everything changes well this was easier to just show this part is like that it's horrible but again kernel is actually built with o2 so it wasn't that bad but still 13% performance so if I can't convince you about its security properties it's faster to use a fixed length array anyway another weird one with the C language is a switch case switch statements and case fall-through c has an indicator for please stop this case it's called break but its absence is supposed to indicate that you want to fall through but what if you just forgot to put the break maybe you didn't mean to fall through so for a very long time there was just nothing in C to indicate I actually want to fall through a lot of analysis tools like Coverity and some others started recognizing comments as an indication of whether or not fall through was intentional and this became so prevalent that there's actually entered into the syntax checking of the compilers would actually parse comments in switch statements to determine whether or not this was okay and the like the the C standard folks I assume saw this and freaked out and said this is terrible on a parse comments that's madness so there is sort of a statement you can add now but really it's too late at this point all all that static checkers are looking for a comment so you need to to move on and add comments like this so you can add implicit fall-through which says you you don't you don't allow fall through well you can warn if there's a switch ends without a break or a mark of either the comment or the statement that got added recently and so this this showed up a lot in the Coverity scans the Linux kernel and Gustavo who I call out here has been systematically going through and adding all of these and where it's not obvious asking maintain errs are you sure this was what you meant to do and he's found quite a lot of legitimate bugs I have some numbers in later slides but I mean there were a couple thousand cases of this and he's just been slowly going through doing a patch after patch after patch getting through these when there was the other one which is I touched on it earlier which was so you have an uninitialized local variable the compilers now are happy enough to say hey you use this variable before you initialize it please stop that and generally speaking that's you know though you know the the intent of the kernel compile is to compile that warnings so this warning is on and people go through and make sure all the variables are initialized except for the case of passing a variable by reference so if you pass it into a function you you pass the address of the struct or whatever into another variable there's sort of this assumption that oh well that function will do something to it so certainly it gets initialized in that function and I won't warn about it that's not true sometimes so there's been a push to say okay we just need to initialize everything we were actually are already covered on everything that's not passed by reference because that's actually been fixed so the question is all right well we should initialize everything that's even passed by reference and I was not really excited about trying to have that conversation with very performance sensitive culture of the Linux kernel except that when this topic came up and the idea of a zero initializing everything was suggested leanness said he loved it so I was very relieved and I include a reference to this in anything where we're talking about uninitialized variable of forced initialization since if leanness wants it you can't say no getting getting this actually implemented in the compilers is an ongoing thing from a couple years back there was a patch suggested against GCC it's not upstream yet it had some port interactions with for example warning about your uninitialized variables so if you force initialize everything now you don't get a warning about having missed initializing something which may be a bug because you maybe want to initialize it something that's not zero so the interaction with that is a little odd clang had another patch for this there have been I think I've seen three different versions of local initialization stuff for clang I think one of them is making progress and then there's a the struct Li GCC plug-in that was ported from gr security was extended to cover by reference structures but that doesn't cover non struct things that are passed like a character array or you know smaller things but I've been trying to get that fixed recently I'd rather have the compiler do it but until then maybe we can use plugins one funny thing again leftovers from C being kind of a weird language was with the GCC patch that I was playing with if you built an initializer for a variable that's actually code that executes right you have to say I want to write a zero here so if you declare a variable in the space between a switch and in the first case it'll never get run so the compiler correctly says hey you that'll never happen so we had to I wrote a patch there weren't a lot of these cases though which was nice so I just had to lift all of those up out of switch statements so the compiler would be happy so I had that patch and there was like again I think I sent that out somewhat recently yesterday or something and no one freaked out about Auto initializing all your variables they were just upset that maybe we we're gonna move things out of switch statements that looked weird anyway I'm like okay that's fine I'll have that discussion another whole case is overflow detection and when doing math GCC has an option to to deal with this but it only works for signed overflow conditions but that's okay you probably want to catch those anyway I'm stuck in trying to figure out how to what to do with it right now for the kernel in particular because it's very fast to track because it's it's literally a single instruction and check for the the overflow of the bit in the CPU so I can I can go the abort route where it'll kill the process and do all these things but leanness has said we can't do those things or ik it's very very big because you generate these warnings so the kernel or the the compiler still needs to be updated for this so that we can have sort of a an intermediate position where we could throw a warning and not freak out but we don't carry with us the entire baggage of the warning text that's why the size of the kernel would change the large it would be such a large change because every case where there is a possible arithmetic overflow assigned overflow you add the string that says I had an overflow over here it was this much by that value and that text just gets repeated and repeated and repeated everywhere so having a common handler would be nicer for that in the meantime we can sort of go through and opt into dealing dealing with this directly with overflow caching operators like the check add overflow and the check mull over flow we even have a shift overflow detector now I that's good it's nice to use that when we can but I prefer global coverage instead of an opt in case because that those are slow but we do have them if you want to actually check for overflow clang adds an unsigned integer overflow I'd really like to get the kernel clean on both signed and unsigned integer overflows the problem is there are a lot of cases in the kernel where there was intentional unsigned overflows so they have to find all of those and mark them as yes yes I wanted that clang does allow for a variety of different types of failure cases you can warn and continue you can warn an abort you can abort without a warning you can do it done a bunch of different things so there's a little bit more flexibility in how clang would instrument the kernel for for reporting these these conditions so I'm I'd like to get GCC up to that level so we'd have a better way to deal with that inside the kernel the favorite one bounds checking so explicit like dealing with buffer overflows whether it's a stack overflow heap whatever doing explicit checking does get time-consuming and I have these numbers up here it's like less than 1% okay cool 2% people start getting angry 1% maybe and then sort of compare that against well but here's the threat of this other security flaw where we turn off hyper-threading which is like a 50% reduction performance what's 2% I haven't really gotten a lot of traction on that yet but I'm like to do this the trouble with the Xbox bounce tracking is you actually need to confidently know what it is that you're going to bounce check against in the the hardened user copy the first one listed there the check is if it's a stack variable you can say okay you didn't exceed the the actual kernel stack and since we've removed like the the per frame markings in the kernel we can't always check that it's stayed within a stack frame so we've lost that granularity so the granularity on that check is kind of large and if it's coming out of a slab allocation in the kernel slab heap memory we can look and see okay we know where this was allocated we know the size of this allocation now we have bounds checking we can do if it came out of a page allocator sometimes you can see that it what the size the allocation was and other times it was merged in you know like two network packets came in and they said well you're next to each other now will claim you one packet but the allocator doesn't actually know that it's continuous and things get confused so the while we can add explicit checking in a lot of these cases the granularity of check depends on the underlying memory allocation so related to this of course or our terrible api's so here's my my page on string copy we'll start at top string copy has no balance checking at all don't use it string and copy does not always know terminate so don't use it for c strings in the c library so it is however good for copying a c string into a non c string fixed size buffer that you don't want to leak more information out of because it will no pad the entire destination if it's shorter than the destination but if the destination is exactly the size of string it will not null terminate it so if you're dealing with weird things that aren't actually a c string or like a fixed array of bytes sure use string and copy but you can actually mark those with like underscore underscore non string and then GCC will not be happy yes yes yes if you have v6 and v7 unities still please continue to use string and copy string L copy was added as a well let's just null terminate it anyway come on accept string L copy will actually call string lang string lend on the source to determine how long it is before terminating it so your string line may just read off the end of memory or do some other things so I don't use string L copy so okay what's left string s copy okay so this returns the number of bytes actually copied not including the null and it null terminates or it returns and if it gets truncated by that it will return e to Biggs you can actually test what it's sent but it of course does not null pad a destination if you don't want to be leaking fixed size things out so then you have to Mel pad a destination if you want to do that but so we don't have a helper that'll actually do both string s copies job and string and copies job at the same time safely you just have to do a mem set open coded so we need to help her for that but generally speaking you want string s copy so then there is s printf esperan F has no bounds checking do not use it string n printf does null terminate unlike string and copy with the same n name whatever but string and printf returns how much it would have written not how much it did so so you can call s n printf with a null target and a size of zero and a format and all your arguments to determine how large the resulting format will resolve to and then you can allocate that much memory and then you call again with that as a target that's sort of its design except when you do things like this where you're adding on to a larger and larger string and you're just taking the output of SN printf the good news is that many kernel releases ago when the the size of buff - count went negative and became a giant number SN printf learned to say that's probably not what you meant I will in fact not write lots and lots of memory all over the place I will return zero but the one that did overflow will have overflowed the the counter there will be larger than your destination size so when you then go copy it back to user space you copy your buffer plus whatever is after it beyond what you had so there's a lot of places where you leak in an appropriate size so use SC and printf which of course is not part of any C library except in the kernel maybe I'm wrong about that but I couldn't find so I'm SC n printf always null terminates and returns a kind the count of bytes actually copied so you can safely use it in the above code but of course it's a kernel so we can't just globally search in replace because there are places that want to know that it overflowed an SC and printf won't tell you that it overflowed and so they're still using s n printf and anyway so if you find yourself in a situation please use SC and printf in the kernel of course those come back around to mem copy be careful I don't know the problem is with the usage patterns for these functions which is there's much like much like this thing where you're trying to append to a buffer you're like building output and you have multiple formats or you're doing a bunch of different things in a row you get that a lot with mem copy - you're building up a structure that you're going to write to disk or you're going to send it over the network you're doing things so there's this this pattern of usage that happens a lot that we have virtually no API support fors like well this is something we want to do a lot we should really have some libraries that you know support us in getting that job done anyway so continuing past the horrors of bounds checking the future is always brighter so we'll have memory tagging and hardware sparked at this with their ATI the arm V 8.5 memory tagging extension will have this in the near to distant future there do not appear to be plans yet that are public or known for Intel supporting it it would be nice so in the in little diagram I've got here the tagging works by actually using bytes in the top like in using bits I should say in the top byte of the add the pointer that you get back so for example you would call K malloc for some size and it writes a tag in the beginning and when you do you reference that the kernel says well you're gonna go over here and your offset is like 40 hex so you're still inside that tagged area and then if that if you increment that pointer beyond the tagged area that it has when that dereference occurs it goes and compares the tag in the pointer you're using with the tag at the memory location you've just arrived at and if they do not match this will fault and this basically would stop whole classes of of linear overflows most of the problems I just talked about in the terrible API items it doesn't help much like jumping over the guard page with the stack protectors it doesn't help if you know two different regions of memory that share the same tag and you are able to perform an index jump over to the other tag but at least linear direct linear overflows will be blocked and this also doesn't solve situations where you have so that that'll that'll solve most Interop jecht like neighboring object overflows but not solve going like within an object you have a struct or something and you have a fixed length character array and you've got sensitive information after that and you can mem copy past the end of your structure or end of your buffer into the more fields in the same structure you're still in the same tagged area this has happened with things like really long ESS IDs and Wi-Fi drivers they have one giant structure for everything so it's not doesn't solve everything but it gets us a lot it's fixed yeah yes as yeah so this time I'm using a write example and the question was this is also applied to reads and my understanding is that both adi and mt e would freak out on a read so it's any memory access although now i want to know if execute would be protected since that's on a usually on a different path anyway so then oh I want immediately to execute that was good so control flow integrity this is protecting us against Rob attacks anything where we're dealing with a redirection of execution after some kind of write happened and I touched on this earlier where I said you go from C where you say all right I'm returning an int I'm taking these different structure pointers you have a whole prototype of all that all that information gets lost normally when you go down a machine language and you save pointers to functions in the heap you save return addresses on the stack and all that type information all the you know call graph information is just not present and here's I'm trying to demonstrate you're making a function call out to a new function that's the forward edge and when you return from that function that's the backward edge to return to where you were and in those cases on the heap for example or somewhere you've stored a function pointer that you're going to go to and on the stack you've got your return address going back and these again just pointers if you force an override of the the function types in here C will compile down to assembly and you run it and it says you know my check here is either call function one or function two and I've I've forced a weird void or overflow but are not a miscast but it doesn't care it's still function and I'll call it so if you run it you get one or the other if you actually enforce prototype checking so see if I for example and clang with sanitize see fi it'll actually attempt to retain that information about those functions and and has a method to check at call times are you part of the family of functions that match this prototype so in this case the my overridden function to to call two will fail and see if I breaks me the see if I check will stop stop that that's really nice so on the backwards edge what can we do clang has a safe stack where it tries to separate these into two stack areas so you have you know unsafe things that are buffers and viruses by reference variables and things that can't really check and a safe stack which contains the automatic register spills that it might be doing variables it can it can reason about to be safe and return addresses so that all the bad stuff happens in one area of memory and the safe stuff happens in another there are pros and cons to this and then there's a shadow call stack which has some hardware support which I get to but uh this splits it into just storing the return address everything else is in the normal stack that's fine but it's really our control control flow stuff that we want to keep a attach to so we try to have effectively to stack registers all the time a problem of doing this in software is that if as an attacker you can figure out where the where the sensitive stack is you can still overwrite it so see if I backward edge hardware support the Intel CET has effectively a read-only shadow stack that does what the prior slide is talking about but it has an in has an ability to implicitly write to a region of memory that is normally read-only which is handy because even if you figure out what where that is in memory as an attack you cannot directly write to it and then in arm the eight-point-three a pointer authentication is effectively signing with a couple bits but that's good enough when you enter and when you leave a function so you you end up with a signed return address as a way of thinking about it and that's quite effective as well so question is where is Linux kernel right now variable-length arrays they have finally been eradicated as of 4.20 - WV la is the default build and as far as I can tell will never add them back that was that was a lot of people helping with that I'm very it was we started a concerted effort on about four releases ago and with a lot of people working on that we got through it it was taken me a lot a lot longer without all that help the explicit Kate switch case fall through this is largely been gustavo just plugging away at it but um i went back and counted from before when gustavo had started on and we had about 2300 of these situations and he told me i think this morning that at least in linux next we are down to 232 of those so we've done 90% doing always initialized variables i can't predict where that's going to end up having lena say that he wants it obviously means that it's not it is a matter of technical challenge not social challenge and a lot of a lot of these a lot of the kernel hardening features tend to be you know a political and social challenge and a technical challenge so i feel like that's probably good a lot of the works been done in plugins already there's active interest and fixing it globally for for the compilers so i think that'll happen soon and I hope that by next LCA I can report that's taken care of the arithmetic overflow detection I think that has a really long tail because there's a lot of error cases and weird conditions we're gonna do that and if you followed SIDS caller at all in a huge dashboard of bugs that says caller reports they don't even turn on the arithmetic overflow detection portion of sis caller because it produces so many reports and they already have so many reports that people are flooded with that so while I'd like to well I'd like to get to that I am concerned that's gonna be a while before we make any serious progress on it um bounds checking well we'll deal with performance concerns and then wait impatiently for hardware support we'll still need to deal with that more i I think that making I think that making a better standard library for dealing with things would help a lot in that and just to avoid the bugs see if I both forward and back there has been a lot of progress in the Android kernel team making this work under clang with link time optimization the pixel 3 has working CFI for their kernel there's gonna be a lot more work necessary to get this all the way upstream but it does work on production systems and that's pretty great and again waiting for a hardware support again on that there's another place where we go but until then we can do that we can wait for it so we have challenges and kernel security developments there's a lot of conservatism dealing with the responsibility of maintaining code there's some sacrifice to that patience I have this gift because that's sort of how I feel sometimes but there's there's some there's a lot of technical complexity there's innovation to be done there's a lot of you know there's been a theme of the keynotes on collaboration and that's why I think we've made we've made a lot of progress because so many people are working on this together and we have we need more resources we need more people doing it reviewers even just say hey it booted I love it go for it well I don't like to admit it we do need people to backport this stuff because there are some some devices products or things that are just stuck on older kernel versions and getting some of these features back ported would really help and that's really all I have with some links and other things high case as I'm obviously a big fan of kernel hardening I've made some contributions of my own one of the concerns I have about the compiler assisted hardening like address address sanitizer for example is that they add an awful lot of code and I appreciate this is code that the CPU has no particular problems executing it's all pretty fast but when I'm trying to debug a problem I find that the code produced by the compiler is incredibly hard to read once the address sanitizer is turned on and so that makes debugging harder for me and that makes me sad and what should we do about it yes I think that um the the a sans stuff is incredibly aggressive in how it is checking everything all the time and that leads to the problem that you're talking about I think the and normal sane people will not turn that on in production because there are there is pretty significant performance penalties as well but when you're debugging a thing where you say it is shown it is seen here I can't read this code I don't have a good solution for that but the piece that I the pieces of a SAN that I do want to turn on are actually pretty small like I talked about the the signed overflow check is literally one extra instruction it says did the overflow pit get set go there if I did but go there is very large in some cases but I think that the stuff that would be reasonable to turn on in production would not get in anyone's way and dealing with the the difficulty of reading a SAN output in a debug build is is painful I don't have any idea hardware support yeah memory tanky I'm there sign me up I have to ask yes with the new world of EPF coming to the Linux kernel what's your thoughts on that so you know any new edition of a VM anywhere gives me the creeps but the thing I I noted at the beginning of EBP F really taking off and I try to remind myself regularly is that even though it too can be flawed the EBP F has a verifier it's part of the tooling is something that actually checks the byte stream that's going to go through the VM that'll eventually hit a JIT or do everything else so it's not a complete wild west of being able to trust the byte codes that go through eb PF there are vim flaws in the Santa in the verifier of course but the fact is we fix those flaws and we move on so it is catching the things we shouldn't be allowing like we already had there is an infrastructure in place built alongside EPP F that was designed with that security in mind so I I have not lost a lot of sleep at night over that just because I know it's part of the design of it that said it creeps me out well I'll follow up real quick on that is the fact that you know yes right now the verifier every think that but you know everyone wants more and more out of it and it seems like every time the add something more just makes it less secure that's yes this is why I find it creepy the this sort of scope creep on on EPP F does have me worried but what I again coming back to the verifier is there is actually a relatively formalized approach to saying that is an inappropriate function because it lets you read kernel memory so we need to you know limit it in this fashion like there there is actually a design there in theory there is an overall design goal about what EPP F should be and should not be allowed to do as opposed to being just completely ad hoc so I mean it exists people are gonna use it it's gonna expand it will have bugs it has had bugs it's gonna be having bugs but you could ask me the same thing about how I feel about networking or USB or whatever else there are useful things we need to have them but uh as it turns out USB does not have a command verifier necessarily built into its design so maybe if you have some better than that not to pick on USB you mentioned that mem copy doesn't take destination size but I was just reading through the standard and one of the things that I find with the C standard one is hard to get hold off which is what I faced right now it's added a lot of things including a variant of mem copy that has checks the second thing that I was going to talk about is that we don't necessarily have a secure programming secure coding standard for Linux in the sense that there is no guidance for programmers except for review as to how you do secure coding and we're supposed to make the entire system secure that's true having having better guidelines on that would be very welcome I think getting rid of our terrible api's would help first and that's quite a challenge writing coccynelle scripts actually helps quite a bit in this define poor patterns and encode and being able to document that I started a deprecated list to sort of describe things that you shouldn't do or functions we shouldn't use or things we should replace with it and I got to the point where I was like well I want to deprecate using SN printf but only when you're doing an additive like and I was like oh this is a coding stuff like this is a coding description and I'd like to build on that the trouble I've had is if you make it the huge document no one's gonna absorb it so I'm trying to figure out what the best approach to getting the right mindset for for coding safely is and it seems like just better API design gets you into place if you can't shoot yourself in the foot you'll be better off although it's C it's really easy to shoot yourself we're out of time so it plays another round of applause well okay scope

Channel: linux.conf.au

Views: 69,416

Keywords: lca, lca2019, #linux.conf.au#linux#foss#opensource, KeesCook

Id: FY9SbqTO5GQ

Length: 44min 59sec (2699 seconds)

Published: Fri Jan 25 2019

Reddit Comments

[u/Octopus_Uprising]

Would making it "safer" take away some of the power and purpose of C?

[u/Freyr90]

Ok, can somebody explain why to use this:

https://github.com/torvalds/linux/blob/master/lib/string.c#L179

Instead of defining proper strings which would work faster and would be simpler anyway?

All other embedded languages have proper strings (pascal, Ada, C++), which are both safer and faster.

[u/gocarlos]

Tldr make it more c++ like