Swift support for Apple Silicon Macs

Development Announcements
1

Apple announced today the forthcoming release of Macs based on Apple Silicon. Apple will bring support for this new target to open source in both the Clang and Swift compilers, as well as LLDB. The process will start immediately.

The first step will be to upstream support for the new Mac target to the LLVM project. The first patch is up for review.

Afterward, the corresponding changes will land in the Swift project (compiler, SwiftPM, Standard Library, etc).

49 Likes
2

Swift build for Silicon :smiley:

3

Is the arch(???) test name set yet? I went through the phab patch and couldn't find anything. Will this need to go through evolution review or will there be an obvious name selected internally under the Apple umbrella?

4

arch() :star_struck:

5

The triple in the patch is arm64-apple-macosx11.5.8, so I would assume the architecture is arm64.

So the same architecture name as recent iOS devices.

3 Likes
6

It's the same ABI in all respects that I can think of off the top of my head.

6 Likes
7

The pull request for Swift is up now.

5 Likes
8

As someone that doesn’t know really anything about different arm architectures, I notice that sometimes arm64 is listed in supported architectures for macOS, sometimes arm64e, and sometimes both. What’s the difference?

9

arm64e is arm64 with pointer authentication.

More info here: Preparing your app to work with pointer authentication | Apple Developer Documentation

While you can’t yet distribute arm64e binaries, you can test your app with them during development in preparation for when they become part of Xcode’s standard build process.

2 Likes
10

Also, slightly off topic but in the same vein, there was an LLVM session last year about this arch and pointer authentication with @John_McCall . 2019 LLVM Developers’ Meeting: A. Bougacha & J. McCall “arm64e: An ABI for Pointer Authentication ” - YouTube

1 Like
11

There’s also this document in the LLVM repo (again by JMC), which goes in to more depth about what kind of things are signed (e.g. heap destructors). Very little code interacts with these directly, so for almost everybody, pointer authentication won’t require any code changes.

Apple have apparently been using this internally since iOS 12, and Google’s Project Zero have some practical examples which show how this can make attacks much more difficult.

PAC remains a solid and worthwhile mitigation. Apple's hardening of PAC in the A12 SoC, which was clearly designed to protect against kernel attackers with read/write, meant that I did not find a systematic break in the design and had to rely on signing gadgets, which are easy to patch via software ... I believe it's possible for Apple to harden their implementation to the point that strong forgery bypasses become rare.

But yeah, it’s a little bit off-topic.

1 Like
12

Note that it enables a little bit more than just PAC; of particular interest to me, it also implies the ARMv8.3 ISA extensions including native Float16 arithmetic:

func foo(_ x: Float16) -> Float16 {
  x + 1
}

Compiled for arm64, this generates:

_$s4neon3fooys7Float16VADF:
fcvt s0, h0          // Float(x)
fmov s1, #1.00000000 // conjure 1.0
fadd s0, s0, s1      // result = Float(x) + 1 
fcvt h0, s0          // Float16(result)

But if we compile for arm64e instead, we get:

fmov h1, #1.00000000 // conjure 1.0
fadd h0, h0, h1      // x + 1

There's a bunch of other small niceties that come along with it, but native Float16 arithmetic is a big one.

10 Likes