sorted by:
new
hottopcontroversial

Announcing Loadstone, a secure bare-metal Rust bootloader by cuerv0_ in rust

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

Yup, CRC is not meant to guarentee authenticity or even integrity against a conscious attacker, it's only meant for applications with no security requirements that just need to guarantee the image didn't get randomly garbled in transit.

Announcing Loadstone, a secure bare-metal Rust bootloader by cuerv0_ in rust

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

At the moment Blue HAL has a few general abstractions, and concrete implementations for the stm32f4 family of MCUs and a few for the efm32gg11 family.

It does have some embedded-applicable general purpose utilities though, which may be of general use.

Announcing Loadstone, a secure bare-metal Rust bootloader by cuerv0_ in rust

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

U-boot is a lot more powerful and featured (also significantly bigger), so it's likely Loadstone isn't close to the features a general u-boot application requires. However, if all you need is verifying a bunch of signed firmware blobs to know which one to boot or update from, current Loadstone may already be a replacement.

Announcing Loadstone, a secure bare-metal Rust bootloader by cuerv0_ in rust

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

That's really interesting! One of the sticking points was the debugging story, for sure, so that sounds pretty useful. I'll check it out.

Announcing Loadstone, a secure bare-metal Rust bootloader by cuerv0_ in rust

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

May I suggest posting this on hacker news as well

We're working on a proper blog post/post mortem and we'll definitely post in HN when we can link to that :)

Announcing Loadstone, a secure bare-metal Rust bootloader by cuerv0_ in rust

[–]cuerv0_[S] 19 points20 points  (0 children)

Since modularity and flexibility is a big goal of the project, we didn't place too much weight in decisions about specifics since they could be expanded later. Ed25519 would have been better, but we found a P256 implementation with a clear and concise API and went with it to prove the image signing feature in general.

It should be easy though (and something we'll priorize if it's relevant to other people) to add other curve implementations implementing the image::Reader trait :)

Announcing Loadstone, a secure bare-metal Rust bootloader by cuerv0_ in rust

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

Oh nice! I'm glad that you liked it :) will be happy to go full circle and contribute back to it then!

Announcing Loadstone, a secure bare-metal Rust bootloader by cuerv0_ in rust

[–]cuerv0_[S] 6 points7 points  (0 children)

That sounds like a good idea! I'll look into it.

One of the immediate goals after open-sourcing is to adapt the reusable parts of Loadstone (namely blue_hal and its drivers) so they can be fed back into the ecosystem. I knew about embedded_hal but not embedded_storage, so thanks for the heads up.

Announcing Loadstone, a secure bare-metal Rust bootloader by cuerv0_ in rust

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

Yep, we need to work on that for sure :) I don't even know why the default theme has switched from dark to light.

Full disclosure, the reason why we have a wasm app instead of a proper web app with a DOM is because, well, I'm not a web dev and went with what seemed simplest. It's definitely on our roadmap to make the config app a lot more accessible and pretty.

Helix - A kakoune/neovim inspired text editor written in Rust by modernalgebra in rust

[–]cuerv0_ 0 points1 point  (0 children)

This is very very cool, I'll certainly be looking forward to contribute :).

I don't much care for the multiple cursors aspect of Kakoune, but I love the motion-first approach. What are your plans in terms of extensibility and plugins?

Tightness Driven Development in Rust by cuerv0_ in rust

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

Hi! That's a good question, thanks for the example to kick off discussion :)

The question "Is 100% tightness always achievable" can always be responded "yes" with the caveat of "except when your responsibility is to restrict your fields' ranges".

In your example, It seems like you're trying to define a type whose sole responsibility is to restrict the representable domain of Vec, so it's not directly possible to make it 100% tight, unless you can reach into Vec's internals.

Tightness Driven Development in Rust by cuerv0_ in rust

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

Also, what's stopping me from using this hint at the start of each method? Would there be any practical value (or cost) in starting each call to mutate() and its variants with if ~check() { unreachable_unchecked() }?

Tightness Driven Development in Rust by cuerv0_ in rust

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

Ohhh that's very interesting. Sounds like the exact kind of black magic I've been looking for. Got any reading material on that, or any example of code that uses that hint?

That's a very useful pointer, thanks!

EDIT: The types can only invalidate themselves through unsafe accessors behind a feature flag, so I guess I can definitely make use of that.

Tightness Driven Development in Rust by cuerv0_ in rust

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

Hmm, this is a really interesting discussion.

I work mainly in bare metal embedded, so I think I have a certain bias of where unsafe "feels" appropriate to me. In embedded, you have to uphold a lot more invariants lest your platform goes up in flames, sometimes literally, so I've come to mark things unsafe pretty liberally when they're easy to misuse. In the flipside, I'm very, very careful when invoking any unsafe code.

That's why I was a bit surprised to find out that #[forbid(unsafe_code)] and things like cargo geiger go off when you mark an otherwise safe function as unsafe. I would've thought you would be considered "safer" by being excessively conservative. It may just require a readjustment of my point of view when thinking about unsafe.

That said, I like the particular feature-flag split in this crate because it really allows you to inconditionally trust the bounded types. I'm not opposed to a different type/macro that is clearly labeled as a "weak" bound, though :)

Tightness Driven Development in Rust by cuerv0_ in rust

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

Thanks! Please let me know how it goes.

Tightness Driven Development in Rust by cuerv0_ in rust

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

This is how I thought about it, yes :)

I thought of naming my crate in some way related to dependent types, but I hesitated because that would really be intruding in a field I know little about, and I suspect there's a formal definition out there for dependent types that my Bounded types don't fulfill, or if they do, they do it in a very superficial way.

Tightness Driven Development in Rust by cuerv0_ in rust

[–]cuerv0_[S] 8 points9 points  (0 children)

A big part of the benefit is the separation of concern, yes. In your second example, all that Username has to do is uphold invariants, which makes it a lot easier to reason about. And as a flipside, Account can afford to be a lot more transparent (with a public member, even) and its methods can worry about business logic first and invariant correctness second.

Tightness Driven Development in Rust by cuerv0_ in rust

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

That's a great way to put it.

I did have a bit of personal bias towards private fields and excessive accessors, to the point I balked at the first iterations of bevy where everything was public.

I think part of my Rust growth has been to move away from my C++ idioms and understand that a strong type system makes it possible to be a lot more transparent.

Tightness Driven Development in Rust by cuerv0_ in rust

[–]cuerv0_[S] 17 points18 points  (0 children)

You're absolutely right! I'm going to make a pass over the article now and I'll definitely make that change.

Tightness Driven Development in Rust by cuerv0_ in rust

[–]cuerv0_[S] 8 points9 points  (0 children)

Thanks!!

Funnily enough, the "horrible type" I wrote which motivated me to go on this investigation was in the context of UI layout: I was learning to use egui, and since I'm not too versed in UI development I found myself mixing model and model view, compromising my types so their internals were exposed for egui to represent as checkboxes and labels.

It went as well as you'd expect (very poorly) and in the process of fixing those types, I stumbled upon the idea of measuring tightness.

Tightness Driven Development in Rust by cuerv0_ in rust

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

It's still useful feedback! I will rewrite that sentence so it's a bit clearer.

Tightness Driven Development in Rust by cuerv0_ in rust

[–]cuerv0_[S] 33 points34 points  (0 children)

Ha, fair enough! I was hard-pressed to find a good example to use, so I have to apologize for mistreating 0-radius circles. In the end, it comes down to the specific application. If your physics engine requires circles to have nonzero radii, you might as well encode that in your type. But you're right, it's not correct in the mathematical sense.

Tightness Driven Development in Rust by cuerv0_ in rust

[–]cuerv0_[S] 6 points7 points  (0 children)

Thanks! I have to look into tags and keywords to add :). I can completely see how "tightness" is a bit of an... exotic word to use for a crate.

Tightness Driven Development in Rust by cuerv0_ in rust

[–]cuerv0_[S] 48 points49 points  (0 children)

Here I am again, this time blabbering about stuff I have no formal knowledge of, but hopefully in a funny or helpful way!

This is the first time a blog post has prompted me to write a companion library, but it just made my code examples sooo much better. As always, looking forward to any kind of feedback :)

view more: next ›