Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Open Sourcing Ferrocene

ferrous-systems.com

Post reply on HN
Print view View original

11–20 of 20 posts

Re: Open Sourcing Ferrocene

#11

Post by Xylakant »

miloignis wrote: post #9
andrewl-hn wrote: post #4

Ken Thompson talked about compilers potentially injecting code in final programs in his Turing Award lecture [1]. That's why compilers need to be certified in order for the software built by these compilers also receive certification. It's a great step for Rust! [1]: https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...

The best defense against a trusting-trust-attack that I am aware of is Diverse Double-Compilation: https://dwheeler.com/trusting-trust/ It's a simple idea, but can be surprisingly tricky to get exactly the right. Basically, you bootstrap from multiple disconnected and diverse systems and then do pairwise binary comparisons of the bootstrapped program on each of those systems. (This only matters after you've checked t…

There's an issue open on the rustc issue tracker that describes what's missing https://github.com/rust-lang/rust/issues/48707 (reproducible builds is the big one)

Re: Open Sourcing Ferrocene

#13

Post by mbStavola »

Considering that Ferrocene has been open sourced (or at least, will be) and Adacore announced the (seemingly) closed source GNAT Pro for Rust, it looks to me that maybe the two organizations couldn't agree on a path forward regarding source availability and parted ways. Even this post mentions that the current version of Ferrocene needs to have some "proprietary partner work" scrubbed before a proper open source release can occur.

Re: Open Sourcing Ferrocene

#14

Post by steveklabnik »

0xDEF wrote: post #12

Interesting that they only support x86-64 and aarch64/ARM64. I would have thought the majority of safety critical systems are on bare-metal ARM32.

On Lobsters, Pietro says

> For the first iteration we wanted to keep the set of supported targets small and focus on obtaining qualification, so 23.06 will include only support for ARMv8-A. Now that we achieved qualification though, we will work to expand support for other architectures and operative systems (including QNX).

and

> The current target is “bare metal” (aka without libstd) ARMv8-A.

https://lobste.rs/s/pcbjzj/open_sourcing_ferrocene#c_h4fmyo

Re: Open Sourcing Ferrocene

#15

Post by wyldfire »

Xylakant wrote: post #10
thesuperbigfrog wrote: post #8

Hopefully the work on Ferrocene can contribute to the standardization of the Rust language. Tracking issue: https://github.com/rust-lang/rust/issues/113527

This is explicitly a non-goal. Ferrocene considers itself a certified downstream of the rust project and as such we certified the rust compiler as it was at 1.68. There's no effort or push to standardize the language from our side. As part of the certification efforts, we had to write a spec since some description of the language is required. But this spec is a descriptive spec, describing the intended behavior of th…

Is there any high-level description of the downstream changes in ferrocene and a roadmap of which changes could be upstreamed and which would probably "never" be acceptable upstream?

Re: Open Sourcing Ferrocene

#16

Post by Xylakant »

wyldfire wrote: post #15
Xylakant wrote: post #10

Earlier quoted context omitted.

This is explicitly a non-goal. Ferrocene considers itself a certified downstream of the rust project and as such we certified the rust compiler as it was at 1.68. There's no effort or push to standardize the language from our side. As part of the certification efforts, we had to write a spec since some description of the language is required. But this spec is a descriptive spec, describing the intended behavior of th…

Is there any high-level description of the downstream changes in ferrocene and a roadmap of which changes could be upstreamed and which would probably "never" be acceptable upstream?

> Is there any high-level description of the downstream changes in ferrocene:

The list of relevant changes to the compiler is the empty set. We wanted to certify the compiler without forking it or restricting the supported language features.

We do build and test some targets to a higher tier level than upstream rust and do have support for custom proprietary targets which the rust project will never support (1), but that makes for a tiny change set. (Measured in literally tens of lines).

Most of Ferrocene is the LTS support and the qualification documentation, both of which upstream has no interest in providing. The documentation also describes our QA process and unless you’ll adopt our procedures, you’ll have to adjust the documentation and then re-certify.

(1) to a large extend because the rust project cannot sign an NDA and support proprietary hardware in its CI.

Re: Open Sourcing Ferrocene

#19

Post by ngrilly »

Kudos to the team! I'm almost sad that I'm not working anymore on a Battery Management System, requiring functional safety, as I was considering transitioning from C to Rust and that's how I came to learn about Ferrocene :)

Re: Open Sourcing Ferrocene

#20

Post by brobecke »

mbStavola wrote: post #13

Considering that Ferrocene has been open sourced (or at least, will be) and Adacore announced the (seemingly) closed source GNAT Pro for Rust, it looks to me that maybe the two organizations couldn't agree on a path forward regarding source availability and parted ways. Even this post mentions that the current version of Ferrocene needs to have some "proprietary partner work" scrubbed before a proper open source rele…

> Adacore announced the (seemingly) closed source GNAT Pro for Rust

I just wanted to clarify all AdaCore products are open source. Including of course GNAT Pro for Rust.

Post reply on HN