Bảo mật vi kiến trúc của AWS Firecracker VMM: Bối cảnh

tác giả: (1) Zane Weissman, Học viện Bách khoa Worcester Worcester, MA, Hoa Kỳ {zweissman@wpi.edu}; (2) Thomas Eisenbarth, Đại học Lübeck Lübeck, SH, Đức {thomas.eisenbarth@uni-luebeck.de}; (3) Thore Tiemann, Đại học Lübeck Lübeck, SH, Đức {t.tiemann@uni-luebeck.de}; (4) Berk Sunar, Học viện Bách khoa Worcester Worcester, MA, Hoa Kỳ {sunar@wpi.edu}. Bảng liên kết Tóm tắt và giới thiệu Lý lịch Mô hình mối đe dọa Phân tích hệ thống ngăn chặn pháo Phân tích cuộc tấn công và phòng thủ vi kiến trúc trong microvms pháo Kết luận, Lời cảm ơn và Tài liệu tham khảo 2. BỐI CẢNH 2.1 KVM Máy ảo dựa trên nhân Linux (KVM) [29] cung cấp bản tóm tắt các tính năng ảo hóa được hỗ trợ bằng phần cứng như Intel VT-x hoặc AMD-V có sẵn trong các CPU hiện đại. Để hỗ trợ thực thi gần như nguyên bản, chế độ khách được thêm vào nhân Linux bên cạnh chế độ nhân và chế độ người dùng hiện có. Nếu ở chế độ khách Linux, KVM khiến phần cứng chuyển sang chế độ ảo hóa phần cứng nhằm sao chép các đặc quyền của vòng 0 và vòng 3.[1] Với KVM, ảo hóa I/O được thực hiện chủ yếu trong không gian người dùng bởi quy trình tạo VM, được gọi là VMM hoặc bộ ảo hóa, trái ngược với các bộ ảo hóa trước đó thường yêu cầu một quy trình bộ ảo hóa riêng biệt [41]. Trình ảo hóa KVM cung cấp cho mỗi máy khách VM một vùng bộ nhớ riêng tách biệt với vùng bộ nhớ của quy trình đã tạo máy khách. Điều này đúng với các khách được tạo từ không gian kernel cũng như từ không gian người dùng. Mỗi VM ánh xạ tới một tiến trình trên máy chủ Linux và mỗi CPU ảo được gán cho máy khách là một luồng trong tiến trình máy chủ đó. Quá trình ảo hóa không gian người dùng của VM chỉ thực hiện các cuộc gọi hệ thống tới KVM khi cần thực thi đặc quyền, giảm thiểu chuyển đổi ngữ cảnh và giảm VM thành bề mặt tấn công hạt nhân. Bên cạnh việc thúc đẩy cải thiện hiệu suất trên tất cả các loại ứng dụng, thiết kế này còn cho phép phát triển các trình ảo hóa nhẹ, đặc biệt hữu ích cho việc đóng hộp cát các chương trình riêng lẻ và hỗ trợ môi trường đám mây nơi nhiều máy ảo đang chạy cùng lúc. 2.2 Điện toán đám mây không có máy chủ Một mô hình ngày càng phổ biến cho điện toán đám mây là điện toán không có máy chủ, trong đó CSP quản lý khả năng mở rộng và tính khả dụng của các máy chủ chạy mã của người dùng. Một triển khai điện toán không có máy chủ được gọi là chức năng như một dịch vụ (FaaS). Trong mô hình này, người dùng đám mây xác định các chức năng được gọi là cần thiết thông qua giao diện lập trình ứng dụng (API) của nhà cung cấp dịch vụ (do đó có tên là “chức năng như một dịch vụ”) và CSP quản lý việc phân bổ tài nguyên trên máy chủ thực thi chức năng của người dùng (do đó có tên là “điện toán không có máy chủ”—người dùng không quản lý máy chủ). Tương tự, điện toán container dưới dạng dịch vụ (CaaS) chạy các container, gói thời gian chạy di động theo yêu cầu. Việc quản lý máy chủ tập trung của FaaS và CaaS có tính hấp dẫn về mặt kinh tế đối với cả CSP và người dùng. CSP có thể quản lý khối lượng công việc của người dùng theo ý muốn, tối ưu hóa để có chi phí vận hành tối thiểu và triển khai mức giá linh hoạt trong đó người dùng trả tiền cho thời gian thực hiện mà họ sử dụng. Người dùng không cần phải lo lắng về việc thiết kế hoặc quản lý cơ sở hạ tầng máy chủ, do đó giảm chi phí phát triển và chi phí bảo trì thuê ngoài cho CSP ở mức tương đối nhỏ và có thể dự đoán được. 2.3 MicroVM và AWS Firecracker Các nhà cung cấp FaaS và CaaS sử dụng nhiều hệ thống khác nhau để quản lý các chức năng và vùng chứa đang chạy. Các hệ thống container như Docker, Podman và LXD cung cấp một cách thuận tiện và nhẹ nhàng để đóng gói và chạy các ứng dụng hộp cát trong mọi môi trường. Tuy nhiên, so với các máy ảo được sử dụng cho nhiều hình thức điện toán đám mây truyền thống hơn, các container ít cách ly hơn và do đó kém bảo mật hơn. Trong những năm gần đây, các CSP lớn đã giới thiệu microVM hỗ trợ các container truyền thống với khả năng ảo hóa nhẹ để tăng cường bảo mật. [1, 55] Hiệu quả của việc ảo hóa phần cứng với KVM và thiết kế gọn nhẹ của microVM có nghĩa là mã trong các hệ thống ảo hóa, được chứa trong bộ chứa hoặc giống như bộ chứa có thể chạy nhanh gần như mã không được ảo hóa và có chi phí hoạt động tương đương với bộ chứa truyền thống. Firecracker [1] là một microVM được AWS phát triển để tách biệt từng khối lượng công việc AWS Lambda FaaS và AWS Fargate CaaS trong một VM riêng biệt. Nó chỉ hỗ trợ khách Linux trên máy chủ x86 hoặc ARM Linux-KVM và cung cấp một số lượng thiết bị hạn chế có sẵn cho hệ thống khách. Những hạn chế này cho phép Firecracker có kích thước rất nhẹ về kích thước cơ sở mã và chi phí bộ nhớ đối với máy ảo đang chạy, cũng như khởi động hoặc tắt rất nhanh. Ngoài ra, việc sử dụng KVM làm giảm nhẹ các yêu cầu của Firecracker vì một số chức năng ảo hóa được xử lý bằng lệnh gọi hệ thống hạt nhân và hệ điều hành chủ quản lý máy ảo như các quy trình tiêu chuẩn. Do cơ sở mã nhỏ được viết bằng Rust, Firecracker được cho là rất an toàn, mặc dù các lỗi bảo mật đã được xác định trong các phiên bản trước đó (xem CVE-2019-18960). Điều thú vị là, sách trắng của Firecracker tuyên bố các cuộc tấn công kiến trúc vi mô nằm trong phạm vi mô hình kẻ tấn công của nó [1] nhưng thiếu phân tích bảo mật chi tiết hoặc các biện pháp đối phó đặc biệt chống lại các cuộc tấn công kiến trúc vi mô ngoài các khuyến nghị cấu hình hệ thống an toàn chung cho nhân máy khách và máy chủ. Tài liệu về Firecracker cung cấp các khuyến nghị về bảo mật hệ thống [8] bao gồm danh sách các biện pháp đối phó cụ thể mà chúng tôi đề cập trong phần 2.6.1. 2.4 Tan chảy và MDS Vào năm 2018, cuộc tấn công Meltdown [32] cho thấy dữ liệu được truy cập theo suy đoán có thể bị đánh cắp qua các ranh giới bảo mật bằng cách mã hóa nó vào kênh bên của bộ đệm. Điều này sớm dẫn đến một loạt các cuộc tấn công tương tự, được gọi là lấy mẫu dữ liệu vi kiến trúc (MDS), bao gồm Fallout [14], Tải dữ liệu trên chuyến bay giả mạo (RIDL) [50], Hủy bỏ không đồng bộ TSX (TAA) [50] và Tải zombie [46]. Tất cả các cuộc tấn công này đều tuân theo cùng một mô hình chung để khai thác việc thực thi suy đoán: (1) Nạn nhân chạy chương trình xử lý dữ liệu bí mật và dữ liệu bí mật đi qua bộ đệm hoặc bộ đệm CPU. (2) Kẻ tấn công chạy một lệnh được chọn cụ thể sẽ khiến CPU dự đoán nhầm rằng dữ liệu bí mật sẽ cần thiết. CPU chuyển tiếp dữ liệu bí mật theo lệnh của kẻ tấn công. (3) Dữ liệu bí mật được chuyển tiếp được sử dụng làm chỉ mục cho bộ nhớ được đọc vào một mảng mà kẻ tấn công được phép truy cập, khiến một dòng cụ thể của mảng đó được lưu vào bộ đệm. (4) CPU hoàn tất việc kiểm tra dữ liệu và quyết định rằng dữ liệu bí mật đã được chuyển tiếp không chính xác và hoàn nguyên trạng thái thực thi về trước khi nó được chuyển tiếp, nhưng trạng thái của bộ đệm không được hoàn nguyên. (5) Kẻ tấn công thăm dò tất cả mảng để xem dòng nào được lưu vào bộ đệm; chỉ mục của dòng đó là giá trị của dữ liệu bí mật. Lỗ hổng Meltdown ban đầu nhắm mục tiêu chuyển tiếp bộ đệm và cho phép trích xuất dữ liệu theo cách này từ bất kỳ địa chỉ bộ nhớ nào có trong bộ đệm. Các cuộc tấn công MDS nhắm vào các bộ đệm nhỏ hơn và cụ thể hơn trong vi kiến trúc trên lõi và do đó tạo nên một lớp tấn công có liên quan nhưng khác biệt được giảm thiểu theo một cách khác biệt đáng kể. Trong khi Meltdown nhắm vào bộ nhớ chính được cập nhật tương đối không thường xuyên và được chia sẻ trên tất cả các lõi, luồng và quy trình, thì các cuộc tấn công MDS có xu hướng nhắm mục tiêu vào các bộ đệm cục bộ trong các lõi (mặc dù đôi khi được chia sẻ giữa các luồng) và được cập nhật thường xuyên hơn trong quá trình thực thi. . Hình 1 biểu đồ các đường tấn công MDS chính đã biết trên CPU Intel và tên đặt cho các biến thể khác nhau của Intel và các nhà nghiên cứu đã báo cáo chúng. Nhìn rộng nhất, Intel phân loại các lỗ hổng MDS trong CPU của họ theo bộ đệm cụ thể mà từ đó dữ liệu được chuyển tiếp theo suy đoán, vì những bộ đệm này có xu hướng được sử dụng cho một số hoạt động khác nhau. Các lỗ hổng RIDL MDS có thể được phân loại thành Lấy mẫu dữ liệu cổng tải vi kiến trúc (MLPDS), dành cho các biến thể rò rỉ từ cổng tải của CPU và Lấy mẫu dữ liệu bộ đệm điền vi kiến trúc (MFBDS), dành cho các biến thể rò rỉ từ LFB của CPU. Tương tự như vậy, Intel gọi lỗ hổng Fallout là Lấy mẫu dữ liệu bộ đệm cửa hàng vi kiến trúc (MSBDS), vì nó liên quan đến rò rỉ từ bộ đệm cửa hàng. Lấy mẫu thanh ghi vectơ (VRS) là một biến thể của MSBDS nhắm mục tiêu dữ liệu được xử lý bởi các hoạt động vectơ khi nó đi qua bộ đệm lưu trữ. VERW bypass khai thác một lỗi trong 2.4.1 Các biến thể MDS cơ bản sửa lỗi vi mã cho MFBDS tải dữ liệu cũ và có khả năng bí mật vào LFB. Cơ chế rò rỉ cơ bản là như nhau và bỏ qua VERW có thể được coi là trường hợp đặc biệt của MFBDS. Lấy mẫu trục xuất dữ liệu L1 (L1DES) là một trường hợp đặc biệt khác của MFBDS, trong đó dữ liệu bị trục xuất khỏi bộ đệm dữ liệu L1 đi qua LFB và trở nên dễ bị tấn công MDS. Đáng chú ý, L1DES là trường hợp kẻ tấn công thực sự có thể kích hoạt sự hiện diện của dữ liệu bí mật trong CPU (bằng cách loại bỏ nó), trong khi các cuộc tấn công MDS khác dựa trực tiếp vào quá trình nạn nhân truy cập dữ liệu bí mật để đưa nó vào bộ đệm CPU phù hợp. [37] là một loại tấn công MDS được Intel phân loại là các biến thể MLPDS [25]. Các lỗ hổng Medusa khai thác các thuật toán khớp mẫu không hoàn hảo được sử dụng để kết hợp các cửa hàng trong bộ đệm ghi kết hợp (WC) của bộ xử lý Intel. Intel coi bộ đệm WC là một phần của cổng tải nên Intel phân loại lỗ hổng này là trường hợp của MLPDS. Có ba biến thể Medusa đã biết, mỗi biến thể khai thác một tính năng khác nhau của bộ đệm kết hợp ghi để gây rò rỉ suy đoán: 2.4.2 Medusa. Medusa tải lỗi được kết hợp một cách suy đoán với tải trước đó với độ lệch dòng bộ đệm phù hợp. Lập chỉ mục bộ đệm: một cửa hàng hợp lệ theo sau là tải phụ thuộc gây ra lỗi bộ nhớ không được căn chỉnh khiến dữ liệu ngẫu nhiên từ WC được chuyển tiếp. Chuyển tiếp Store-to-Load không được căn chỉnh: : lệnh REP MOV bị lỗi theo sau là tải phụ thuộc làm rò rỉ dữ liệu của REP MOV khác. Shadow REP MOV Lỗ hổng phần cứng TSX Asynchronous Abort (TAA) [24] cung cấp một cơ chế suy đoán khác để thực hiện một cuộc tấn công MDS. Trong khi các cuộc tấn công MDS tiêu chuẩn truy cập dữ liệu bị hạn chế bằng cách thực thi suy đoán tiêu chuẩn, TAA sử dụng giao dịch bộ nhớ nguyên tử do TSX triển khai. Khi một giao dịch bộ nhớ nguyên tử gặp phải sự hủy bỏ không đồng bộ, chẳng hạn do một quy trình khác đọc dòng bộ đệm được đánh dấu để giao dịch sử dụng hoặc do giao dịch gặp lỗi, tất cả các hoạt động trong giao dịch sẽ được khôi phục về trạng thái kiến trúc trước khi giao dịch bắt đầu. Tuy nhiên, trong quá trình khôi phục này, các hướng dẫn bên trong giao dịch đã bắt đầu thực thi có thể tiếp tục thực hiện suy đoán, như trong bước (2) và (3) của các cuộc tấn công MDS khác. TAA tác động đến tất cả các bộ xử lý Intel hỗ trợ TSX và trường hợp một số bộ xử lý mới hơn không bị ảnh hưởng bởi các cuộc tấn công MDS khác, các biện pháp giảm thiểu MDS hoặc các biện pháp giảm nhẹ TAA cụ thể (chẳng hạn như vô hiệu hóa TSX) phải được triển khai trong phần mềm để bảo vệ chống lại TAA [24]. 2.4.3 Hủy bỏ không đồng bộ TSX. 2.4.4 Biện pháp giảm nhẹ. nhưng chúng có thể được giảm thiểu bằng các bản vá chương trình cơ sở vi mã trên hầu hết các CPU dễ bị tấn công. Mặc dù các lỗ hổng bảo mật loại Meltdown và MDS khai thác các hoạt động vi kiến trúc cấp thấp Cách ly bảng trang. để quy trình cấp người dùng có thể thực hiện lệnh gọi hệ thống tới kernel với chi phí tối thiểu. Cách ly bảng trang (lần đầu tiên được đề xuất bởi Gruss và cộng sự là KAISER [19]) chỉ ánh xạ bộ nhớ hạt nhân tối thiểu cần thiết vào bảng trang của người dùng và giới thiệu một bảng trang thứ hai chỉ có thể được truy cập bởi hạt nhân. Do quy trình người dùng không thể truy cập vào bảng trang kernel, nên quyền truy cập vào tất cả ngoại trừ một phần nhỏ và được chọn cụ thể của bộ nhớ kernel sẽ bị dừng trước khi chúng đến bộ đệm cấp thấp hơn nơi cuộc tấn công Meltdown bắt đầu. Trong lịch sử, các bảng trang kernel đã được đưa vào các bảng trang quy trình cấp người dùng Các cuộc tấn công MDS nhắm vào bộ đệm CPU trên lõi yêu cầu khả năng phòng thủ ở cấp độ thấp hơn và có mục tiêu hơn. Intel đã giới thiệu một bản cập nhật vi mã ghi đè lên các bộ đệm dễ bị tấn công khi bộ nhớ đệm dữ liệu cấp một (L1d) (mục tiêu chung của các cuộc tấn công kênh bên định thời gian bộ nhớ đệm) bị xóa hoặc lệnh VERW được chạy [25]. Sau đó, hạt nhân có thể bảo vệ chống lại các cuộc tấn công MDS bằng cách kích hoạt ghi đè bộ đệm khi chuyển sang một quy trình không đáng tin cậy. Ghi đè bộ đệm. Giảm thiểu ghi đè bộ đệm nhắm mục tiêu các cuộc tấn công MDS tại nguồn của chúng, nhưng ít nhất phải nói là không hoàn hảo. Các quy trình vẫn dễ bị tấn công từ các luồng chạy đồng thời trên cùng một lõi khi SMT được bật (vì cả hai luồng đều chia sẻ bộ đệm dễ bị tấn công mà không có quá trình hoạt động thực sự thay đổi trên một trong hai luồng). Hơn nữa, ngay sau khi bộ đệm ban đầu ghi đè cập nhật vi mã, nhóm RIDL đã nhận thấy rằng trên một số CPU Skylake, bộ đệm đã bị ghi đè bằng dữ liệu cũ và có khả năng nhạy cảm [50] và vẫn dễ bị tổn thương ngay cả khi bật tính năng giảm thiểu và tắt SMT. Vẫn còn các bộ xử lý khác dễ bị tấn công bởi TAA chứ không phải các cuộc tấn công MDS không phảiTAA và không nhận được bản cập nhật vi mã ghi đè bộ đệm và do đó yêu cầu TSX phải bị vô hiệu hóa hoàn toàn để ngăn chặn các cuộc tấn công MDS [20, 24]. 2.5 Bóng ma Năm 2018, Jan Horn và Paul Kocher [30] đã báo cáo độc lập các biến thể Spectre đầu tiên. Kể từ đó, nhiều biến thể Spectre khác nhau [22, 30, 31, 33] và các biến thể phụ [10, 13, 16, 28, 52] đã được phát hiện. Các cuộc tấn công của Spectre khiến CPU truy cập bộ nhớ theo cách suy đoán mà về mặt kiến trúc không thể truy cập được và làm rò rỉ dữ liệu sang trạng thái kiến trúc. Do đó, tất cả các biến thể của Spectre đều bao gồm ba thành phần [27]: Thành phần đầu tiên là tiện ích Spectre được thực thi theo suy đoán. Các biến thể của Spectre thường được phân tách theo nguồn gốc của sự hiểu sai mà chúng khai thác. Ví dụ: kết quả của nhánh trực tiếp có điều kiện được dự đoán bởi Bảng lịch sử mẫu (PHT). Việc dự đoán sai PHT có thể dẫn đến việc bỏ qua kiểm tra giới hạn suy đoán đối với các hướng dẫn tải và lưu trữ [13, 28, 30]. Mục tiêu nhánh của bước nhảy gián tiếp được dự đoán bởi Bộ đệm mục tiêu nhánh (BTB). Nếu kẻ tấn công có thể ảnh hưởng đến kết quả dự đoán sai của BTB thì có thể xảy ra các cuộc tấn công lập trình hướng lợi nhuận suy đoán [10, 13, 16, 30]. Điều này cũng đúng đối với các dự đoán được cung cấp bởi Bộ đệm ngăn xếp trả về (RSB) dự đoán các địa chỉ trả về trong quá trình thực hiện các lệnh trả về [13, 31, 33]. Các kết quả gần đây cho thấy một số CPU hiện đại sử dụng BTB để dự đoán địa chỉ trả về của chúng nếu RSB tràn [52]. Một nguồn tấn công Spectre khác là việc dự đoán sự phụ thuộc giữa các cửa hàng và tải. Nếu một tải bị dự đoán sai là không phụ thuộc vào kho lưu trữ trước đó, thì nó sẽ thực thi một cách suy đoán trên dữ liệu cũ, điều này có thể dẫn đến bỏ qua cửa hàng suy đoán [22]. Tất cả các tiện ích này đều không thể khai thác được theo mặc định mà phụ thuộc vào hai thành phần còn lại được thảo luận bây giờ. Thành phần thứ hai là cách kẻ tấn công kiểm soát đầu vào của các tiện ích nói trên. Những kẻ tấn công có thể xác định trực tiếp các giá trị đầu vào của tiện ích thông qua đầu vào của người dùng, nội dung tệp, gói mạng hoặc các cơ chế kiến trúc khác. Mặt khác, những kẻ tấn công có thể tiêm dữ liệu vào thiết bị một cách tạm thời thông qua việc tiêm giá trị tải [12] hoặc tiêm giá trị dấu phẩy động [42]. Những kẻ tấn công có thể kiểm soát thành công đầu vào của tiện ích nếu chúng có thể tác động đến dữ liệu hoặc hướng dẫn nào được truy cập hoặc thực thi trong cửa sổ suy đoán. Thành phần thứ ba là kênh bí mật được sử dụng để chuyển trạng thái vi kiến trúc suy đoán sang trạng thái kiến trúc và do đó lọc dữ liệu được truy cập suy đoán vào một môi trường ổn định. Các kênh bí mật của bộ đệm [39, 40, 54] có thể áp dụng nếu mã nạn nhân thực hiện truy cập bộ nhớ tạm thời tùy thuộc vào dữ liệu bí mật được truy cập theo suy đoán [30]. Nếu một bí mật được truy cập theo cách suy đoán và được tải vào bộ đệm trên lõi, kẻ tấn công có thể dựa vào kênh dựa trên MDS [14, 46, 50] để chuyển tạm thời dữ liệu đã lọc sang luồng của kẻ tấn công nơi dữ liệu được truyền đến kiến trúc trạng thái thông qua, ví dụ, một kênh bí mật bộ đệm. Cuối cùng nhưng không kém phần quan trọng, nếu nạn nhân thực thi mã tùy thuộc vào dữ liệu bí mật, kẻ tấn công có thể tìm hiểu bí mật bằng cách quan sát sự tranh chấp cổng [3, 11, 18, 43, 44]. Nhiều biện pháp đối phó đã được phát triển để giảm thiểu các biến thể Spectre khác nhau. Một biến thể Spectre cụ thể sẽ bị vô hiệu hóa nếu một trong ba thành phần bắt buộc bị loại bỏ. Kẻ tấn công không có quyền kiểm soát đầu vào của các tiện ích Spectre khó có thể thực hiện thành công một cuộc tấn công. Điều tương tự cũng đúng nếu không có kênh bí mật để chuyển trạng thái suy đoán thành trạng thái kiến trúc. Nhưng vì điều này thường khó đảm bảo nên các biện pháp đối phó của Spectre chủ yếu tập trung vào việc ngăn chặn những dự đoán sai. Việc chèn các hướng dẫn hạn chế trước các phần mã quan trọng sẽ vô hiệu hóa việc thực thi suy đoán vượt quá điểm này và do đó có thể được sử dụng như một biện pháp đối phó chung. Nhưng do chi phí hoạt động cao nên các biện pháp đối phó cụ thể hơn đã được phát triển. Các biện pháp đối phó Spectre-BTB bao gồm Retpoline [48] và cập nhật vi mã như IBRS, STIBP hoặc IBPB [23]. Spectre-RSB và Spectre-BTB-via-RSB có thể được giảm thiểu bằng cách điền vào RSB các giá trị để ghi đè các mục độc hại và ngăn RSB tràn hoặc bằng cách cài đặt các bản cập nhật vi mã IBRS. Spectre-STL có thể được giảm thiểu bằng cách cập nhật vi mã SSBD [23]. Một tùy chọn quyết liệt khác để ngăn chặn kẻ tấn công giả mạo bộ đệm dự đoán nhánh dùng chung là vô hiệu hóa SMT. Việc vô hiệu hóa SMT sẽ phân vùng một cách hiệu quả các tài nguyên phần cứng dự đoán nhánh giữa những người thuê đồng thời với cái giá là giảm hiệu suất đáng kể. 2.5.1 Biện pháp giảm thiểu. 2.6 Mô hình cách ly của AWS Firecracker được xây dựng riêng cho các ứng dụng serverless và container [1] và hiện đang được Fargate CaaS và Lambda FaaS của AWS sử dụng. Trong cả hai mô hình dịch vụ này, Firecracker là hệ thống cách ly chính hỗ trợ mọi tác vụ Fargate hoặc sự kiện Lambda riêng lẻ. Cả hai mô hình dịch vụ này cũng được thiết kế để chạy số lượng lớn các tác vụ tương đối nhỏ và có thời gian tồn tại ngắn. AWS liệt kê các yêu cầu thiết kế cho hệ thống cách ly mà cuối cùng đã trở thành Firecracker như sau: : Phải đảm bảo an toàn cho nhiều chức năng chạy trên cùng một phần cứng, được bảo vệ chống leo thang đặc quyền, tiết lộ thông tin, các kênh bí mật và các rủi ro khác. Cô lập Phải có thể chạy hàng nghìn chức năng trên một máy, với mức lãng phí tối thiểu. Chi phí và mật độ: Các chức năng phải hoạt động tương tự như chạy nguyên bản. Hiệu suất cũng phải nhất quán và tách biệt khỏi hoạt động của các thiết bị lân cận trên cùng phần cứng. Hiệu suất: : Lambda cho phép các hàm chứa các tệp nhị phân và thư viện Linux tùy ý. Chúng phải được hỗ trợ mà không cần thay đổi mã hoặc biên dịch lại. Khả năng tương thích Phải có khả năng khởi động các chức năng mới và dọn dẹp các chức năng cũ một cách nhanh chóng. Chuyển đổi nhanh: Phải có khả năng cam kết vượt mức CPU, bộ nhớ và các tài nguyên khác, với mỗi chức năng chỉ tiêu thụ những tài nguyên mà nó cần chứ không phải những tài nguyên mà nó được hưởng. [1] Phân bổ mềm: Chúng tôi đặc biệt quan tâm đến yêu cầu và nhấn mạnh rằng các cuộc tấn công vi kiến trúc được khai báo trong phạm vi của mô hình mối đe dọa Firecracker. Trang “thiết kế” trong kho lưu trữ Firecracker Git công khai của AWS trình bày chi tiết về mô hình cách ly và cung cấp sơ đồ hữu ích mà chúng tôi tái tạo trong Hình 2. Sơ đồ này chủ yếu liên quan đến việc bảo vệ chống lại việc leo thang đặc quyền. Lớp bảo vệ ngoài cùng là jailer, sử dụng kỹ thuật cách ly container để hạn chế quyền truy cập của Firecracker vào kernel máy chủ trong khi chạy VMM và các thành phần quản lý khác cách ly của Firecracker dưới dạng các luồng của một tiến trình duy nhất trong không gian người dùng máy chủ. Trong quy trình Firecracker, khối lượng công việc của người dùng được chạy trên các luồng khác. Các luồng công việc thực thi hệ điều hành khách của máy ảo và mọi chương trình đang chạy trong máy khách. Việc chạy mã của người dùng trong máy ảo sẽ hạn chế sự tương tác trực tiếp của nó với máy chủ ở các tương tác được sắp xếp trước với KVM và một số phần nhất định của chuỗi quản lý Firecracker. Vì vậy, từ góc độ hạt nhân máy chủ, VMM và VM bao gồm cả mã của người dùng đều được chạy trong cùng một quy trình. Đây là lý do tại sao AWS tuyên bố rằng mỗi VM nằm trong một quy trình duy nhất. Tuy nhiên, do VM được cách ly thông qua các kỹ thuật ảo hóa phần cứng nên mã của người dùng, kernel khách và VMM hoạt động trong các không gian địa chỉ riêng biệt. Do đó, mã của khách không thể truy cập tạm thời hoặc kiến trúc VMM hoặc địa chỉ bộ nhớ lõi của khách vì chúng không được ánh xạ trong không gian địa chỉ của khách. Bề mặt tấn công vi kiến trúc còn lại được giới hạn ở các cuộc tấn công MDS làm rò rỉ thông tin từ bộ đệm bên trong CPU, bỏ qua ranh giới không gian địa chỉ và các cuộc tấn công Spectre trong đó kẻ tấn công thao túng dự đoán nhánh của các quy trình khác để tự rò rỉ thông tin. Không được hiển thị trong Hình 2, nhưng điều quan trọng không kém đối với mô hình mối đe dọa của AWS là việc các chức năng với nhau khi phần cứng được chia sẻ, đặc biệt là trong bối cảnh yêu cầu . Bên cạnh thực tế là việc xâm phạm nhân máy chủ có thể ảnh hưởng đến tính bảo mật của bất kỳ khách nào, các cuộc tấn công vi kiến trúc nhắm vào phần cứng máy chủ cũng có thể đe dọa trực tiếp đến mã người dùng. Do một quy trình Firecracker chứa tất cả các luồng cần thiết để chạy một máy ảo có chức năng của người dùng nên việc phân bổ mềm có thể được thực hiện đơn giản bởi hệ điều hành máy chủ [1]. Điều này có nghĩa là các hệ thống cách ly quy trình Linux tiêu chuẩn được đặt trên cơ sở cách ly máy ảo. tách biệt phân bổ mềm Tài liệu về Firecracker cũng khuyến nghị các biện pháp phòng ngừa sau để bảo vệ chống lại các kênh bên vi kiến trúc [8]: 2.6.1 Khuyến nghị về bảo mật pháo nổ. • Tắt SMT • Kích hoạt tính năng cách ly bảng trang kernel • Vô hiệu hóa việc hợp nhất trang kame kernel • Sử dụng hạt nhân được biên dịch với tính năng giảm thiểu Spectre-BTB (ví dụ: IBRS và IBPB trên x86) • Xác minh biện pháp giảm thiểu Spectre-PHT • Kích hoạt tính năng giảm nhẹ L1TF • Kích hoạt tính năng giảm thiểu Spectre-STL • Sử dụng bộ nhớ với tính năng giảm thiểu Rowhammer • Vô hiệu hóa trao đổi hoặc sử dụng trao đổi an toàn Bài viết này theo giấy phép CC BY-NC-ND 4.0 DEED. có sẵn trên arxiv [1] Vòng 0 và vòng 3 được ảo hóa là một trong những lý do cốt lõi giúp đạt được việc thực thi mã gần giống gốc.