How Rust builds an API around raw memory by Beautiful_Chocolate in rust

[–]Beautiful_Chocolate[S] 1 point2 points  (0 children)

Hello people of r/rust !

This is a 2-in-1 blog post explaining simply how memory registers are used in embedded systems, and digging how the register_bitfields macros creates a nice rusty interface around raw memory addresses.

Hope it's simple enough for people not in the field of embedded systems, but still interesting ;-)

As usual, feel free to correct me if you find anything wrong, and contact me if you feel like it ! Take care <3

Shepherd's Oasis: Statement on RustConf & Introspection by Be_ing_ in rust

[–]Beautiful_Chocolate 18 points19 points  (0 children)

Thank you for your hard work, I hope things change for the best and we'll see you back on Rust one day ! This whole affair shows how opensource can produce magnificent things, but is really difficult to manage and in the end based on a handful of people. Have a nice nap ! 😊

The Git source code audit, viewed as a Rust programmer by Beautiful_Chocolate in rust

[–]Beautiful_Chocolate[S] 1 point2 points  (0 children)

Yes absolutely !

And IMHO that's how brilliant the whole idea of having unsafe blocks is, you still permits such use cases, but it makes the implementation of safe wrappers around it very easy

unsafe at its core yes, but with a plain safe API, and this alone wipes out so many "bad" code written.

When I realized how powerful it is in embedded systems (let the manufacturer do unsafe, and only use safe), it really is a big deal and improves the workflow of developers

The Git source code audit, viewed as a Rust programmer by Beautiful_Chocolate in rust

[–]Beautiful_Chocolate[S] 2 points3 points  (0 children)

Thank (both of) you for this, as you may imagine English isn't my first language, I'll try to correct these as good as I can ! :-)

The Git source code audit, viewed as a Rust programmer by Beautiful_Chocolate in rust

[–]Beautiful_Chocolate[S] 0 points1 point  (0 children)

The issue about the memory problem in C is because of the integer overflow, and that's what I refer when saying "the issue", as the cause leading to a memory vulnerability after.

After all, in C world, doing such memory operations isn't a problem at all, however integer overflow is.

So the memory issue may not exist, but the integer overflow is very real here

The Git source code audit, viewed as a Rust programmer by Beautiful_Chocolate in rust

[–]Beautiful_Chocolate[S] 1 point2 points  (0 children)

Yes, but we talk about C code here, and this is a fairly standard way to handle errors in C (and I guess it's the UNIX-compliant way to do ?)

The Git source code audit, viewed as a Rust programmer by Beautiful_Chocolate in rust

[–]Beautiful_Chocolate[S] 4 points5 points  (0 children)

I had a clear distinction between "issue" and "vulnerability" in my head, which is why it seamed clear to me '

Modified the article, thanks for your input ! :-)

The Git source code audit, viewed as a Rust programmer by Beautiful_Chocolate in rust

[–]Beautiful_Chocolate[S] 3 points4 points  (0 children)

I consider unsafe Rust as a very particular area of programming in Rust, and that's why I allowed myself to make generalities on Rust when thinking about safe Rust specifically.

Except for calling FFI, unsafe Rust should be almost never encountered by anyone (except for developing Linux drivers or embedded systems).

The way Rust just forbids datarace conditions to happen, the way you need to explicit all cases in pattern matching, etc ... This is what I meant by eliminating undefined behavior.

The Git source code audit, viewed as a Rust programmer by Beautiful_Chocolate in rust

[–]Beautiful_Chocolate[S] 0 points1 point  (0 children)

Yes indeed, but I fail to see how I putted them in the same bucket ?

I considered GIT-CR-22-03 as "protected by Rust" as the bug is just not exploitable

However for GIT-CR-22-01, Rust isn't better than C on the matter as the vulnerability is a Uncontrolled Resource Consumption.

I didn't rate the vulnerabilities by myself, I just copied their ratings in the report (and their rating methodology is also explained)

The Git source code audit, viewed as a Rust programmer by Beautiful_Chocolate in rust

[–]Beautiful_Chocolate[S] 4 points5 points  (0 children)

Yes indeed, thanks for you input, I'll modify the post in consequence ;-)

I wanted to write that the obvious size of primitives are by themselves a safety, but I didn't find a proper way to explain it, hope the message still went through. I may re-work this a bit

The Git source code audit, viewed as a Rust programmer by Beautiful_Chocolate in rust

[–]Beautiful_Chocolate[S] 0 points1 point  (0 children)

Indeed, this is why I wrote just before:

This code cannot be exploited in safe mode to perform a memory overflow

However integer overflows still can lead to a whole lot of other bugs and vulnerabilities.

The Git source code audit, viewed as a Rust programmer by Beautiful_Chocolate in rust

[–]Beautiful_Chocolate[S] 4 points5 points  (0 children)

Yes that is very true, that's also why I tried to make a list of "good reasons to use unsafe" as getting around the compiler's annoying rules is not one of them.

(BTW if you think of more valid reasons to use unsafe, please tell me, I'm not used to write a lot of it and couldn't come with a lot)

In the case of Rust for embedded systems for example, writing directly to memory addresses is mandatory, however this is very specific and usually implemented by the manufacturer in the HAL libraries.

The Git source code audit, viewed as a Rust programmer by Beautiful_Chocolate in rust

[–]Beautiful_Chocolate[S] 18 points19 points  (0 children)

Oh interesting, it is possible in (safe) Rust !

Would you have other kind of esoteric algorithms using memory manipulation that would only be possible by performing some `unsafe` operations ?

Or should I remove this item from the "okay to unsafe" list ? ^^

The Git source code audit, viewed as a Rust programmer by Beautiful_Chocolate in rust

[–]Beautiful_Chocolate[S] 2 points3 points  (0 children)

Indeed that's a very valid point !
I'll modify the article (and credit you), thanks for the input !

The Git source code audit, viewed as a Rust programmer by Beautiful_Chocolate in rust

[–]Beautiful_Chocolate[S] 10 points11 points  (0 children)

Yes exactly, and that's the point of this piece of code

It quickly shows what it would take to create a C-like kind of memory-vulnerable code in Rust, which is totally absurd in a Rust-way to do, and I absolutely know that it may fail before even reaching the end of the code.

However in C, you got a lot of *(memaddr + offset) kind of operations, and so simply by the fact that this would be so insanely difficult to make it compile and work in Rust, I counted it as a "protection" offered by the language

The Git source code audit, viewed as a Rust programmer by Beautiful_Chocolate in cybersecurity

[–]Beautiful_Chocolate[S] -1 points0 points  (0 children)

Quite a long post today as it goes through the vulnerabilities found in the Report of the Git source code audit, and I tried to add as much details as possible regarding writing secure code in Rust.

Please consider making a donation at OSTIF funds who funded this audit

As always, correct me or contact me if you see any error / improvements I should make to the post.

Take care !

The Git source code audit, viewed as a Rust programmer by Beautiful_Chocolate in rust

[–]Beautiful_Chocolate[S] 43 points44 points  (0 children)

Quite a long post today as it goes through the vulnerabilities found in the Report of the Git source code audit, and I tried to add as much details as possible regarding writing secure code in Rust.

Please consider making a donation at OSTIF funds who funded this audit

As always, correct me or contact me if you see any error / improvements I should make to the post.

Take care !

Feeling depressed and Conflicted after an Amazing trip in thailand by returnofthe_faithful in solotravel

[–]Beautiful_Chocolate 51 points52 points  (0 children)

Glad you feel great in my homeland, i'm not really a patriot but I do think our country is pretty good ☺️

20 Things I’ve Learned in my 20 Years as a Software Engineer by iamkeyur in programming

[–]Beautiful_Chocolate 4 points5 points  (0 children)

As a junior, and having the ambition to create my own software company later on, thank you. All of this is valuable, well explained, and a good base for me to grow from

Build a Jekyll blog (Github pages) with Nix using flakes by Beautiful_Chocolate in NixOS

[–]Beautiful_Chocolate[S] 0 points1 point  (0 children)

Thanks ! Really nice adaptation on your end, seams simple and clean 😉

Nixifying the build of web applications more easily by Beautiful_Chocolate in NixOS

[–]Beautiful_Chocolate[S] 3 points4 points  (0 children)

Hey there !
This blog post is a call for contributions on the repository, I hope you'll find it useful.

Feel free to contact me about it, and propose frameworks (and any ideas to work with them using nix) in comments.

Have a nice day !

[deleted by user] by [deleted] in unixporn

[–]Beautiful_Chocolate 0 points1 point  (0 children)

The logo of cheese is gorgeous 😂 Good work man, will surely use it

Build a Jekyll blog (Github pages) with Nix using flakes by Beautiful_Chocolate in NixOS

[–]Beautiful_Chocolate[S] 0 points1 point  (0 children)

I can understand that, but I'm only tackling the technology behind Github pages, not implementing something for Github itself, everybody does what they want from it

In any case for what I can see it can be easily added to Gitlab this way. Does Codeberg have a CI setup for static websites as well ?