1. So sánh hiệu năng truy vấn giữa Database thường và Database SGX
Để đánh giá mức độ ảnh hưởng của SGX lên throughput, ta sẽ thực hiện hai kịch bản: chạy MySQL chuẩn (non-SGX) và MySQL chạy trong Enclave (SGX-enabled).
Chuẩn bị môi trường: Đảm bảo cả hai instance đang chạy trên cùng một node vật lý, sử dụng cùng cấu hình CPU và RAM, chỉ khác biệt ở chế độ bảo mật.
Sử dụng công cụ sysbench để tạo tải đồng thời và đo độ trễ.
Trước tiên, cài đặt sysbench nếu chưa có:
sudo apt update && sudo apt install -y sysbench
Kết quả mong đợi: sysbench được cài đặt thành công, không báo lỗi thiếu dependency.
Chạy test với Database thường (Non-SGX) trên cổng 3306:
sysbench --test=oltp --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-pass=your_password --mysql-db=test_sgx --num-threads=8 --report-interval=1 --max-requests=10000 run
Ghi lại kết quả: transactions/sec và latency (avg) vào file /var/log/benchmark_non_sgx.log.
Chạy test với Database SGX (Enclave) trên cổng 3307 (hoặc cổng cấu hình của SGX instance):
sysbench --test=oltp --mysql-host=localhost --mysql-port=3307 --mysql-user=root --mysql-pass=your_password --mysql-db=test_sgx --num-threads=8 --report-interval=1 --max-requests=10000 run
Kết quả mong đợi: Số transactions/sec của SGX thấp hơn khoảng 15-30% so với non-SGX do overhead của mã hóa/giải mã và chuyển đổi context vào Enclave.
Phân tích sự khác biệt:
Overhead chính đến từ việc serialize/deserialize dữ liệu qua ranh giới Enclave (Enclave Boundary) và chi phí tính toán AES-GCM cho mỗi dòng dữ liệu.
Verify kết quả: So sánh hai file log. Nếu chênh lệch < 35%, cấu hình EPC và driver đang hoạt động tối ưu. Nếu chênh lệch > 50%, cần kiểm tra lại phần tối ưu EPC ở mục sau.
2. Đo lường overhead khi thực hiện mã hóa/giải mã trong Enclave
Mục tiêu là tách biệt overhead của cơ sở dữ liệu thuần túy và overhead do cơ chế mã hóa trong Enclave gây ra.
Sử dụng tool sgx-bench đi kèm với Intel SGX SDK hoặc viết script benchmark đơn giản để đo thời gian thực hiện AES-GCM.
Tạo script Python đơn giản để đo thời gian mã hóa 1MB dữ liệu ngẫu nhiên:
Đường dẫn: /root/sgx_encryption_bench.py
Nội dung file:
#!/usr/bin/env python3
import os, time
from cryptography.hazmat.primitives.ciphers.aead import AESGCM
def benchmark_aes(size_mb=1):
key = AESGCM.generate_key(bit_length=256)
data = os.urandom(size_mb * 1024 * 1024)
start = time.perf_counter()
for _ in range(100):
nonce = os.urandom(12)
aesgcm = AESGCM(key)
encrypted = aesgcm.encrypt(nonce, data, None)
aesgcm.decrypt(nonce, encrypted, None)
end = time.perf_counter()
print(f"Throughput: {(size_mb * 100 * 1024 * 1024) / (end - start) / 1024 / 1024:.2f} MB/s")
if __name__ == "__main__":
benchmark_aes()
Chạy script bên ngoài Enclave (host) để đo chi phí phần cứng AES-NI:
chmod +x /root/sgx_encryption_bench.py && python3 /root/sgx_encryption_bench.py
Kết quả mong đợi: Throughput đạt mức ~10GB/s trên CPU hỗ trợ AES-NI.
Bây giờ, cần đo overhead khi gọi hàm mã hóa từ bên trong Enclave. Sử dụng tool sgx-bench có sẵn trong SDK:
cd /opt/intel/sgxsdk/benchmarks && make sgx-bench
Chạy benchmark cụ thể cho AES-GCM:
./sgx-bench --aes-gcm --iterations=1000
Kết quả mong đợi: Throughput trong Enclave thấp hơn host khoảng 10-20% do chi phí gọi hàm ECall và quản lý bộ nhớ EPC, nhưng vẫn cao hơn đáng kể so với phần mềm thuần (software-only).
Verify kết quả: So sánh throughput của AES-GCM bên trong Enclave với kết quả benchmark Database SGX ở mục 1. Nếu overhead mã hóa chiếm > 50% tổng thời gian query, cần tối ưu kích thước block hoặc sử dụng batch processing.
3. Thực hiện kiểm thử tấn công giả lập để xác minh tính bảo mật
Kiểm tra khả năng chống lại các tấn công giả lập như Memory Scrapping (đọc RAM) và Code Injection.
Sử dụng tool sgx-dcap hoặc script Python để giả lập việc đọc bộ nhớ EPC từ bên ngoài Enclave.
Đầu tiên, kiểm tra xem Enclave có đang hoạt động và khóa (key) có được bảo vệ không:
cat /sys/fs/sgx/enclave_status | grep -E "0x[0-9a-f]+" | head -n 5
Kết quả mong đợi: Thấy các trạng thái enclave (INIT, RUNNING, TERMINATED). Không thể đọc trực tiếp nội dung EPC qua file system này.
Giả lập tấn công: Thử đọc trực tiếp file socket hoặc file dữ liệu tạm thời của MySQL SGX:
xxd /var/lib/mysql/sgx_data.bin | head -n 20
Kết quả mong đợi: Dữ liệu hiển thị là các chuỗi ngẫu nhiên (random bytes), không thể đọc được nội dung SQL hay dữ liệu thực tế. Đây là dấu hiệu mã hóa thành công.
Thử tấn công "Replay Attack" giả lập bằng cách gửi lại một gói tin đã được ký (signature) cũ:
Tạo script gửi lại request cũ:
curl -H "Authorization: Bearer OLD_TOKEN_FROM_LOG" http://localhost:3307/query?sql="SELECT * FROM users"
Kết quả mong đợi: Server trả về lỗi 401 Unauthorized hoặc 403 Forbidden vì Enclave từ chối token hết hạn hoặc nonce đã được sử dụng.
Verify kết quả: Nếu dữ liệu raw bị mã hóa và các request giả mạo bị từ chối, tính bảo mật của Enclave được xác nhận. Nếu đọc được dữ liệu rõ văn bản, cấu hình SGX đang bị lỗi nghiêm trọng.
4. Kiểm tra khả năng phục hồi (recovery) khi mất dữ liệu hoặc crash Enclave
SGX yêu cầu cơ chế lưu trữ trạng thái (state persistence) vì Enclave có thể bị reset bất cứ lúc nào (do lỗi phần cứng hoặc tấn công DoS).
Kịch bản: Gây crash Enclave bằng cách kill mạnh tiến trình MySQL SGX và kiểm tra khả năng khôi phục dữ liệu.
Đầu tiên, tạo một bản ghi kiểm tra (checkpoint) thủ công:
mysql -u root -p -h localhost -P 3307 -e "FLUSH TABLES WITH READ LOCK; SHOW STATUS LIKE 'Com_insert';"
Ghi lại số lượng transaction hiện tại.
Tiến hành kill tiến trình MySQL SGX để mô phỏng crash:
sudo kill -9 $(pgrep -f "mysql.*sgx")
Kết quả mong đợi: Tiến trình bị dừng ngay lập tức, socket file bị khóa hoặc xóa.
Khởi động lại service MySQL SGX:
sudo systemctl start mysql-sgx
Kiểm tra xem dữ liệu có còn không:
mysql -u root -p -h localhost -P 3307 -e "SELECT COUNT(*) FROM users;"
Kết quả mong đợi: Số lượng record phải bằng hoặc cao hơn (nếu có auto-commit trước đó) so với bước checkpoint. Không được báo lỗi "Corrupt database" hoặc mất dữ liệu.
Verify kết quả: Chạy script kiểm tra tính toàn vẹn (checksum) của dữ liệu đã khôi phục. Nếu checksum khớp, cơ chế recovery hoạt động tốt.
5. Tối ưu hóa bộ nhớ Enclave (EPC) cho workload thực tế
Enclave Page Cache (EPC) là tài nguyên giới hạn nhất của SGX. Nếu EPC đầy, hệ thống sẽ xảy ra "Page Fault" và phải swap ra bộ nhớ thường (untrusted memory), gây giảm hiệu năng nghiêm trọng.
Cấu hình file /etc/sgx_config.txt để điều chỉnh kích thước EPC tối đa.
Đường dẫn: /etc/sgx_config.txt
Nội dung file (ví dụ phân bổ 4GB cho EPC):
# SGX Configuration
EPC_SIZE=4096M
EPC_MAX=4096M
Chú ý: Tổng EPC_SIZE không được vượt quá 50% RAM vật lý hoặc giới hạn của CPU.
Áp dụng cấu hình:
sudo systemctl restart sgx
Kiểm tra kích thước EPC hiện tại:
cat /sys/class/sgx/epc0/size
Kết quả mong đợi: Giá trị trả về là 4294967296 (4GB in bytes).
Giám sát tỷ lệ Page Fault của Enclave MySQL:
watch -n 1 'grep -c "fault" /sys/kernel/debug/sgx/enclave_stats'
Nếu thấy số lỗi tăng nhanh, cần tăng EPC_SIZE hoặc giảm kích thước bảng hash của Database trong Enclave.
Tối ưu hóa trong MySQL Config (/etc/mysql/mysql.cnf.d/sgx.cnf):
Giảm kích thước buffer pool để phù hợp với EPC:
[mysqld]
innodb_buffer_pool_size = 2G
innodb_flush_log_at_trx_commit = 0
sgx_enclave_size = 3G
Khởi động lại MySQL:
sudo systemctl restart mysql-sgx
Verify kết quả: Chạy lại benchmark sysbench. Nếu latency giảm và throughput tăng ổn định mà không có spike page fault, việc tối ưu EPC thành công.
Điều hướng series:
Mục lục: Series: Triển khai Database Confidential Computing với Intel SGX trên Ubuntu 24.04
« Phần 5: Triển khai quy trình Attestation và xác thực Enclave
Phần 7: Xử lý sự cố nâng cao và các mẹo vận hành (Troubleshooting & Best Practices) »