Hieu Xuan Leu (Brian)


SWE at Delegate Labs (based Sydney)
🇻🇳 🇦🇺
Share: 

[vn] Apple đang đưa Swift vào kernel như thế nào?

Sau WWDC26, có một chi tiết nhỏ nhưng rất đáng chú ý xuất hiện trong cộng đồng Apple developer: Apple đã bắt đầu viết một số phần của kernel bằng Swift cho các bản phát hành “27”.

Thông tin này ban đầu được Devon Maloney chia sẻ trên X. Ý chính của bài đăng là: với thế hệ OS 27, Apple đã bắt đầu đưa Swift vào một vài phần của core operating system kernel, như một bước đầu tiên hướng tới một kernel an toàn bộ nhớ hơn.

Nghe qua thì rất lớn.

Nhưng nếu hiểu theo kiểu “Apple đang rewrite XNU bằng Swift” thì lại chưa chính xác.

Một bài phân tích reverse engineering của Josh Maine trên Substack đã bóc tách kỹ hơn chuyện này. Bài viết cho thấy Apple đúng là đang chuẩn bị hạ tầng để Swift có thể chạy trong không gian kernel, nhưng phạm vi hiện tại vẫn rất thận trọng: Swift mới xuất hiện ở tầng kernel extension thông qua một thứ có tên là KernelKit, chứ chưa thay thế phần lõi C/C++ của XNU.

Từ một dòng tweet đến KernelKit

Tweet của Devon Maloney có thể xem như tín hiệu công khai đầu tiên: Apple đã có dự án “Swift for the Kernel” và mục tiêu dài hạn là tiến gần hơn tới một kernel memory-safe.

Điều này hợp lý nếu nhìn vào hướng đi nhiều năm gần đây của Apple. Swift được thiết kế với nhiều đặc tính an toàn hơn C/C++, đặc biệt là quanh ownership, type safety và memory safety. Apple đã dùng Swift ở tầng app, framework, tooling, server-side, embedded, và trước đó cũng từng có các nỗ lực liên quan tới Secure Enclave.

Phần thú vị là: Swift vào kernel bằng cách nào?

Theo phân tích của Josh Maine, khi kiểm tra macOS 27 beta, tác giả không tìm thấy bằng chứng rằng lõi XNU đã được viết lại bằng Swift. Thay vào đó, ông tìm thấy một runtime của Embedded Swift nằm trong com.apple.kec.pthread, rồi lần tiếp theo lần ra một cấu trúc mới trong hệ thống có tên KernelKit.

Trên macOS 27, bên cạnh /System/DriverKit, xuất hiện thư mục /System/KernelKit. Bên trong có các kernel extension như Libm.kextpthread.kext. Các metadata của chúng nhắc tới một internal SDK tên kernelkit.macosx27.0.internal, cùng các target build riêng như libpthread_kernelkitLibm_kernelkit.

Nói cách khác, Apple dường như đang tạo một lane riêng cho các thành phần kernel có thể build với toolchain/SDK KernelKit.

KernelKit giống một bước đi kiểu DriverKit

Điểm đáng chú ý là cách Apple tổ chức KernelKit khá giống cách họ từng giới thiệu DriverKit: có thư mục riêng dưới /System, SDK riêng, platform riêng, và toolchain biết cách xử lý target đó.

Trong Mach-O, các binary KernelKit có LC_BUILD_VERSION với platform ID mới. Theo bài phân tích, Xcode 27 beta linker chứa thêm các platform mới:

Điều này cho thấy Apple không chỉ thử nghiệm riêng trên macOS. Họ đã chuẩn bị định danh platform cho nhiều OS khác nhau trong hệ sinh thái.

Tuy nhiên, việc có platform ID không đồng nghĩa mọi hệ điều hành đã có Swift runtime trong kernel. Ở thời điểm bài phân tích, macOS là nơi thấy rõ runtime Embedded Swift được link vào pthread. iOS 27 đã có binary KernelKit platform, nhưng chưa thấy Swift runtime được link vào theo cùng cách.

Embedded Swift trong kernel, nhưng chưa ai gọi tới

Phần kỹ thuật quan trọng nhất nằm ở pthread.kext của KernelKit trên macOS 27.

Josh Maine đối chiếu UUID giữa binary trong /System/KernelKit và entry trong kernelcache, rồi kết luận rằng build KernelKit của pthread thật sự được đưa vào kernelcache. Binary này có một số symbol Swift như swift_retain, swift_release, swift_once, swift_dynamicCast, cùng nhóm symbol của Embedded Swift runtime.

Nhưng đây vẫn chưa phải là “kernel đang chạy logic Swift” theo nghĩa rộng.

Tác giả kiểm tra cross-reference và nhận thấy các symbol Swift này hầu như không được component nào khác trong kernelcache gọi tới. Runtime đã được link, đã được load khi boot, nhưng về cơ bản vẫn đang nằm đó như hạ tầng chuẩn bị sẵn.

Đây là điểm rất quan trọng: Apple có vẻ đang đưa runtime và plumbing vào trước, quan sát trong vài beta cycle, rồi sau đó mới dần đưa các component Swift thực sự vào dùng runtime đó.

Đó là cách rollout rất Apple: nhỏ, kiểm soát được, và giảm rủi ro ở tầng hệ thống cực kỳ nhạy cảm.

Libm xuất hiện để làm gì?

Bên cạnh pthread, Libm cũng được build dưới KernelKit. Libm không có Swift symbol riêng, nhưng nó cung cấp các hàm toán học như nhóm xử lý floating-point.

Một cách hiểu hợp lý là: nếu Swift trong kernel cần xử lý các phép toán với Double hoặc Float, runtime/toolchain sẽ cần một tập thư viện nền tảng tương ứng để link. Vì vậy Libm_kernelkit có thể là một phần của bộ hạ tầng hỗ trợ Swift trong môi trường kernel.

Nó chưa chứng minh có nhiều code Swift đang chạy. Nhưng nó cho thấy Apple đang chuẩn bị đủ mảnh ghép để Swift có thể tồn tại nghiêm túc trong môi trường này.

Vậy XNU đã chuyển sang Swift chưa?

Câu trả lời ngắn gọn: chưa.

Theo bài Substack, phần lõi XNU vẫn là C/C++. Các compile unit trong debug symbol của kernel vẫn cho thấy C11, C++14 và một phần assembly, không có Swift. Điều này làm rõ một hiểu nhầm dễ xảy ra sau tweet ban đầu: “viết một số phần kernel bằng Swift” không có nghĩa là Mach, BSD hay IOKit đã được rewrite.

Hiện tại, Swift xuất hiện ở rìa hệ thống hơn là ở lõi: cụ thể là trong các KernelKit kext và Embedded Swift runtime.

Nhưng điều này không làm câu chuyện kém quan trọng.

Ngược lại, nó cho thấy Apple đang mở một con đường mới: thay vì thay toàn bộ kernel bằng Swift trong một lần, họ xây hạ tầng để từng component phù hợp có thể chuyển sang Swift khi đã đủ an toàn.

Vì sao chuyện này quan trọng?

Kernel là nơi một lỗi memory corruption có thể trở thành lỗi bảo mật nghiêm trọng. C và C++ cho phép kiểm soát rất thấp, nhưng cái giá là rất dễ mắc lỗi quanh lifetime, pointer, buffer, race condition và undefined behavior.

Swift không tự động biến mọi thứ thành an toàn tuyệt đối, đặc biệt khi đi xuống tầng hệ thống thấp. Nhưng Swift có thể giảm một lớp lớn lỗi memory safety nếu được dùng đúng cách, nhất là với một phiên bản Embedded Swift được tối ưu cho môi trường không có đầy đủ runtime như app user-space.

Điểm mình thấy đáng chú ý là Apple không chọn một cú nhảy ồn ào. Họ đang làm một việc khó theo cách có thể kiểm soát:

Với mình, đây là một tín hiệu mạnh hơn một announcement marketing. Nó là dấu vết của một migration dài hạn.

Tổng hợp hai bài viết

Bài đăng trên X là thông điệp ngắn: Apple đã bắt đầu đưa Swift vào một số phần kernel trong thế hệ OS 27, với mục tiêu tiến tới kernel an toàn bộ nhớ hơn.

Bài phân tích của Josh Maine trả lời câu hỏi “đưa vào như thế nào?” bằng các bằng chứng reverse engineering:

Vì vậy, cách diễn đạt chính xác nhất có lẽ là:

Apple chưa chuyển kernel sang Swift, nhưng Apple đã bắt đầu đặt nền móng để Swift có thể đi vào kernel một cách có kiểm soát.

Kết luận

Mình nghĩ đây là một trong những thay đổi nền tảng đáng theo dõi nhất sau WWDC26.

Nó không phải thứ developer iOS sẽ dùng ngay trong app hằng ngày. Nó cũng không phải một API mới để mở Xcode lên và thử trong vài phút.

Nhưng ở tầng platform, đây là một tín hiệu lớn.

Nếu Apple tiếp tục hướng này, trong vài năm tới chúng ta có thể thấy ngày càng nhiều thành phần hệ thống được viết bằng Swift hoặc Embedded Swift, đặc biệt ở những nơi memory safety mang lại giá trị bảo mật rõ ràng.

Điều thú vị nhất là Apple đang làm điều đó từ dưới lên: không phải bằng một tuyên bố “kernel mới viết bằng Swift”, mà bằng SDK, linker, runtime, platform ID, kernelcache và những binary rất nhỏ.

Đôi khi tương lai của platform không xuất hiện trên slide lớn nhất của keynote.

Nó nằm trong một LC_BUILD_VERSION, một internal SDK, và vài chục symbol Swift đang im lặng chờ được gọi.

Nguồn tham khảo:

, , , , , , ,