RFC: Promote aarch64-unknown-linux-gnu to a Tier-1 Rust target

[raw-bin]

This commit contains an RFC proposal to promote the aarch64-unknown-linux-gnu Rust target to Tier-1.

Rendered

[CJKay]

Fantastic!

[nagisa]

I’m in support of this RFC.

[nikomatsakis]

cc @joshtriplett, who has been working on the general Tier RFC, and @rust-lang/compiler more generally.

[mbrubeck]

Should stack probes be required for all tier-1 platforms? See rust-lang/rust#43241 and rust-lang/rust#49355.

[Absolucy]

I'd really love to see more non-x86 targets become Tier 1!

[raw-bin]

I’m in support of this RFC.

Hi again @nagisa. Thank you for your support! :)

[raw-bin]

Should stack probes be required for all tier-1 platforms? See rust-lang/rust#43241 and rust-lang/rust#49355.

Hi and thanks for your comment.

As it happens, @alexcrichton recently reached out to highlight this gap. There is work pencilled in in Q3 to address this. There is an element of uncertainty involved though (the work is planned to be done as a part of the Linaro Toolchain Working Group and there is a vote involved). However stack probing support in LLVM for AArch64 Linux is understood to be a key requirement so servicing it is an inevitability.

Whether stack probing needs to be a gating feature for Tier-1 attainment is debatable. Given the ultra complex (to the point of being pathologically hard!) synthetic scenarios that need to be arranged in order to get an exploitable stack clash, I would state that the feature should be a high priority ask and not a gate.

Happy to discuss further.

Thanks.

[raw-bin]

I'd really love to see more non-x86 targets become Tier 1!

Me too! :)

[joshtriplett]

@mbrubeck What do you think of the following requirement (for addition to the target tier policy):

• The code generation backend for the target should not have deficiencies that
  invalidate Rust safety properties, as evaluated by the Rust compiler team.
  For example, if Rust relies on a specific code generation feature to support
  a memory safety property, the code generation for the target should support
  that feature. If this requirement does not hold, the target must clearly and
  prominently document any such limitations, such as via a footnote in the
  target tier list, and the Rust compiler team must be satisfied with the balance
  between these limitations and the difficulty of implementing the necessary
  features.

[zwhitchcox]

As someone installing servers on raspberry pi's new 64 bit images, this seems useful!

[Absolucy]

I'd really love to see more non-x86 targets become Tier 1!

Me too! :)

tbh I'd also love to see RISC-V targets gain a decent status, but as it's rather hard/expensive to get a RV64GC workstation right now, that'd be a bit hard

[cuviper]

Is it accurate to say that if we move to Tier 1 without stack probing support, we are effectively relaxing the guarantee of no UB without unsafe? Is there a more bounded statement we could make about what's possible in practice that's less scary?

At most, I'd call it a known soundness issue, of which there are many even on Tier 1. "Relaxing the guarantee" sounds like we would never intend to fix this, but really it would just be a pragmatic choice to say that this is not a hard blocker.

[raw-bin]

Hi @cuviper , @tmandry , @nagisa , @jonas-schievink and others on the approvals list: RFC author here. Thanks for the comments. All insightful and on point.

There's a couple of things I wanted to say by-the-by, in the spirit of this discussion and the broader RFC:

1. The guideline we used for structuring all the work done ahead of making this RFC submission was the existing target tier policy document and unfortunately in all the discussions we had, the stack probing aspect did not bubble up either directly or indirectly. It's clearly a gap that needs to be filled without doubt.

2. As mentioned earlier here: At present, work to add support for stack probing for AArch64 in LLVM is slated to begin in Q4 this year as a part of the Linaro Toolchain Working Group activities (link provided earlier). This unfortunately isn't a guarantee though (it involves a vote etc) so given the narrative here, we will now try to find alternative ways to fill this gap. I'm personally pretty confident that we will resolve this in a reasonable time frame. However it is not possible at present to state exactly when. From past experience, compiler mods of this sort do tend to drag on for a fair bit before landing in mainline repos given the potential implications for multiple triplets associated with the processor target in question.

3. As also mentioned earlier here: Stack clashing - the primary scenario for which stack probing is the mitigation - is an arguably pathological scenario to exploit. Not meaning to trivialise that scenario of course but I wanted to put that on the table as a fact that I feel should be considered when such decisions are made. I do realise that some of the argumentation that is being used around the lack of stack probing here is oriented somewhat differently - as in - it raises concerns about UB implications from a Rust PoV and not the stack clashing reality more directly. Still thought it best to bring it up. Completely agree that a clear problem has been presented irrespective and we would like to see the right solution happen - even if that means the RFC's merge is delayed.

4. About delay: This is a slightly unusual one to articulate in such a forum but I feel it is important to do so. Note that this is my personal opinion. It has taken a fair amount of engineering: actual, social and strategic, to get the right folks in an organisation such as Arm to recognise the value proposition that Rust presents for the Arm ecosystem. As is inevitably the case for any such organisation, perception and optics play a strong role in shaping the trajectory of long term strategic plays - especially around relatively new technology. Today, we know that Rust on AArch64 Linux is already being productised despite this target triplet not having the Tier-1 'badge' (for want of a better phrase). That bodes well already, which is neat. However, not having the badge does limit the rate of pervasive uptake of the language, especially on AArch64 based Linux systems - which are hugely popular across an astonishing spectrum of market domains - most of which are a perfect fit for Rust.

Would getting the badge in a hurry change that in a meaningful way ? Hard to say. That said, my experience in speaking with relevant parties in the Arm ecosystem leads me to maintain that the sooner we get the badge, the sooner we can usher in a lot of interest in Rust more generally and Rust on AArch64 Linux, more specifically.

We will of course respect the outcome of your decision, either which way. If you decide that the RFC merge needs to gate on stack probing availability in LLVM and it's coupling to Rust for AArch64 Linux, that's the direction we will move in. I felt it important to share the above points, all the same.

Thanks!

[skade]

I do agree with @cuviper's point that the absence of a desired feature should be filed as a bug instead of being considered a blocker to policy. Especially if a root issue is LLVM support.

Personally speaking, I would rather not have this promotion blocked on known technical details, as I see tier-labels rather as a statement of support and quality levels.

[tmandry]

At most, I'd call it a known soundness issue, of which there are many even on Tier 1.

Yes, but I would wager that most of those (at least, the ones that have been open for awhile) are fairly limited in scope. If not, they'd be P-critical and we'd be fixing it immediately.

What's the scope of this? Stack overflows can happen in many programs, and I've seen Rust functions with some very large stack frames (edit: these are the ones that need stack probes). It's not uncommon for programs to have a recursion level dictated by user input (e.g. parsers). So my question is about whether that can be exploited in the wild.

"Relaxing the guarantee" sounds like we would never intend to fix this, but really it would just be a pragmatic choice to say that this is not a hard blocker.

Fair enough. What I was trying to get across is that Rust programmers on Tier 1 targets enjoy freedom in practice from memory exploits when writing safe code. I'm just trying to make sure that remains the case.

Stack clashing - the primary scenario for which stack probing is the mitigation - is an arguably pathological scenario to exploit.

This may be true and I think it's an important point. Despite some of my earlier phrasing, my concern isn't about UB existing in the abstract, but about UB that can lead to high-severity exploits in reality. If it matters, I think it's also fair to consider any mitigations (like ASLR) that Linux enables by default, since this RFC is about Linux.

I'm not a security expert and I'd be happy to learn that this is pretty much impossible to exploit in practice :)

Personally speaking, I would rather not have this promotion blocked on known technical details, as I see tier-labels rather as a statement of support and quality levels.

I tend to agree with this. A statement of support I have no problem with, and I personally would like to see arm64 get promoted as soon as possible. It's clear that this is a platform of significant interest to Rust users and I count myself as one of them!

It's the quality level that I'm double checking here. I'd note that users' expectations around quality are shaped by the state of other Tier 1 targets. Even if they used to have this problem, most people have probably forgotten this, and Rust is more mature and stable overall than it was 3 years ago.

[skade]

I tend to agree with this. A statement of support I have no problem with, and I personally would like to see arm64 get promoted as soon as possible. It's clear that this is a platform of significant interest to Rust users and I count myself as one of them!

It's the quality level that I'm double checking here. I'd note that users' expectations around quality are shaped by the state of other Tier 1 targets. Even if they used to have this problem, most people have probably forgotten this, and Rust is more mature and stable overall than it was 3 years ago.

I think this is an important question! I think the main problem is that this question would not come up as a blocking question on a purely technical RFC like an API: it is clear that the API is not yet implemented. If this RFC is merged, is aarch64-unknown-linux-gnu immediately tier1 or is there an implementation issue that lists a number of things that need to be fixed before this RFC is considered "implemented"?

Also, statements of quality are also a statement about future issues, that we will care for them, that there's eyes and that issues may be release-blocking.

[raw-bin]

Hi @skade, @tmandry, @cuviper, @jonas-schievink, @pietroalbini, @nikomatsakis, others on the approvals list: I wanted to share that this commentary helped prioritise things. :)

I can now confirm that work to add probe-stack support to LLVM for AArch64 will officially begin from October 1st (so next week) with a dedicated expert assigned to implement this feature. The implementation will be funded by Arm and done up through Linaro (a not for profit alliance of Arm ecosystem partners).

This link which I've shared previously has some details (not all of them openly available sadly).

The relevant change is that the 'Fix/version(s)' attribute, which was previously empty has now been changed to 'LLVM 12'.

This means that the feature is now intended to be a part of the LLVM 12 release. Extrapolating from LLVM's release history, that is likely to be around Q2/Q3 next year. The Rust linkage can be developed in tandem, I suppose. I expect that the actual implementations will be available sooner in RCs etc but we should assume the release as the end-point for feature availability.

[raw-bin]

Hi folks.

I note from the commentary here that the general view on the topic at hand has oriented around the caveat posited in @joshtriplett's proposed upcoming draft of the Target Tier policy, and I quote:

The code generation backend for the target should not have deficiencies that
invalidate Rust safety properties, as evaluated by the Rust compiler team.
For example, if Rust relies on a specific code generation feature to support
a memory safety property, the code generation for the target should support
that feature. If this requirement does not hold, the target must clearly and
prominently document any such limitations, such as via a footnote in the
target tier list, and the Rust compiler team must be satisfied with the
balance between these limitations and the difficulty of implementing the
necessary features.

On that basis, I'd like to request @aidanhs, @estebank, @jonas-schievink, @nagisa, @nellshamrell and @pnkfelix to please either follow through with casting their vote in favour of this RFC here or to please share their counters so we can proceeed accordingly. Thanks!

[tmandry]

With stack probing being scheduled for implementation, my remaining concern is mismatched expectations. I think we could solve that with clear and explicit documentation.

[nagisa]

@rfcbot resolve should stack probes be implemented before this target is promoted

After some discussion we did not reach anything very conclusive but:

1. There's a person working on an RFC to better define the requirements for targets;
2. There were no objections to promoting the target and just filing an issue for lack of safeguards like stack probes.

hence resolving.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

The RFC will be merged soon.

[pietroalbini]

Huzzah! The @rust-lang/compiler @rust-lang/infra @rust-lang/release teams have decided to accept this RFC.

To track further discussion, subscribe to the tracking issue here: rust-lang/rust#78251

[raw-bin]

Awesome! :) Thanks everyone for all the feedback and support! :)

[jjpe]

Would it be possible to update the link in the first post? Currently it's broken unfortunately.

[pietroalbini]

Updated the rendered link!