GrapheneOS phát hiện lỗi hỏng bộ nhớ Bluetooth bằng ARM MTE
(grapheneos.social)- Việc hỗ trợ gắn thẻ bộ nhớ phần cứng trên Pixel 8·Pixel 8 Pro đã làm lộ ra một lỗi hỏng bộ nhớ mới được đưa vào Bluetooth LE trong Android 14 QPR2
- Nguyên nhân được xác định là lỗi upstream use-after-free trong Bluetooth LE, và GrapheneOS đã tạo bản vá để đưa vào bản phát hành mới
- Người dùng tái hiện được sự cố trong chế độ Bluetooth LE của Samsung Galaxy Buds2 Pro đã xác nhận bản sửa hoạt động, và stock Pixel OS cũng bị ảnh hưởng
- GrapheneOS cho rằng vì Bluetooth là một bề mặt tấn công lớn, nên biện pháp vòng tránh là tắt gắn thẻ bộ nhớ cho tiến trình này là không phù hợp ngay cả trong ngắn hạn
- Một phần mã Bluetooth của Android đã được chuyển sang Rust, nhưng vẫn cần chuyển nốt phần mã còn lại và thử nghiệm trên thiết bị thực với các bản dựng HWASan·MTE
Lỗi Bluetooth LE trong Android 14 QPR2 và bản sửa
- GrapheneOS đã phát hiện lỗi hỏng bộ nhớ Bluetooth LE trong Android 14 QPR2 nhờ hỗ trợ gắn thẻ bộ nhớ phần cứng trên Pixel 8 và Pixel 8 Pro
- Đây không phải vấn đề xảy ra với mọi thiết bị Bluetooth, mà chỉ tái hiện được với một số thiết bị Bluetooth LE nhất định
- GrapheneOS đang điều tra cách sửa tính năng mới được đưa vào hoặc tạm thời vô hiệu hóa nó
- Nguyên nhân được xác định là lỗi upstream use-after-free trong Bluetooth LE, và GrapheneOS đã phát triển bản vá
- Ưu tiên trước mắt là nhanh chóng phát hành bản GrapheneOS có tích hợp bản sửa này
- Dự kiến sẽ báo cáo đây là lỗi bảo mật Android
- Bản sửa này cũng có vẻ sẽ khắc phục cả sự hồi quy của âm thanh BLE
- Người dùng từng tái hiện sự cố bằng cách dùng Samsung Galaxy Buds2 Pro ở chế độ Bluetooth LE đã xác nhận bản sửa hoạt động
- Cùng lỗi này cũng ảnh hưởng đến stock Pixel OS
- GrapheneOS đã phát hiện điều này nhờ hỗ trợ gắn thẻ bộ nhớ của hardened_malloc, đồng thời bổ sung thông báo sự cố MTE chứa báo cáo có thể sao chép
Cách áp dụng MTE và các thách thức của mã Bluetooth trên Android
- GrapheneOS cho rằng biện pháp vòng tránh là tắt gắn thẻ bộ nhớ trong tiến trình này là không phù hợp ngay cả trong ngắn hạn
- Bluetooth là một bề mặt tấn công lớn, bất kể khả năng bị khai thác thực tế của lỗi này ra sao
- Android đã chuyển một phần đáng kể mã Bluetooth sang Rust, nhưng việc chuyển nốt phần mã còn lại cũng cần thêm nguồn lực
- Trong môi trường thực tế, vẫn cần nhiều thử nghiệm hơn với các bản dựng HWASan và MTE trên nhiều thiết bị Bluetooth khác nhau
- Thiết bị Pixel có MTE, một tính năng bảo mật phần cứng quan trọng, nhưng hệ điều hành mặc định không bật do muốn giảm 3.125% mức sử dụng bộ nhớ·bộ nhớ đệm
- Cách tính này dựa trên thẻ 4 bit cho mỗi 16 byte bộ nhớ được gắn thẻ
- heap MTE gần như có overhead hiệu năng bằng 0% ở chế độ bất đồng bộ (async mode), và ở chế độ bất đối xứng (asymmetric mode) thì chi phí còn thấp hơn các biện pháp giảm thiểu hiện có như SSP
- GrapheneOS bật MTE theo mặc định cho các ứng dụng do người dùng cài đặt đã được biết là tương thích với hệ điều hành mặc định
- Có thể bật theo kiểu opt-in cho mọi ứng dụng do người dùng cài đặt tại Settings > Security
- Cung cấp thông báo có thể sao chép báo cáo sự cố và công tắc riêng cho từng ứng dụng
- Triển khai MTE của hardened_malloc trong GrapheneOS sử dụng thẻ ngẫu nhiên tiêu chuẩn và thẻ free chuyên dụng, đồng thời loại trừ động thẻ trước đó cùng với thẻ lân cận hiện tại hoặc trước đó
- Tích hợp Chromium đã được sửa, và PartitionAlloc cũng sẽ được cải thiện
1 bình luận
Ý kiến trên Hacker News
Thật lạ khi Pixels được trang bị một tính năng bảo mật phần cứng lớn gọi là MTE mà OS lại không bật chỉ để tiết kiệm 3,125% mức dùng bộ nhớ/cache
Tôi thật sự muốn xem đội Pixel biện minh cho quyết định này thế nào, và tò mò về quá trình suy nghĩ dẫn tới việc tắt một tính năng bảo mật quan trọng như vậy chỉ vì một chút lợi ích hiệu năng
Tuy vậy, GrapheneOS là một dự án tuyệt vời, nhưng chỉ hỗ trợ khoảng 11 thiết bị; còn các thay đổi của AOSP phải cân nhắc một hệ sinh thái OEM lớn hơn nhiều
Chúng tôi luôn tìm cách làm Android tốt hơn, nhưng phê phán việc phát hành một tính năng cụ thể mà bỏ qua hệ sinh thái OEM lớn hơn thì có vẻ hơi thiển cận
Khả năng lý do tính năng này chưa được bật là vì 3% bộ nhớ/cache là rất thấp; có lẽ đã có những cân nhắc khác
Khi quyết định có bật tính năng hay không, đây có lẽ mới là yếu tố lớn hơn
Nghe nói các OS khác hiện cũng không phát hành với MTE được bật, nên việc bật hay không có lẽ là một đánh giá tinh tế hơn
Chính người của Google ngay từ đầu đã thúc đẩy MTE phần cứng, và nó khởi phát từ đội có tham gia ASAN, syzkaller, v.v.
Dù không thuộc đội Android, họ có sự giúp đỡ và hỗ trợ từ phía Android, và dĩ nhiên cũng có hợp tác với ARM cùng các bên khác
Khi đó tôi ở vị trí dẫn dắt các đội ấy nên hiểu rõ các đánh đổi; vấn đề không chỉ là bộ nhớ hay cache
Đúng là MTE được thiết kế để có thể bật/tắt động và chi phí hiệu năng gần như bằng 0, nhưng mục đích sử dụng chính khi đó là tìm lỗi dựa trên lấy mẫu
Nếu bật chỉ 1% thời gian trên toàn bộ tập thiết bị, quy mô như vậy đã đủ lớn để tìm lỗi rất nhanh, và cũng có thể dùng trong kiểm thử nội bộ
Nói cách khác, mục tiêu là cho phép bật/tắt chức năng gần tương đương ASAN khi muốn
Dùng nó như một biện pháp giảm thiểu bảo mật luôn bật chỉ là một khả năng phụ, và ngoài overhead bộ nhớ còn có các vấn đề khác
Ví dụ, đột nhiên có nhiều crash hiển thị với người dùng hơn; trên điện thoại có MTE thì crash, còn điện thoại không có MTE thì không, nên cũng thiếu nhất quán
Từ góc nhìn nhà phát triển, khi gần như chỉ có một mẫu điện thoại bật MTE, việc phải ép mọi người kiểm thử trên chiếc đó chắc cũng không dễ chịu
Nó có thể chặn exploit bảo mật, và khiến chương trình crash thay vì bị khai thác
Nó cũng có thể bắt các lỗi vô hại
Nhưng như đã nói, tôi sẽ không giả định là họ không dùng; cách nhìn hợp lý hơn là họ không để nó luôn bật trong production
Ai từng có kinh nghiệm đưa các tính năng phần cứng kiểu này vào hệ thống sẽ nói rằng bản thân việc hệ thống boot được, chạy được, và chỉ crash dưới MTE ở một số hành vi cụ thể thực ra lại là dấu hiệu tốt cho thấy nó đã được dùng rồi
Nếu chưa dùng, có lẽ nó đã crash cả triệu lần
Nói thêm, cũng không rõ đây có phải là biện pháp giảm thiểu runtime tốt nhất hay không
Pixel mặc định có thể không cung cấp trạng thái bật sẵn cho người dùng cuối, nhưng nếu muốn thì bất kỳ ai cũng có thể bật Memory Tagging Extensions trong tùy chọn nhà phát triển
Có thể giữ cho tới khi tắt, hoặc chỉ bật một phiên để kiểm thử một ứng dụng cụ thể
Bật hỗ trợ memory tagging trong tùy chọn nhà phát triển trên Pixel OS mặc định chỉ làm cho nó khả dụng, chứ thực tế chưa dùng
Cũng phải bật heap memory tagging bằng
setproptrong shell Android Debug Bridge (ADB)Nếu không gắn tag cho các allocation thì chỉ bật lên thôi cũng chẳng có giá trị gì
Có thể bật hoàn toàn MTE cho heap không gian người dùng trên OS mặc định thông qua Scudo, implementation allocator mặc định, nhưng hiện đó không phải là implementation được gia cố đặc biệt
KASan dùng backend MTE cũng có thể dùng bằng
setprop, nhưng hiện không được thiết kế cho mục đích hardening, và cũng chưa rõ sau này có như vậy khôngKernel nhiều khả năng cần một implementation MTE riêng, không phải một phần của KASan, và GrapheneOS cũng chưa làm, nên hiện hardening bằng MTE là tính năng ở không gian người dùng
GrapheneOS dùng implementation hardware memory tagging riêng cho hardened_malloc, với các thuộc tính bảo mật mạnh hơn
Để bật mặc định trên OS mặc định, họ đã phải sửa hoặc workaround nhiều vấn đề, bao gồm cả issue này
Thay vì dùng MTE bất đồng bộ trên các core chính, họ dùng chế độ bất đối xứng trên mọi core
Chế độ bất đối xứng là bất đồng bộ với ghi và đồng bộ với đọc, nên chặn đúng cách mà không để lại cửa sổ cơ hội cho exploit thành công
Nó được kiểm tra trong system call; còn io_uring, một đường bypass tiềm năng khác, bị giới hạn bằng SELinux nên trên Android chỉ được phép cho 2 tiến trình hệ thống cốt lõi
fastbootd chỉ được dùng trong lúc cài đặt, còn snapuserd được dùng trong OS cốt lõi sau khi áp dụng cập nhật
GrapheneOS luôn dùng heap MTE cho các ứng dụng đã được xác nhận tương thích với OS mặc định
Với các ứng dụng do người dùng cài đặt không có trong cơ sở dữ liệu tương thích và không tự đánh dấu là tương thích, họ cung cấp nút bật/tắt MTE theo từng ứng dụng
Người dùng cũng có thể bật để mặc định ép MTE cho các ứng dụng do người dùng cài đặt, hoặc chỉ loại trừ những ứng dụng không tương thích
Để biến điều này thành thứ thực sự dùng được, cần có hệ thống báo cáo crash hiển thị cho người dùng, và họ đã triển khai để người dùng dễ dàng sao chép rồi gửi báo cáo crash hữu ích cho nhà phát triển
Khi tìm Memory Tagging Extensions trong Settings thì có kết quả, tôi tưởng nó bị giấu đâu đó, hóa ra chỉ dành cho điện thoại Pixel 8: https://news.ycombinator.com/item?id=38125379
GrapheneOS đi trước các lựa chọn khác quá xa về mặt bảo mật, đến mức việc chọn thứ gì ngoài phần cứng Pixel trở nên đáng nghi ngờ
Nhưng tôi thực sự muốn có pin có thể thay thế
Không hiểu sao dạo này mọi thứ lại tệ đến vậy
Các thiết bị Android khác còn chưa đến gần
Hỗ trợ gắn thẻ bộ nhớ bằng phần cứng là một trong nhiều lợi thế bảo mật lớn của Pixel
Danh sách yêu cầu phần cứng chính thức ở đây: https://grapheneos.org/faq#future-devices
Yêu cầu này được đáp ứng đầy đủ trên Pixel thế hệ 8
Pixel thế hệ 6/7 chỉ thiếu MTE, BTI và PAC, trong đó MTE là tính năng giá trị nhất trong danh sách yêu cầu phần cứng
Việc có bản vá bảo mật đúng nghĩa quan trọng hơn, và ngoài Pixel thì không được cung cấp theo cùng cách
Android có các bản phát hành hằng tháng, hằng quý và hằng năm
Các OEM Android khác cung cấp đầy đủ các bản sửa mức nghiêm trọng Critical/High trong các bản backport bảo mật hằng tháng, nhưng phần lớn không cung cấp các bản sửa mức Moderate/Low, bao gồm hầu hết các bản sửa về quyền riêng tư
Dùng hệ điều hành thay thế để cung cấp các bản vá này có thể giảm nhẹ phần nào, nhưng hệ điều hành thay thế cho các thiết bị đó thường làm lùi bảo mật theo nhiều cách
Firmware và nhiều mã hỗ trợ thiết bị thực ra đến từ OEM
Có thể chạy Android 14 QPR2 trên kernel/driver Android 12, nhưng sẽ thiếu các cải tiến bảo mật cho những phần lớn của hệ điều hành
Pin Pixel không hẳn là dễ thay mà không làm hỏng thiết bị, nhưng việc này được hỗ trợ chính thức và cũng có linh kiện chính hãng: https://www.ifixit.com/Device/Google_Pixel
Chúng tôi không thể hỗ trợ các thiết bị không an toàn, không đáp ứng được cả những điều cơ bản
Danh sách yêu cầu phần cứng của chúng tôi bao gồm cả những thứ rất cơ bản mà đa số OEM Android không cung cấp, lẫn các tính năng nâng cao như MTE mà hiện chúng tôi xem là yêu cầu cơ bản để có bảo mật phù hợp
Chúng tôi muốn hỗ trợ cả các thiết bị khác, nhưng các thiết bị đó phải đáp ứng những yêu cầu này
Gắn thẻ bộ nhớ là tính năng cơ bản được các nhân Cortex ARMv9 tiêu chuẩn hỗ trợ
Thật đáng tiếc khi Qualcomm không triển khai nó, và các OEM dùng SoC hỗ trợ tính năng này cũng không bật cấu hình
Thật buồn khi kiến trúc CPU có tính năng đó nhưng lại không thể dùng vì SoC hoặc OEM
Dù sao thì Pixel 8 dự kiến được hỗ trợ 7 năm, thế là may rồi
Apple cũng khó tin, Samsung cũng khó tin, và Google đã trở thành lựa chọn tốt nhất trong số đó
Sẽ rất tốt nếu có người dùng GrapheneOS trả lời
Tuy nhiên gần đây khi tôi đi Disney World và Universal Studios ở Orlando, Florida với vợ, dù các ứng dụng nhìn chung vẫn chạy với Google Play Services được sandbox, nhưng có vài vấn đề phiền phức
Ứng dụng My Disney Experience gặp khá nhiều lỗi liên quan đến vị trí, và thỉnh thoảng khi làm việc quan trọng lại hiện thông báo rằng phải ở Mỹ hoặc Canada, nên tôi phải dùng điện thoại của vợ để lách
Với ứng dụng Universal, tôi không đăng nhập tài khoản được, trong khi trên chiếc Samsung Galaxy mặc định của vợ thì chạy tốt, nên có vẻ là vấn đề của GrapheneOS
Ngoài ra, nếu bạn thanh toán thẻ tín dụng bằng Google Wallet thì không được hỗ trợ vì Google không chứng nhận GrapheneOS
Các chức năng khác của Wallet vẫn hoạt động
Uber hoạt động không vấn đề gì
Ngoài ra tôi không dùng ứng dụng độc quyền nào khác
Nếu chủ yếu định dùng ứng dụng tự do/mã nguồn mở thì sẽ không có vấn đề
Phần lớn ứng dụng độc quyền chạy được với Google Play Services được sandbox, nhưng nếu trong số đó có ứng dụng cực kỳ quan trọng cho công việc, bạn có thể gặp các vấn đề phiền phức như tôi đã gặp với Universal Studio và My Disney Experience
Tôi dùng cáp USB thông thường và adb trên dòng lệnh Linux, nhưng cách được khuyến nghị là dùng WebUSB của Chromium, vốn đáng lẽ dễ hơn cho người không chuyên kỹ thuật
Tuy nhiên trong trường hợp của tôi thì cách đó không chạy tốt
Có Google Play Services được sandbox, nên bạn có thể cài đủ loại ứng dụng độc quyền giúp chịu đựng đời sống hiện đại, đồng thời Google Play không có quyền truy cập không giới hạn vào toàn bộ điện thoại; nói chung là lấy được điểm tốt của cả hai phía
Nếu muốn cô lập hơn nữa, bạn có thể tạo một người dùng riêng và chạy các thành phần liên quan đến Google Play trong tài khoản đó
Tôi có thử một lúc, nhưng cá nhân thấy mỗi lần chuyển người dùng khá phiền
Điện thoại chưa từng crash lần nào, ứng dụng ngân hàng cũng chạy
Thiết bị là Pixel 6a
Bạn cũng có thể mua thiết bị đã cài sẵn, nhưng gần như ai cũng có thể dùng trình cài đặt web
Trên Android, ChromeOS, macOS thì đặc biệt dễ, còn Windows hơi rắc rối hơn vì cần cài driver
Linux desktop cần cài quy tắc udev, và một số bản phân phối có phiên bản phần mềm bị cố định có các dịch vụ lỗi gây cản trở
Người không chuyên kỹ thuật cũng làm được, chỉ cần trình duyệt hỗ trợ WebUSB
Không cần phần mềm đặc biệt
Dùng hằng ngày với Google Play được sandbox thì gần như giống Pixel OS mặc định, khả năng tương thích ứng dụng cũng gần tương tự
Khả năng cao bạn sẽ không gặp nhiều crash hơn một cách đáng kể
Hệ điều hành mặc định không có báo cáo crash hướng tới người dùng như ở đây, nên bạn có thể nhận ra các crash mà trước kia vốn không biết
Các ứng dụng nhiều lỗi có lỗi hỏng bộ nhớ có thể crash cho đến khi bật chế độ tương thích theo từng ứng dụng, đặc biệt nếu bạn chọn ép MTE cho toàn bộ ứng dụng do người dùng cài thì khả năng này cao hơn
Ứng dụng ngân hàng sẽ chạy nếu ngân hàng cho phép hệ điều hành không được Google chứng nhận, và hiện phần lớn vẫn cho phép
Tuy nhiên các ngân hàng đang dần chặn các hệ điều hành không được Google chứng nhận, nên về bản chất đây cần được xử lý như một vấn đề quản lý chống cạnh tranh
Trong lúc đó, chúng tôi đang cố thuyết phục các ngân hàng dùng https://grapheneos.org/articles/attestation-compatibility-guide
Các tính năng bảo mật bổ sung, thiết lập sandboxing và hardened memory allocator khiến mọi thứ chậm hơn một chút, và phiền hơn so với việc dùng Android nguyên bản rồi bấm OK cho mọi yêu cầu truy cập dữ liệu
Cũng mất một chút thời gian để thiết lập ban đầu và hiểu GrapheneOS khác gì, dùng các tính năng bảo mật ra sao
Trong 4 năm dùng, tôi không gặp crash
Ít nhất là không có crash toàn hệ thống, và theo kinh nghiệm thì các crash phải debug nhiều ngày không xảy ra vì phần cứng và phần mềm Pixel được phối hợp tốt với nhau
Ứng dụng ngân hàng thì tùy ứng dụng
Có ứng dụng chạy được không cần Play Services, phần lớn chạy được với Play Services được sandbox, và chỉ một số rất ít hoàn toàn không chạy
Nếu bạn nói dùng ngân hàng nào thì người dùng khác có thể kiểm tra giúp xem có chạy không
Ngay cả cách cài khó cũng chỉ là kết nối điện thoại qua USB, bấm nút nguồn/âm lượng vài lần rồi sao chép-dán hai ba lệnh terminal
Cách dễ thì chỉ cần kết nối điện thoại với máy tính và bấm nút cài đặt một cú nhấp chạy trong trình duyệt Chrome
Tôi đã dùng nó gần như liên tục làm OS hằng ngày từ ngay sau khi Google Pixel 6 ra mắt, và chưa từng crash một lần nào
Cũng chưa từng gặp bug hay cần debug, sửa chữa, bảo trì
Mọi ứng dụng tôi thử đều cứ chạy như trên Android nguyên bản, thật lòng là gần như không cảm thấy khác biệt
Đôi khi tôi còn quên mất đây không phải là OS cài sẵn trên điện thoại
Cá nhân tôi thì ứng dụng ngân hàng Discover chạy được, nhưng các ứng dụng khác thì không chắc
Dù vậy, vì có Google Play services và bootloader được khóa sau khi cài, có lẽ phần lớn sẽ chạy
Đến năm 2024 thì chúng ta cần hệ điều hành được xác minh hình thức, ứng dụng và công cụ tiếp nối tinh thần seL4 nhưng ở mức nghiêm ngặt hơn
Trong thời đại như hiện nay, việc ghép nối các codebase thiết kế quá mức nhưng chỉ được kiểm thử hời hợt với những ngôn ngữ mong manh và nguy hiểm có thể khiến tác nhân nước ngoài hack và người dùng có thể thiệt mạng, đồng thời tạo ra nhiều bug phiền toái cùng bề mặt tấn công cho mã độc và hacker
Bên cạnh đó cũng phải cung cấp trải nghiệm người dùng sạch sẽ, tích hợp và các tính năng dùng được, nếu không thì mọi công sức kỹ thuật đều thành vô ích
Cứ nhìn Qubes OS là thấy
Có máy tính bo mạch đơn nào ổn mà triển khai Arm MTE không? Kiểu như Raspberry Pi mới nhất ấy
RasPi 5 dùng quad A76 và các phần mở rộng v8.2, còn MTE là v8.5
MTE so với CHERI thì thế nào?
MTE là để tìm các lỗi bảo mật tiềm ẩn, chứ không phải bảo vệ thật sự
Tag chỉ có 4 bit và ứng dụng có thể giả mạo, nên nếu kẻ tấn công cần đoán đúng tag thì chọn ngẫu nhiên cũng có xác suất đúng 1/16
Ý tưởng khi áp dụng MTE là có thể bắt được những truy cập sai thỉnh thoảng xảy ra, kể cả khi không phải do kẻ tấn công và thực tế chưa tạo ra hậu quả xấu
Hãy nghĩ đến một buffer overflow điển hình: các word ngay sau cuối buffer có thể không được dùng cho mục đích khác, nên trên thực tế chương trình vẫn có thể chạy
MTE phát hiện các truy cập như vậy, cho phép điều tra và vá trước khi chúng trở thành exploit được vũ khí hóa
Tuy nhiên, thông qua tag dành riêng, nó có thể cung cấp các thuộc tính bảo mật xác định mạnh
Thứ không được gắn tag có tag 0, còn thứ được gắn tag mặc định có tag khác 0 do cơ chế loại trừ mặc định
Các tag khác cũng có thể được loại trừ tĩnh hoặc động bằng lệnh, nhưng nếu dùng tag 0 cho mục đích nội bộ như bộ nhớ đã được giải phóng, ta có thể tận dụng việc không con trỏ đã gắn tag nào có thể truy cập nó
Trong hardened_malloc, với các slot cấp phát, các tag liền kề và tag đã dùng trước đó được loại trừ động
Nhờ đó cung cấp bảo vệ xác định trước overflow tuyến tính và overflow nhỏ
Với use-after-free, con trỏ trỏ đến vùng cấp phát đã giải phóng sẽ không thể truy cập trong lúc nó đang được giải phóng hoặc ngay sau khi được cấp phát lại; nó phải chờ đến lần được phân bổ lại tiếp theo, khi đó xác suất có đúng tag là 1/15
Điều này kết hợp tốt với các thuộc tính bảo mật khác của hardened_malloc
Có các vùng cách ly FIFO/ngẫu nhiên cho cấp phát slab và bộ nhớ ảo để trì hoãn tái sử dụng hơn nữa và khiến nó không mang tính xác định
Trước khi vượt quá 128k, vị trí bộ nhớ không bao giờ được tái sử dụng giữa các lớp kích thước cấp phát khác nhau; mỗi lớp nằm ở một vùng khác nhau, và toàn bộ metadata nằm trong một vùng dành riêng khác nữa
Trong trường hợp thông thường, MTE hiện chỉ có 4 bit nên xác suất vượt qua vào khoảng 1/15
Có thể dễ dàng mở rộng để hỗ trợ dùng 8 bit, và nếu không dùng PAC thì vẫn còn các bit rảnh khác
Về lý thuyết, trong không gian địa chỉ 39 bit thông thường, nó còn có thể hỗ trợ MTE tối đa 16 bit cho không gian địa chỉ từ 48 bit trở lên
Hiện nó bị cố định ở 4 bit; tôi nghe nói họ chọn vậy thay vì 8 bit để có thể lưu thêm bit trong bộ nhớ parity ECC
Nhưng không phát hiện đáng tin cậy như CHERI
Không có bảo vệ cho tag và không gian tag cũng nhỏ (2^4)
Mong đến ngày phần cứng chủ lưu bắt kịp kiến trúc gắn tag bộ nhớ của Solaris SPARC năm 2015 hoặc trước đó, để cuối cùng kiểm soát được vấn đề hỏng bộ nhớ
Dĩ nhiên những vấn đề đó thường bị xem như chỉ do các lập trình viên kém năng lực gây ra
Đây không phải là vấn đề “lập trình viên kém năng lực”, mà là vấn đề của tất cả mọi người
Hỏng bộ nhớ về cơ bản gần như là một tính năng ngôn ngữ của C/C++
Tốt nhất đừng lan truyền niềm tin rằng đó là do những người ngu ngốc
Gần như không ai tự nghĩ mình ngu, và tôi đã thấy cả những coder thật sự xuất sắc cũng tạo ra các lỗi bộ nhớ rất buồn cười
Đó đơn giản là một phần trong phạm vi của các ngôn ngữ đó, và không phải là chuyện “nếu”, mà là “khi nào”
Tôi thích việc câu nói Android đã chuyển phần lớn code Bluetooth sang Rust, và đây là lý do cần đầu tư thêm tài nguyên để chuyển nốt phần code còn lại sang Rust, được lồng vào khá khéo
Tôi đã dùng C và C++ nhiều năm nhưng chưa có kinh nghiệm Rust, nên tò mò khi port từ C sang Rust thì cần refactor nhiều đến mức nào
Tách câu hỏi ra thì: 1. C có thể được dịch trực tiếp sang Rust đến mức nào? Rust có đòi hỏi tái cấu trúc hoặc refactor không?
2. Tôi cũng tò mò Google đang tiếp cận việc này ra sao: họ cố “dịch” sát nhất có thể, hay xem đây là cơ hội viết lại/refactor quy mô lớn?
Tôi cũng tự hỏi liệu một ngày nào đó Bluetooth stack của Android có thể dùng được trên hệ thống desktop của các bản phân phối Linux tiêu chuẩn hay không
Có nhiều tham chiếu vòng, các module giao tiếp với nhau qua một “signal bus” có callback, và tôi cảm thấy phải đánh vật với Rust hơn là được Rust giúp
Ngay cả ở những chỗ trong C++ có thể lưu dữ liệu inline, tôi cũng cần khá nhiều Box, tức con trỏ heap
Kết luận là nếu là công cụ dòng lệnh đơn giản hoặc cấu trúc request-response thì port sang Rust có lẽ dễ
Nói chung hơn, nếu cấu trúc code hợp tốt với cấp phát arena thì việc chuyển sang cách gắn tag lifetime cho tham chiếu không phải vấn đề lớn
Nhưng nếu bạn viết kiểu lập trình viên C với các tham chiếu vòng — phải thừa nhận là code xấu — thì Rust sẽ giống như leo dốc, và đó không phải điểm khởi đầu tốt
Trước hết cần đổi cấu trúc code C++ để chuyển quyền sở hữu lên một cha chung
Làm vậy có lẽ sẽ tốt hơn
Tôi sẽ tiếp tục học Rust theo vòng lặp, nhưng vẫn làm việc tiếp trong C++ cho đến khi code tương ứng tốt hơn với Rust
Sẽ phải tái kiến trúc phần lớn thứ đang viết
Điều này là không tránh khỏi do cách Rust bảo đảm an toàn bộ nhớ