TinyKVM - Sandbox nhanh chạy trên Varnish

 (info.varnish-software.com)
6 điểm bởi GN⁺ 2025-03-15 | 2 bình luận | Chia sẻ qua WhatsApp
  • Sandbox đơn tiến trình dựa trên KVM
    • Có thể chạy các chương trình Linux thông thường hoặc chương trình sử dụng API cụ thể trong sandbox
  • Cung cấp hiệu năng native nhờ sử dụng ảo hóa phần cứng
  • Chỉ dùng một phần của KVM API → codebase nhỏ và hiệu quả

Thiết kế của TinyKVM

  • Hỗ trợ chạy chương trình Linux ELF tĩnh
    • Hỗ trợ tệp thực thi động sẽ được bổ sung sau
    • Cũng có thể mở rộng bằng API để cung cấp quyền truy cập tới máy chủ HTTP hoặc cache bên ngoài
    • Hiện hoạt động trên AMD64(x86_64), và có kế hoạch port sang AArch64(ARM 64-bit)
  • Hỗ trợ hugepage
    • Có thể tạo hugepage cho các trang guest
    • Cũng có thể dùng hugepage ở host → cải thiện hiệu năng
    • Ví dụ: khi cấp phát trang 2MB, hiệu năng biên dịch LLVM tăng 5%
  • Gọi hàm nhanh
    • Khi gọi hàm từ guest, overhead là 2μs
    • Khi chạy không có timer, overhead giảm xuống 1.2μs
  • Hỗ trợ gỡ lỗi từ xa
    • Có thể gỡ lỗi từ xa bằng GDB
    • Sau khi gỡ lỗi vẫn có thể tiếp tục chương trình bình thường
  • Hỗ trợ Copy-on-Write
    • Hỗ trợ tính năng fork riêng → có thể giảm thiểu sao chép bộ nhớ
    • Ví dụ: khi sao chép mô hình 6GB, mỗi instance chỉ cần 260MB bộ nhớ
  • Khởi tạo trạng thái nhanh
    • Có thể reset trạng thái guest nhanh chóng → tăng cường bảo mật
    • Reset theo từng request giúp giảm rủi ro lộ trạng thái
  • Codebase được đơn giản hóa
    • Sử dụng khoảng 42k LOC từ KVM API
    • Codebase riêng của TinyKVM khoảng 9k LOC → nhỏ hơn nhiều so với các giải pháp cạnh tranh
    • Ví dụ: Wasmtime 350k LOC, FireCracker 165k LOC
  • Tạo page table tĩnh
    • Không thể sửa page table trong lúc runtime → tăng cường bảo mật
    • Có thực hiện kiểm tra tính toàn vẹn của page table
  • Ngữ cảnh tiến trình tách biệt
    • Guest KVM dùng PCID/ASID riêng → có khả năng chống chịu tốt hơn trước các tấn công thực thi suy đoán như Spectre
  • Kernel được tăng cường bảo mật
    • Bật SMEP, SMAP
    • Có thể xử lý ngoại lệ CPU ở chế độ người dùng

Xử lý system call

  • Kết nối API với host
    • Thực hiện system call qua lệnh SYSCALL/SYSRET hoặc OUT
    • Khi thực hiện system call sẽ xảy ra VM exit → mất khoảng 1μs
    • Nên thiết kế API với đơn vị I/O lớn và hạn chế các lời gọi nhỏ

Benchmark

  • Overhead gọi VM
    • Đo tail latency khi reset VM
    • Nếu chỉ gọi đơn giản mà không reset thì overhead thấp
  • Hiệu năng bộ nhớ
    • Hiệu năng bộ nhớ ở mức bình thường
    • Ví dụ: trong benchmark HTTP có thể mã hóa 1500 AVIF mỗi giây
  • Hiệu năng chuyển đổi JPEG → AVIF
    • Có thể chuyển đổi khoảng 1582 ảnh mỗi giây
    • Có thể chuyển đổi không mất dữ liệu bằng đường dẫn chuyển đổi YUV

Vì sao hiệu năng sandbox lại nhanh

  • Không dùng I/O và driver
    • Không có I/O, driver hay thiết bị ảo → tránh suy giảm hiệu năng
    • Chỉ dùng tài nguyên CPU → đạt tốc độ gần native
  • Tối ưu hugepage
    • Dùng hugepage giúp giảm page walk → cải thiện hiệu năng
    • Đạt 99.7% hiệu năng native trên workload LLM quy mô lớn
  • Gọi VM nhanh
    • Giảm thiểu overhead khi gọi hàm từ guest
    • Có thể xử lý dữ liệu ở tốc độ CPU native

Hạn chế

  • Không thể giảm số lượng vCPU
    • KVM API không cho phép giảm số lượng vCPU
    • Có thể giải quyết xử lý đa tiến trình bằng cách chạy song song nhiều VM
  • Vấn đề suy giảm hiệu năng khi reset
    • Có thể phát sinh suy giảm hiệu năng khi reset trạng thái VM
    • Tuy nhiên có thể khắc phục bằng chia sẻ và sao chép trạng thái

Việc cần làm tiếp theo

  • Bổ sung hỗ trợ Intel TDX và AMD SEV
  • Port sang AArch64
  • Bổ sung tính năng khóa bộ nhớ (KVM_MEM_READONLY) → tăng cường bảo mật
  • Cải thiện API thân thiện hơn với người dùng
  • Bổ sung hỗ trợ tải liên kết động → tăng cường tích hợp với Varnish

Kết luận

  • TinyKVM là một trong những giải pháp sandbox nhỏ gọn và nhanh nhất
  • Đồng thời đạt được cả tăng cường bảo mật lẫn tối ưu hiệu năng
  • Codebase nhỏ nên dễ bảo trì
  • Được cung cấp dưới dạng thư viện mã nguồn mở → nếu quan tâm có thể xem kho mã

Kho TinyKVM

Bài viết liên quan

2 bình luận

 
xcutz 2025-03-16

Khá độc đáo
 
GN⁺ 2025-03-15
Ý kiến trên Hacker News

  • Rất thích nội dung này. Mong họ sẽ tiếp tục và không dừng việc mình đang làm

    • Tôi biết đây là một trong những người đóng góp chính cho IncludeOS. Khi đọc bài blog này, đó là dự án đầu tiên xuất hiện trong đầu tôi
    • Tôi đã bị ám ảnh với network function virtualization trong một thời gian dài. Đây là ranh giới tự nhiên nhất để tách đơn vị công việc trong hệ thống phân tán, đồng thời mang lại một lớp trừu tượng gọn gàng và cơ chế mở rộng hiệu quả
    • Tôi đang dùng Varnish trong production và rất hài lòng. Ở vài khía cạnh, nó còn đáng tin cậy hơn cả nginx. Thường thì tôi còn quên mất sự tồn tại của nó. Sau khi cấu hình đúng, nó chưa từng là nguyên nhân gây ra lỗi

  • Giống Firecracker nhưng nhanh hơn rất nhiều

    • Điều tôi thích nhất là khả năng lập tức đặt lại trạng thái của VM về một trạng thái được định nghĩa sẵn. Nó giống như khởi động lại VM mà không cần thực sự khởi động lại
    • Có vẻ là biện pháp lý tưởng cho các dịch vụ mạng liên tục bị tấn công. Ngay cả khi cuộc tấn công thành công, kết quả cũng sẽ bị xóa ở request tiếp theo
    • Khả năng chia sẻ trang COW dễ dàng cho các chương trình không được viết với mục tiêu đó, như trình chạy mô hình ML, cũng khá tuyệt

  • Bài gốc: liên kết

    • Có thể tìm thấy rất nhiều bài viết liên quan đến chủ đề này

  • Thật sự rất thú vị. Hiệu năng khôi phục snapshot 2.5us ngang với Wasmtime, nhưng có lợi thế lớn là có thể chạy mã native. Dù vậy, khả năng tương tác vẫn chậm hơn nhiều, dù vẫn ở mức micro giây

    • Trong kho tinykvm_examples đã có demo QuickJS, nhưng sẽ còn nhanh hơn nhiều nếu xác minh được rằng nó có thể chạy một JavaScript runtime có JIT
    • Trong thử nghiệm render phía máy chủ cho ứng dụng React, QuickJS native mất khoảng 12-20ms, còn v8 là 2-4ms sau khi JIT warm-up
    • Tôi cần tìm hiểu thêm, nhưng muốn tạo một file thực thi đơn kiểu Deno chạy trong sandbox và xử lý mọi HTTP request thông qua Varnish
    • Sau khi lấy JS URL được chỉ định, chụp snapshot rồi để mỗi request chạy trong một snapshot cách ly
    • Có lẽ sẽ cần một cơ chế đặt lại random seed theo từng request

  • Về cơ bản thì đây chẳng phải là thứ giống libkrun sao? liên kết

  • Dù đây không hẳn là mục đích sử dụng được nhắm tới, có ai từng có kinh nghiệm chạy X server (hoặc Wayland) trên đó chưa?

    • Tôi đang phát triển cho một RDP server trên Mac, và đôi khi có thêm những nhu cầu khác cho client. Hiện tại tôi đang dùng UTM (frontend QEMU cho Mac) và VM DietPi (Debian được tinh gọn rất nhiều)
    • Tôi quen với Docker, nhưng cũng hiểu khá rõ cần những bước gì để chạy một graphics server. Tôi đang tự hỏi liệu có cách nào đơn giản hơn không

  • Khá thú vị, nhưng tôi đang gặp khó khăn để hiểu bức tranh tổng thể. Có phải là chạy tiến trình người dùng trong VM mà không cần kernel không? Mọi system call sẽ khiến VM thoát ra để được proxy qua host sao? Hay là hoàn toàn không có system call?

  • Nếu phù hợp với use case thì đúng là rất tuyệt

    • Một vài ghi chú từ bài viết
    • Tôi thấy rằng TinyKVM chạy ở tốc độ bằng 99,7% native
    • Nếu không cần truy cập file hay mạng và là mã tĩnh, thì có thể chạy trực tiếp
    • Guest TinyKVM có một kernel nhỏ không thể sửa đổi

  • Thật sự rất tuyệt

    • Tôi đang khám phá micro-VM cho một PaaS tự lưu trữ, và mức overhead thấp khiến đây trông như một lựa chọn rất hấp dẫn

  • Bài viết không hề nói rằng nó chạy trên Varnish, và trên thực tế tác giả còn nói rằng nó không phải để chạy Varnish