Hi, this is Ciara Carey, and this is Cloudsmith's monthly webinar on all things cloud native, supply chain security, and DevOps. So Cloudsmith is your cloud native, universal, artifact management platform. We support all your formats from your C sharp NuGets to your Python wheels to your Rust crates, and even your C Conan packages.

We want them all. So today our webinar, we're going to talk about memory safety. Did you know that you could completely eliminate software vulnerabilities by caused by memory corruption by moving your software from C and C to memory safe languages? The USA's NSA National Security Agency has urged developers to shift to memory safe languages like your C sharps, your Go, Java, Ruby, and of course, Rust.

And we're going to be talking a bit more about Rust today. So today we are, we have a wonderful guest, Carol Nichols. She's the [00:01:00] developer, the owner, the founder of Integer32. And she's also the co author of the book, the Rust Programming Language, just sort of renowned in, in Rust circles. So I'm going to bring her on now.

Hi, Carol. How are you? Good. How are you? Good. Thanks so much for coming on the show. We want to hear all about these terrible vulnerabilities. Thank

you so much for having me.

Yeah. So how did you get into Rust initially? You

weren't always a Rust. No, I wasn't. So I was a Ruby on Rails developer for a long time, and I was working on a Rails app and doing a lot of performance tuning.

And there's a certain point at which if you want to keep tuning Ruby, you have to drop into C and I am terrified of C. I had a, a couple of college courses in C and I was lost most of the time and was [00:02:00] at office hours all the time and didn't understand it. And I hated, like, you make a mistake and you just get a core dump and it's like, good luck.

Yeah, I love those compiler messages. They're, they're so useful.

Yeah, yeah. So I knew that I should be nowhere near production C and coincidentally, that was around the time that Rust was gaining some publicity. It was before 1. 0 of Rust and A colleague of mine had written an e book called Rust for Rubius, and I said, Oh, I can do that.

And it was really exciting to get involved in. And I sent him so many pull requests to his book that This is Steve Kladnick. He eventually brought me on as co author of the Rust Programming Language. It has, the Rust for Rubyists kind of evolved into the official book, which evolved into the print book the Rust Programming Language.

And, and I just love it. I, [00:03:00] it, it Feels like the compiler is taking care of the boring, tedious, important memory management parts of Programming at a lower level so that I can concentrate on the actual business problem I'm trying to solve and know that I'm, I'm able to write faster code than I could in Ruby.

And yeah, boring, dangerous problems. They're like the worst.

Yes. Yeah. So it feels like I can like offload that to the Rust compiler, which gives great error messages as opposed to C. And I. It feels really empowering. I feel like it has expanded my abilities because it, it, it's like a productivity booster.

I an ability booster sort of thing.

Yeah. So let's start at the start. Like what, why is C and C why are they so prone to vulnerabilities?[00:04:00]

Let's, let's go, go with C. To start with C gives you very little in the way of keeping track of what memory is valid and what memory isn't valid.

So the, the big problems that are very, very common in C are use after free, where you have a pointer and then you've called to some allocated memory, you've called free on it to clean it up, but something else also has a pointer to that memory. And tries to use it. If an attacker is able to put malicious code at that location instead, then when you try to read it and it's actually invalid, C just goes ahead and reads it and, and keeps going.

And that's how a lot of remote code execution vulnerabilities happen. Double free is if you call free on. on the same memory location twice, and that can also cause corruption. Buffer overflows, underflows, overwrites, [00:05:00] overreads. A

lot of them are to do with buffer overflows,

aren't they? It's when you have like a list of stuff and, and C lets you go right off the end and just keep reading whatever is over there and doesn't stop you.

These are things that C just lets you do and you just have to be careful. And especially when you're doing multi threaded stuff, it doesn't, it doesn't help you at all. And some people say, oh, well, you just have to be careful. You have to be really smart. You have to I'm I'm very careful.

I'm very smart. No, there's been 2 independent studies by Microsoft and by Google, the Google Chrome team looking at. The security vulnerabilities they have had in Chrome from Google and in all products from Microsoft that they have had to issue security patches for, and they've analyzed the root cause of these issues and about 70 percent of them, the underlying [00:06:00] cause was a memory safety problem.

So that's most of them from

my calculations,

right? So, like, we, we as an industry are not capable of being careful enough to avoid these, like, the big companies have shown this, this is not possible. Yeah,

if Microsoft and Google are having 70 percent of vulnerabilities from their big products are down to these memory issues, then nobody can handle them effectively. So there's a, there's, but there's a lot of C and C codes out there, but if you were to move like where I suppose you would think that Rust will be the obvious successor,

right? I have to say, yes, I am definitely biased. I think Rust is the best option.

And we can get into why Google also has Go, which kind of aims to get the simplicity of C. There's Zig, which is not a memory [00:07:00] safe language, but it's also trying to be low level, like C. So there are cases where that might be appropriate. D is another kind of successor to C, but it's a little more niche.

Nim, I've also heard of as having supporters Swift. Oh,

Swift for Apple. I, and like for a lot of these cases, for a lot of cases. You could probably use maybe what people might consider languages with this, like a less steep learning curve, like you could use C sharp. You could use Java. You could use these memory safe languages, but we're talking about languages that need the performance of C and C Really, you can't just.

You can't just go to those languages. You need something that has the performance of C but with this added memory safe feature.

Yes, absolutely. Yeah. So, like if, if the overhead of a garbage collector is acceptable and Go does have a garbage collector[00:08:00] then like that, those languages are a great choice, but there are cases where you need more performance than that, or you're in a resource constrained environment, like an embedded device.

Yes. So. You need to have a way to manage memory without the runtime overhead of a garbage collector, and Rust is great at that. Rust is not as, as portable as C, like, there, you have to, be able to compile to the target you're trying to get to and not every embedded device supports rust or rust doesn't support every embedded device yet.

But that's the end goal.

Whenever I think of memory safety, I think garbage collector, but Rust doesn't do that at all. No, no. Just so like quickly, could you explain how how it actually manages memory this way?

Absolutely. So the big part of the Rust compiler that does this is called the borrow checker. So Rust. the compiler looks at your code and where you introduce a [00:09:00] variable that allocates memory or even on the stack where you say, let X equals something. It says, okay, we're, we're, that's the start of memory allocation.

And then it looks at all the uses of that and sees that. So that X is the owner. of that memory. It sees when that owner goes out of scope and when Rust compiles your code, it inserts what's called drop, which is essentially the free, when your code is no longer using that variable, when, when the owner goes out of scope.

So it's doing the ALC and the free. It's putting them in the right spots for you. You don't have to remember to do that. And any place that you want to let your code read or write or borrow is what we call take a reference to that memory. Like, you can pass references to that. To other parts of the code and the borrow checker makes sure looks at your [00:10:00] code analyzes and make sure that those uses of the references aren't being held on to longer than the owner's scope.

So. You can't have use after free because the compiler will complain and won't even let you compile the code.

So you're stopped at day one. Like there's no way you can release code that is that loses memory. Like the way C does. Brilliant. So, you're shifting left as far as you can, which is brilliant.

Yes.

Yes. Now there, there are some exceptions.

Is this the unsafe keyword?

Exactly. Yeah. So unsafe lets you opt out of a certain subset of Rust's guarantees. It lets you dereference a raw pointer, which is the big one. And it lets you interoperate with a C API with anything that else that talks C, the C API.

So When you, you can use the unsafe keyword and say, Hey Rust I'm going to check. I'm going to make sure this pointer is [00:11:00] cool. So you let me use it even, even if you can't tell that it's fine. And the advantage of this is that it's opt out and, and you have the spot in your code that says unsafe.

So if you do have to do this. For things like interoperating with C or interacting with devices which are inherently unsafe that Rust can't verify. Then if you limit your use of unsafe and you get a crash, then, you know, you have a limited number of places to look.

I know Rust is in Linux, there's a new OpenSSL that's Rust specific.

Yeah. Rustles. Yeah. Yeah.

So when that's like, Talking to other modules in Linux, that, that will be unsafe though, when it's talking to other C modules, then you'll use the unsafe keyword. Is that kind of how it

works? Yes, because Rust can't verify anything that C is doing with whatever you're passing back and forth with C.

So [00:12:00] you have to say, this is unsafe. I will, I will check it myself.

I was looking up the Stack Overflow developer survey this year, and 12 percent of professional developers that were surveyed say they're Rust developers , I want to use something like 16 percent or C and 20 or C like there's still a lot of C and C out there, but Rust is making its way up.

It's also on the same survey, it was the most desired technology, which, so it is having a real moment. Do you think part of that is, is to do with The people involved at Rust, the ecosystem and like crates. io there's a lot of packages there. And so there's a lot there for people.

Why do you think it's becoming so

popular? Oh, I think it's a lot of things. I think I think there's some luck involved. I think we, Rust came on the scene at the right time. Rust actually doesn't, doesn't add a whole lot of new. Ideas [00:13:00] like the borrow checker was an academic idea. That's been around a lot longer than rest house.

And a lot of the package management like cargo , is the package manager and a lot of how cargo works was inspired by bundler and NPM which is another huge benefit over C and Cplus plus that don't have a standard package manager. Super hard to bring in libraries in

C and C Yeah, we talked about, I've looked into this recently because we released a feature like more stuff on Conan, which is a package manager for C but it's still a minority of C programmers that actually use Conan

it's mostly they, drop in the DLLs or they use CMake to sort of. To hack it to get, no, I don't want to, but

it's all, it's all ad hoc. There's not a standard. Every project has to invent it on its own. Yeah.

Yeah. So the fact that Rust came about where package management was more the thing to do, you didn't have to reinvent the wheel or like [00:14:00] you weren't there before package management, you kind of had all these things are coming together at the right time, like you

were saying.

Right. Yeah. So, so we're learning from previous mistakes. We're bringing it all together in a way that is, is, makes people more productive. Everyone is realizing that C and C are not working out. And, and like the compiler is just very supportive. It's I don't know. It's. It's strange to kind of anthropomorphize the compiler, but people talk about, you know, fighting with the borrow checker and the compilers kind of your pair programmer, who's always right.

And, but like there, there has been a lot of human work put into the compiler. Esteban fun blanking on his last name. He's Esteban Kay on. On github but he especially has put a whole lot of work into making the compiler errors [00:15:00] useful and like it, they pull in your code and say right here, this Scott needs to do this and where possible.

It says, have you tried maybe doing this? This might fix it? So, so it's fun watching people start to start to use rust and stuff like that. They're used to other languages where, you know, you get a screen of garbage when you get an error and they're like, they like ignore it and start guessing at what the problem is.

I'm like, no, no, no, no, no, no, no. Go read the error message. I promise these error messages are helpful. Like you have to change your habits and get used to going to read the error messages because people put a lot of work into making them better.

You're a compiler, but also a little bit of a therapist. You know,

yeah, and like another, another big thing that I think helps is Graydon Hoare.

It was his research project at Mozilla. And when he open sourced it, he hit one of his conditions was it had to have a code of conduct as part of [00:16:00] participating in the Rust community and which was kind of controversial at the time. And I feel like that's, it's. Slowly becoming less controversial. It's slowly becoming.

Oh, yeah, we should, we should have a code conduct. But we have a moderation team. I mean, we can always use more people to help with the moderation team because it's a thankless job. And but it's, it's something that the rest community has always taken seriously, which has been different from Other communities.

I know, I know, Linus Torvalds has had kind of a change of heart in the past few years, but he used to be famous for, you know, just tearing into people for their code with abuse. And like, he kind of set the tone for the community and systems programming was not not welcoming to people who are trying to learn.

And Russ, like the The tone that was set at the beginning was very different, and I think that has drawn in people who don't want to be yelled at all the time for trying to [00:17:00] learn. So I think we've benefited and, and gotten a lot of smart people who have been pushed out of other communities, and that has been a huge help, a huge driver of our success is that I mean, Ruby, Ruby is famously trying to be trying to optimize for developer happiness.

Which sometimes I feel like it goes a little too far. And it's like, like prioritizes developer happiness over things like performance or, but it's, I feel like Rust is, is like trying to be helpful, like, we're not going to, we're not saying it's going to be easy, like, systems programming is hard, but we're going to help you along the way the compiler is going to help you as much as it can and we're all going to make better code together.

Yeah, because one

thing I find is. Well, just personally, just sometimes to move from like, say you're a C or a C programmer to move to another language, it is, it's scary that, that, that journey, like [00:18:00] you were, you were king of the castle. Now you're back to square one. It's nice to, to be able to take up a language that recognizes that and doesn't treat you like dirt.

Cause

you don't know stuff. So. I think it's a worthy it's, it's worthy that this that ethos of being kind to people.

Yeah, and I mean, like, there's lots of, as you pointed out, there's lots of C and C code out there. There's going to be a lot out there for a long time. This is a big problem. And I am in favor of any, any way we can to help fix that problem.

Like, there are many smart people working on making C and C safer. Analyzing code at compile time and at run time. And sandboxing and, data analysis and proofs and, and, and other languages, like,

yeah. [00:19:00] OpenSF came up with a new like a a framework for improving the safety of your C and C code, like to do a compiler setting, something like that, which will eliminate a lot, well, a subset of vulnerabilities.

Yes. Like we need to approach this from every angle we can. Yeah. The one I like is, is writing new code in Rust and you can even do like incremental rewrites of C and C by using the foreign function interface. You, I did a talk where I took a C library and ported it over function by function and had it compiling and passing tests at every commit and slowly moved it from C to Rust.

It's possible. So you can start. Porting little pieces of your code, the, the parts that are processing untrusted input, the parts that crash the most often, the parts that change the most often you can start with that and and start getting the benefits of it without needing to do a [00:20:00] total rewrite, because those take a long time.

They're very risky and and you can't. You, you're spending time on that instead of new features. So, so that's the, that's the direction I'd like to take. I support everyone trying to do everything.

The next, you kind of answered the next question I was going to ask you is like, how would you approach.

Moving a big co base to Rust, I suppose you just answer that by bit by bit, start with prioritize the shakiest bits and move from there. But what do you think is the biggest hurdle for teams moving to a memory safe language?

So it, it is different the program and there is a learning curve. You mentioned the learning curve, which we're trying all the time to make that less steep to make new resources.

Like, you. The compiler will yell at you more if you're coming from C and C plus plus the compiler will yell at you more for things you that C and [00:21:00] C plus plus you do. And that will be weird. My partner actually was, was more of a C developer and. When he first started doing Rust he, he said he would write code the way he always wouldn't see and Rust would yell at him and he would say, but I've been writing this code this way for years.

Like, but why? And then, like, he learned more and understood more. And then he goes. Oh, I've been writing this code this way for years and it was wrong. So, so like it's kind of a shift. It's something different. And if you're coming from like a higher level language, like a Ruby or JavaScript Russ is going to ask you to think about things you're not used to thinking about.

Like how much memory do you need? Are you, are you just reading this or you can write it? Are you, where are you sharing this with? Like, are you done with this yet? Like strings. Dealing with strings and rest is a little more complicated than in other languages because of the memory management, because of the safety, [00:22:00] like, you have to kind of think about some things up front that you may be not used to thinking about in other languages.

But I, I'm of the opinion that this learning is worth it and I feel more productive. I'm definitely more productive than I would be in C or C so once you get there, I think it's worth it. And we're working all the time to get more people to that point. Yeah. It's a journey,

I suppose. Yes. And I do think that like, I saw I was watching a video on the AWS and, and they, their Q generative AI thing has like.

They say that you can use it to upgrade from like Java 7 to Java million. I don't know what it is, the latest one. Do you think like at some point, like we can use AI to just be like, update this to Rust from C do you, do you think, or at least maybe like a module or something, maybe start [00:23:00] similarly, how you would change a big code base, change something small.

Do you think that we will get to the stage where AI will, will be. Accelerating our move away from those memory unsafe languages.

Yeah, I, again, like any tool that will help us do this, I am in favor of there are existing tools predating this, the big LLM explosion here that will generate bindings to C and C for you.

There are tools that will attempt to translate. C and C to Rust. They're not perfect. They still need human review. But they can give you a place to start from. And I'm sure, I, I haven't really spent too much time with AI tools myself. I've heard they're good at things like generating tests, which all like fuzzers are also great generating tests and, and poking at holes and figuring out ways that you, like, you could generate a bunch of fuzz [00:24:00] funding tests against your existing code base, port things over, and then ensure that the code is still behaving the same.

So. Like that sort of tooling, I think is super helpful. And if LLMs can help people and, and I've heard of people using LLMs to like explain code to them too. Which that can also be helpful.

Right. Great. But a wrong comment is like yeah, sets you off in the wrong

direction. Right. But then there's the question of, is, is the LLM wrong?

Oh no. Like yeah, I'm not. I don't know. I'm a little skeptical of the whole thing. Yeah. But, but like, if it's working for you, keep going with a listener out there. More power to you. But yeah, it like, that might be a learning resource. to get into Rust is having an LLM explain it to you because like oftentimes the best way to learn is if you have someone you can ask questions to and they can look at what you're doing and [00:25:00] they can, they can ask you and figure out what your mental model is and figure out where that's not quite matching up.

So. But, you know, there's not, everyone can have access to an experienced Rust developer to ask questions to. We try, there's chat rooms and, and Stack Overflow and things like that. But if, if an LLM is able to do that for you, that can, that is. A resource you should take advantage of.

But thank you so much today, Carol.

You've enlightened us on how Rust in particular can help you eliminate those memory vulnerabilities in C and C and I'd like to thank so much for coming and sharing your insights and just to let people know you can be contacted and on mastodon I'll put a link to your book in the notes.

I'd like to encourage listeners to explore memory, safe languages especially Rust for that secure, robust software development. So thanks so much today and see you [00:26:00] next month. So

thank you.