HỒ CHÍ MINH TRƯỜNG ĐẠI HỌC BÁCH KHOA --- NGUYỄN DUY THÁI NGHIÊN CỨU, HIỆN THỰC GIẢI PHÁP TĂNG TỐC KHẢ NĂNG QUÉT VIRUS CỦA CLAMAV TRÊN PHẦN CỨNG Chuyên ngành: KHOA HỌC MÁY TÍNH Mã số:
GIỚI THIỆU ĐỀ TÀI
Tính cấp thiết của đề tài
Chương trình chống virus chạy dưới dạng phần mềm và tốc độ của phần mềm ngày càng giảm khi tập các mẫu chữ ký tấn công lên đến hàng trăm ngàn mẫu
Ngày nay, đối với các doanh nghiệp, cơ quan lớn như sở ban ngành, ngân hàng, trường đại học đều có hệ thống mạng tốc độ cao hàng Gigabit, nếu chỉ dựa vào phần mềm thì sẽ không hiệu quả
Nếu triển khai để bảo vệ một máy chủ mạng, phần mềm chống virus có thể không đáp ứng được yêu cầu về tốc độ cũng như độ an toàn khi số lượng người dùng tăng lên (các doanh nghiệp, cơ quan lớn)
Ví dụ, một máy chủ email cần phải quét tất cả thư đến và đi ra để đảm bảo rằng các email gửi đến người dùng cuối cùng là không có virus Lượng dữ liệu này có thể lên đến hàng terabyte mỗi ngày
Nâng cao tốc độ xử lý của hệ thống nhận diện virus chuyên dụng trên máy chủ không chỉ quan trọng mà còn cấp thiết Việc cải thiện tốc độ này sẽ góp phần tăng hiệu suất hệ thống, giúp xác định và ngăn chặn các mối đe dọa nhanh chóng và hiệu quả hơn.
Đặt vấn đề
Phần mềm quét virus ClamAV có tốc độ quét chậm (khoảng 12.746 MB/s) Để tăng tốc hệ thống, các nghiên cứu trên thế giới thường tập trung vào 2 hướng chính Đó là chỉ dùng phần cứng và phần mềm-phần cứng kết hợp Ở hướng tiếp cận chỉ dùng phần cứng trong công trình “The Parallel Sieve Method for a Virus Scanning Engine” [1] của nhóm nghiên cứu Hiroki Nakahara, Tsutomu Sasao,
2 Munehiro Matsuura và Yoshifumi Kawamura Chúng tôi đánh giá ưu và nhược điểm của hướng tiếp cận này như sau: Ưu điểm:
Sử dụng bộ nhớ hiệu quả MUC (memory utilization coefficient) : amount of memory per a character = 1.7 Bytes/Char)
Khó cập nhật cơ sở dữ liệu virus cho hệ thống Ở hướng tiếp cận kết hợp phần cứng và phần mềm trong công trình “Phần mềm- phần cứng kết hợp for high-speed signature-based virus scanning” của nhóm nghiên cứu Ying-Dar Lin, Po-Ching Lin và Yuan-Cheng Lai [4] thì họ đã giảm tải cho chương trình ClamAV bằng cách đẩy một phần xử lý so trung chuỗi xuống hệ thống BFAST (Bloom Filter Accelerated Sublinear Time) BFAST đóng vai trò như bộ lọc tiền xử lý dữ liệu quét Nếu như BFAST nghi ngờ có virus thì hệ thống sẽ báo lên phần mềm để kiểm tra kĩ hơn Chúng tôi đánh giá hướng tiếp cận này như sau: Ưu điểm:
Throughput của hệ thống BFAST (151 Mbps) tăng gấp 28 lần so với chương trình gốc ClamAV
Giá thành có thể chấp nhận
Dễ dàng cập nhật cơ sở dữ liệu virus cho hệ thống
Throughput đạt được vẫn còn thấp hơn rất nhiều so với mức độ mô phỏng hardware là 8.79 Gbps
Copy dữ liệu từ user space sang DMA buffer thì tiêu tốn rất nhiều thời gian
Throughput của toàn hệ thống có thể bị suy giảm do overhead từ việc truyền dữ liệu của DMA.
Mục tiêu nghiên cứu
Nghiên cứu và thiết kế được framework có tốc độ quét nhanh tối thiểu 4 lần so với phần mềm quét virus ClamAV.
Nghiên cứu và thiết kế giải pháp
Mục tiêu của chúng tôi là thiết kế 1 framework hoàn chỉnh trong 1 hệ thống quét virus trong 1 doanh nghiệp Do vậy, framework này ngoài tốc độ cao (khoảng từ 1 Gb/s) thì phải cho phép người dùng thể theo dõi, quan sát, cấu hình, cập nhật hệ thống một cách dễ dàng theo nhu cầu của người dùng Để làm điều này thì chúng tôi cần phải kết hợp giữa software và hardware Software đóng vai trò là tiếp nhận files, tiền xử lý, phân loại file, lọc tách data ra khỏi header Phần hardware sẽ đóng vai trò tăng tốc hệ thống cho ta biết rằng tốc độ của hardware chuyên dụng thì luôn cao hơn rất nhiều lần so với software Ngoài ra, để tăng tốc hệ thống hơn nữa, chúng tôi quyết định thiết kế phần cứng sao cho đảm nhận việc quét virus toàn bộ chứ không chỉ đóng vai trò bộ lọc Nếu để phần mềm phải quét lại dữ liệu nghi ngờ từ phần cứng gửi lên thì tốc độ quét của hệ thống sẽ chậm đi
Clam Antivirus (ClamAV) là một công cụ quét virut mã mở nguồn, được thiết kế đặc biệt cho việc kiểm tra e-mail trên các e-mail gateways Nó cung cấp một số tiện ích bao gồm khả năng mở rộng multi-threaded daemon (cung cấp dịch dụ quét qua các socket communications) Hiện tại, tổng số lượng chữ kí trong ClamAV là 2.423.843 (thống kê theo 23/4/2013) và số lượng chữ kí này vẫn tiếp tục tăng lên theo từng ngày Cơ sở dữ
4 liệu của ClamAV được chia thành ba nhóm: mẫu tĩnh, MD5 và mẫu động Mẫu tĩnh và mẫu MD5 chiếm tới 99.6% Thời gian so trùng mẫu tĩnh và mẫu động chiếm tới 84% thời gian quét file Đây chính là phần chạy chậm nhất trong phần mềm ClamAV Do đó, chúng tôi tiến hành thay thế các hàm này bằng các hàm giao tiếp socket với phần cứng bên dưới để tăng tốc độ quét virus
Như vậy, ta có thể áp dụng Amdahl’s law bên dưới để có thể tính toán tốc độ truyền DMA để không làm thắt cổ chai hệ thống
F là tỉ lệ phần được cải tiến,
E: Speedup của phần cải tiến
S: Speedup của toàn hệ thống
Theo kết quả tìm hiểu, chạy thử thì trong phần mềm ClamAV, 2 hàm cli_bm_scanbuff() và cli_ac_scanbuff() chiếm tổng thời gian là 84% Theo mục tiêu nghiên cứu, hệ thống framework cần nhanh hơn phần mềm ClamAV ít nhất là 4 lần Do đó S = 4, F=0.84 Thế vào công thức (1), ta có:
Theo đo đạc thực nghiệm, tốc độ quét của 2 hàm là khoảng 0,408 Gb/s Để hệ thống tăng tốc gấp 5 lần, cần cải tiến tốc độ quét của 2 hàm lên tối thiểu 9,3 lần, tương ứng với tốc độ hàm sau khi cải tiến là 3,7 Gb/s.
Để tối ưu giao tiếp giữa phần cứng và phần mềm mà không tiêu tốn nhiều chi phí overhead, bài báo sử dụng giao tiếp RAW socket Dữ liệu được sao chép từ user space sang kernel space vào TX buffer Đồng thời, để đảm bảo tốc độ truyền dữ liệu hiệu quả, tốc độ truyền dữ liệu tối thiểu của DMA phải đạt 3,7 Gb/s.
5 tay giữa phần cứng và phần mềm trong từng frame truyền bằng các trường như MAGIC code, loại packet, block ID, cũng như số lượng byte truyền
Tiếp theo, dữ liệu được DMA truyền từ TX bufer tới module quét virus HSVS (High speed virus scanner) DMA có 2 tần số hoạt động là 125 Mhz và 250 Mhz Do ở đây chúng tôi cần DMA hoạt động ở tốc độ cao lên hơn 4 Gb/s, nên chúng tôi cấu hình DMA hoạt động ở tần số 250 MHz vì ở tần số 125 MHz thì DMA chỉ đạt throughput tối đa là 2 Gb/s theo kết quả thực nghiệm
Sau khi dữ liệu quét tới HSVS (High speed virus scanner) thì cli_static_scanbuff() (là 1 hàm quét mẫu động được dùng để thay thế cli_bm_scanbuff() của ClamAV) sẽ đợi HSVS trả kết quả quét từng block về: có virus hay không có virus Nếu có virus thì gửi kèm thông tin số lượng virus, virus ID và cli_static_scanbuff() sẽ kết thúc việc quét ngay lập tức, không quét block tiếp theo Nếu như không có virus thì cli_static_scanbuff() sẽ gửi block tiếp theo để quét
Tương tự quá trình xử lý trên khi block dữ liệu được gửi tới cli_dynamic_scanbuff() để quét mẫu động
Khi quét tới block cuối cùng của file thì kết thúc xong việc quét 1 file, và quét file tiếp theo nếu có.
Những đóng góp của luận văn
Những đóng góp chính của luận văn là:
Cải tiến khả năng giao tiếp giữa phần mềm và phần cứng tránh được tình trạng thắt cổ chai
Our innovative HSAV Framework for high-speed virus scanning provides significant performance enhancements to the ClamAV antivirus software Designed and implemented to be compatible with any PCIe-equipped server, our framework enables ClamAV to leverage the enhanced capabilities of the PCIe interface This compatibility translates into markedly improved efficiency for ClamAV, resulting in faster and more effective virus detection.
Tích hợp được framework của chúng tôi vào ClamAV, phần mềm quét virus mã nguồn mở phổ biến được sử dụng rộng rãi nhất Đóng góp này chứng tỏ hiện thực của chúng tôi là có tính thực tế và khả thi
Chạy thử nghiệm và đánh giá hiệu suất của framework theo 2 tiêu chí: là thông lượng (throughput) và độ trễ (latency)
Những kết quả đạt được
Trong giới hạn thời gian làm luận văn, chúng tôi đã thiết kế framework của hệ thống tăng tốc quét virus phần cứng trên nền phần cứng (gọi tắt là HSAV) Hệ thống gồm có 3 phần chính là : phần cứng so trùng mẫu chữ kí tĩnh, phần giao tiếp giữa phần mềm và phần cứng và phần mềm quản lý bằng giao diện web
Qua thực nghiệm, HSAV có throughput của hệ thống đạt được trung bình là 541.6 Mb/s, nhanh gấp 4.2 lần so với giải pháp dùng phần mềm ClamAV có throughput là 65.6 Mb/s Như vậy, hệ thống của chúng tôi đã gần đạt yêu cầu và nhiệm vụ của đề tài là hệ thống sau khi cải tiến phải nhanh tối thiểu 4 lần so với phần mềm.
Cấu trúc của luận văn
Chương 2: Trình bày cơ sở lý thuyết của phương pháp so trùng chuỗi bao gồm 3 hướng tiếp cận chính là systolic array, FSM và hashing cũng như khảo sát phần mềm ClamAV
Chương 3: Tổng hợp các công trình nghiên cứu liên quan Chương này đề cập tới 2 kiểu framework tiêu biểu là kết hợp phần cứng và phần mềm và chỉ dùng phần cứng, đồng thời phân tích ưu và khuyết điểm của mỗi kiểu framework
Chương 4: Giới thiệu về hệ thống HSVS (High speed virus scanner) dùng để so trùng mẫu chữ kí tĩnh Phần này sẽ đề cập tới kiến trúc hệ thống, bộ quét kí tự (Character Scanning Unit), bộ so sánh (Comparison Unit)
Chương 5: Trình bày framework tăng tốc quét virus trên FPGA (HSAV): gồm các vấn đề như định nghĩa giao thức truyền nhận dữ liệu, thiết kế bộ điều khiển giao tiếp với PCIe
Chương 6: Kết quả và đánh giá khi chạy thực nghiệm hệ thống HSAV
Chương 7: Một số kết luận và hướng mở rộng của đề tài
CƠ SỞ LÝ THUYẾT
KHẢO SÁT PHẦN MỀM QUÉT VIRUS CLAMAV
Trong phần này, nhóm tiến hành khảo sát phần mềm quét virus mã nguồn mở ClamAV một cách toàn diện bao gồm:
Thiết lập môi trường phát triển hệ thống và cài đặt phần mềm ClamAV
Chạy thử nghiệm và cấu hình chức năng của ClamAV
Phân tích giải thuật và hoạt động của ClamAV
Phân tích tập chữ ký Virus của ClamAV
Phân tích source code, thời gian hoạt động các hàm quét trong ClamAV
Clam Antivirus (ClamAV) là một công cụ quét virut mã mở nguồn, được thiết kế đặc biệt cho việc kiểm tra e-mail trên các e-mail gateways Nó cung cấp một số tiện ích bao gồm khả năng mở rộng multi-threaded daemon (cung cấp dịch dụ quét qua các socket communications), một dòng lệnh máy quét và công cụ tiên tiến cho việc update tự động cơ sở dữ liệu Cái chính của gói là một công cụ chống virus có sẵn ở dạng thư viện chia sẻ
ClamAV được phát triển bởi nhiều công ty vừa và nhỏ trong hệ thống email của họ, ví dụ như:
Vermont State Government (United States of America)
Michigan University (United States of America)
2.1.2 Cơ sở dữ liệu chữ ký của ClamAV 2.1.2.1 Giới thiệu
Gói dữ liệu virus của ClamAV gồm có các file chính như sau
main.cvd: là dữ liệu chính, chứa các mẫu virus từ trước đến giờ
daily.cvd: là dữ liệu mới nhất, được cập nhật theo ngày
bytecode.cvd: là dữ liệu đặc biệt Nó giống như một đoạn chương trình, mà
ClamAV sẽ thông dịch để nhận diện các virus đa hình, cũng thực hiện một số sửa đổi trong chính bản thân nó
Safebrowsing.cvd: là dữ liệu có nguồn gốc từ google safe browsing, được chuyển đổi để có thể dùng trong ClamAV
Cơ sở dữ liệu virus chính của Clamav được lưu trữ trong file main.cvd File này sẽ được update trên mỗi version của Clamav Ngoài ra, người dùng còn có thể update cơ sở dữ liệu thông qua lệnh freshclam Chương trình sẽ tải dữ liệu mới và chứa trong file daily.cvd Kiểm tra phiên bản hiện tại của file cvd bằng lệnh sigtool:
Ví dụ với file main.cvd:
% sigtool -info main.cvd File: main.cvd
Signatures: 2424225 Functionality level: 60 Builder: neo
U44YuTP7vNpU3sZVfI54S78bkaJluqmkJCFX8skaNcNUPoTLnTxXtSuOwWufwn+M+
21kGR0CO7hvU3K+44YuOA92rMNNNmKOJOnli+lGv972THU2dkCL+491C6Y4Q+
169wIW+Zp/TyH93yt75qGv8vanBM1QdyXk8fnDvsOlC4 Verification OK
2.1.2.2 Định dạng chữ ký virus
File *.cvd là file đóng gói, chứa nhiều file dữ liệu chữ ký virus khác nhau Sử dụng lệnh sau để phân rã file cvd:
Mỗi tập tin được giải nén là danh sách các mẫu virus Mẫu virus trong mỗi file có định dạng khác nhau, ClamAV đọc mỗi file tùy vào tên của file:
File hdb chứa các giá trị hash MD5 của các file bị nhiễm virus Để tạo một file MD5, sử dụng sigtool như sau: sigtool –md5 file
Ví dụ 2.1: sigtool -md5 test.exe
2401851daa0343df8ff683f730fec39:92281:Dialer-85
SizeHình 2.1: Chữ kí MD5
48c4533230e1ae1c118c741c0db19dfb:17387:test.exe
PE sections can contain virus hash values To generate a sample virus PE section, divide different parts of a single file into smaller separate files, and use sigtool with the -mdb option.
File db chứa các mẫu virus ở dạng hex cho generic data, dùng cho các định dạng không nằm trong định dạng ClamAV hỗ trợ Nó được dùng cho cả AC & BM Định dạng của mẫu virus loại này là:
7168:a105e2cc8148158cd048360eb847c7d0:Trojan.Downloader-1421
Name _0017_0001_000!b8004233c999cd218bd6b90300b440cd218b4c198b541bb80
Hydra-Trojan00e81300eb3690be4801bf5a01b912008034f5
Mẫu virus này được tạo ra bằng cách sử dụng lệnh sau: cat virusfile | sigtool –hex-dump
Tương tự định dạng *.db, định dạng *.ba được sử dụng cho nhiều loại dữ liệu hơn, cho phép bổ sung thêm các thông tin cụ thể như định dạng của tập tin đích, vị trí bắt đầu của mã độc, giúp nâng cao độ tin cậy khi nhận diện.
MalwareName:TargetType:Offset:HexSignature [:MinFL:[MaxFL]]
Offset: chỉ vị trí bắt đầu tìm kiếm cho ClamAV
n: dời n bytes so với bắt đầu
EOF-n : cách kết thúc n bytes
MinEL, MaxEL: là các thông số optional, dùng để giới hạn sự có nghĩa của chữ ký trong phạm vi của một số engine
2.1.2.3 Thống kê các loại chữ kí trong ClamAV
Hiện tại, tổng số lượng chữ kí trong ClamAV là 2.423.843 và số lượng chữ kí này vẫn tiếp tục tăng lên
Trong luận văn này, chúng tôi lấy cơ sở dữ liệu virus từ http://www.clamav.net vào ngày 23 tháng 4 năm 2013 để phân tích những đặc tính chung của những loại chữ kí anti- virus điển hình
Bảng 2.1: Thống kê số lượng chữ kí theo 3 loại chính
Mẫu tĩnh Mẫu động Mẫu MD5
2.1.3 Phân tích hoạt động ClamAV 2.1.3.1 Tổng quát hoạt động
Hình 2.2: Sơ đồ hoạt động của ClamAV
Quá trình hoạt động của ClamAV được tóm tắt trong Hình 2.2 ClamAV thực hiện quét theo từng kiểu tệp và sử dụng các dữ liệu chữ ký và thuật toán so trùng tương ứng với từng kiểu tệp Có ba phương pháp nhận dạng mà ClamAV sử dụng:
Hashing a AC & BM sẽ tìm kiếm mã nhận dạng trên nội dung của file
15 Mã nhận dạng của AC là mã đa hình, có sử dụng các ký tự wildcard như ?, :
Mã nhận dạng của BM là mã duy nhất, là chuỗi các ký tự xác định :
0600e81300eb3690be4801bf5a01b912008034f5 b Hashing sẽ được thực thi trên toàn bộ, hoặc 1 phần của file, rồi tiến hành so sánh với hashtable để nhận diện virus
Cấu trúc và mục đích của một số định dạng file như sau:
2.1.3.2 Khảo sát hàm quét trong ClamAV send block có kích thước tối đa 131KB() cli_bm_scanbuff()
Virus found cli_ac_scanbuff()
Scanmanager() loads the database (cli_loaddb()) and creates a new engine (cl_engine_new()) Cli_bm_init() initializes the bookmark system Scanfile() scans the file and magic_scandesc() identifies its type (e.g., PE, HTML, PDF) Matcher_run() performs a content-based search If the file is recognized and has a valid extension (yes, yes), the engine is recreated (cl_engine_new()) Filter_search_ext() checks for a valid extension (yes, no) and returns results only if the buffer size is positive (yes, no).
Hình 2.3: Lưu đồ quét file virus tóm tắt của ClamAV
17 Hình bên trên mô tả tổng quát cấu trúc hàm gọi của chương trình ClamAV Một chu trình thực thi quét của ClamAV bao gồm các bước sau:
Khởi tạo hệ thống: khởi tạo thư viện clamav (cl_init), khởi tạo máy so trùng (cl_engine_new)
Cấu hình máy so trùng: cấu hình tham số điều khiển dựa trên file cấu hình clamAv (setup engine), đọc cơ sở dữ liệu chữ ký (load database), tổng hợp máy so trùng ({compile engine), cấu hình các tham số điều khiển dòng lệnh (set scan option)
Hàm `magic_scandesc()` phân loại file để trích xuất mã cần quét Sau đó, `matcher_run()` quét từng khối 131 KB đã được `magic_scandesc()` chia nhỏ `filter_search_ext()` lọc bước đầu bằng cách so sánh 8 byte đầu của dữ liệu cần quét với chữ ký trong cơ sở dữ liệu Nếu trùng khớp, dữ liệu sẽ được chuyển đến `cli_bm_scanbuff()` và `cli_ac_scanbuff()` `cli_bm_scanbuff()` quét mẫu tĩnh, tìm ra virus sẽ báo cáo ngay Nếu không tìm thấy, `cli_ac_scanbuff()` sẽ quét mẫu động Nếu phát hiện virus, quá trình quét sẽ kết thúc, còn nếu không, sẽ tiếp tục quét các khối tiếp theo của file.
18 Hình 2.4: Sơ đồ cấu trúc gọi hàm trong ClamAV
Khái niệm so trùng mẫu
So trùng mẫu là một tác vụ cơ bản trong hệ thống quét virus Tác vụ này có thể hiểu là việc tìm kiếm sự xuất hiện của một hoặc nhiều mẫu được định nghĩa trước trong trong một chuỗi liên tục các ký tự (byte) Mẫu ở đây có thể được mô tả dưới dạng một chuỗi các ký tự (byte) với chiều dài cố định (mẫu tĩnh) hoặc chuỗi các ký tự xen kẽ với
19 các siêu ký tự (mẫu động) Mẫu động thường được biết đến với định dạng biểu thức chính quy (regular expression)
2.2.1 Mẫu tĩnh (static pattern) Được mô tả dưới dạng một chuỗi byte với chiều dài cố định
Ví dụ: "|81 F1 03 01 04 9B 81 F1 0 1|" sẽ tương đương với chuỗi byte
2.2.2 Mẫu động (dynamic pattern) Đối với so trùng đa mẫu, bên cạnh việc tìm kiếm sự xuất hiện của từng mẫu đơn, đòi hỏi phải có lưu lại và kết hợp với trạng thái so trùng trước đó Việc so trùng đa mẫu là một bài toán phức tạp đặc biệt là xử lý trên phần cứng
Sử dụng các biểu thức chính quy (Regular Expression) để diễn tả: là một cách ghi chú súc tích để diễn tả một tập các chuỗi mà không cần thiết phải liệt kê tất cả các thành phần của tập đó Nếu một chuỗi được định nghĩa bởi một biểu thức chính quy, ta nói rằng biểu thức đó trùng với chuỗi Biểu thức chính quy được viết bằng một ngôn ngữ hình thức với một cú pháp nhất định Chúng bao gồm một số toán tử cơ bản (hay còn gọi là các wildcard), mà nếu kết hợp với nhau, ta có thể mô tả bất kỳ một tập các chuỗi phức tạp nào một cách súc tích
Trong cơ sở dữ liệu của ClamAV, các mẫu virus động biểu diễn bằng biểu thức chính quy theo wildcard được lưu trong file ndb và file db Các mẫu virus này được biểu diễn bằng các chuỗi hệ hex kết hợp thêm các wildcard
Bảng 2.2: Các loại wildcard được sử dụng trong ClamAV wildcard Diễn giải
?? So trùng với một byte bất kì
* So trùng với một số lượng byte bất kì
{-n} So trùng với n byte hoặc ít hơn
{n-} So trùng với n byte hoặc nhiều hơn
{n-m} So trùng từ n byte đến m byte (m > n) (aa|bb|cc| ) So trùng với aa hoặc bb hoặc cc
HEXSIG[x-y] / [x-y]HEXSIG So trùng với chuỗi có aa đi liền với 1 chuỗi hex.
Các phương pháp so trùng chuỗi
Systolic array là một tập hợp các Data Processing Units (DPUs) được kết nối với nhau tạo thành một cấu trúc ma trận như bên dưới Mỗi DPU nhận dữ liệu xử lý bởi DPU trước và cung cấp kết quả cho DPUs láng giềng
Hình 2.5: a) Kiến trúc tổng quát của Systolic Array b) Mô hình cụ thể của 1 node Kết cấu riêng biệt của Systolic array phù hợp với so trùng mẫu được biểu diễn ở hình
2.3b Mỗi DPU chứa 1 ký tự của mẫu Giả sử chúng ta có mẫu P 6 ký tự, chúng ta cần 6 DPUs T là văn bản đang được kiểm tra Y là output sẽ là ‘1’ khi Systolic array phát hiện ra T chứa mẫu P
Mỗi ký tự của T sẽ được broadcast tới tất cả DPUs
Mỗi DPU sẽ so sánh kí tự với kí tự Pj của mẫu P Nếu cả 2 kí tự đều giống nhau và output của DPU trước đó là ‘1’, thì DPU này cũng báo cáo là match, và output là ‘1’
Ví dụ 2.7: Cho mẫu P và chuỗi T
Each DPU sẽ gán 1 kí tự của mẫu P:
Mỗi kí tự trong T sẽ được broadcast đến các DPU Bảng sau sẽ mô tả output của mỗi DPU tương ứng với input của T
Bảng 2.3: Output của mỗi DPU khi kiểm tra chuỗi T
In general, the pattern matching system uses Finite State Machine (FSM) based on Aho-Corasick algorithm and Extended Aho-Corasick algorithm Figure 2.4 shows an example of a state graph of a pattern set.
Mỗi vòng tròn là một trạng thái của hệ thống Mũi tên thẳng đi từ trạng thái hiện tại sang trạng thái kế tiếp khi đầu vào (input) là giống nhau với các kí tự bên cạnh nó hoặc nếu như ko có kí tự nào thì sẽ chuyển trạng thái bằng 1 mũi tên đứt nét
Bắt đầu từ trạng thái 0, hệ thống sẽ chuyển sang trạng thái 1 khi tín hiệu vào là
Nếu hệ thống nhận được tín hiệu “e”, nó sẽ chuyển qua trạng thái 2 và đưa ra output “he” Nếu tín hiệu vào là “i”, hệ thống sẽ chuyển sang trạng thái 6 và đợi tín
23 hiệu vào tiếp theo Nếu tín hiệu vào khác “e” và “i”, hệ thống sẽ trở về trạng thái 0 và đợi tín hiệu vào tiếp theo
Hình 2.6: Máy trạng thái cho tập mẫu P = {he,she,his,hers}
Hạn chế của phương pháp máy trạng thái:
Trong cơ sở dữ liệu của CLAMAV có rất nhiều trường hợp nhiều ?? (so trùng với 1 byte bất kỳ) liên tiếp nhau và nhiều dấu * (so trùng với một số lượng byte bất kỳ), điều này dẫn đến sự bùng nổ trạng thái khi xây dựng máy trạng thái, không thích hợp với các hệ thống có dung lượng bộ nhớ nhỏ
Hashing là một phương pháp lưu giữ và lấy lại được các record từ cơ sở dữ liệu Hashing cho phép thêm, xóa, tìm kiếm 1 record dựa vào việc tìm kiếm các key Trong thực tế, hệ thống hash-based chỉ cần xem xét 1 hoặc 2 record cho mỗi việc thêm, xóa hay kiếm các task Hashing có hiệu suất tốt hơn khi so sánh với những giải thuật tìm kiếm như BST (Binary Search Tree) với độ phức tập là 0(log n)
24 Để sử dụng giải thuật hashing, chúng ta cần hàm hash và bảng hash (index tables) Ngoài ra, tìm kiếm keys cho records cũng phải được xác định Ví dụ 2.8 cho thấy làm thế nào hệ thống hashed-based cơ bản hoạt động
Ví dụ 2.8: Để đơn giản, chúng ta giả sử rằng các mẫu có chung độ đài
Search key: chúng ta chỉ xem xét liệu mẫu P có xuất hiện trong text T hay không, do đó, tìm kiếm khóa cũng chính là mẫu P
Hàm hash: H() với input là P1 và P2 Sau khi tính toán H(), chúng ta có giá trị hash cho mỗi mẫu Các giá trị này cũng là vị trí của các mẫu trong bảng hash
Bảng hash: là một mảng của các chuỗi mà độ dài là 10 Chuỗi sẽ được lưu trong phần tử tương ứng với giá trị hash H() của các mẫu
Tất cả các chuỗi con của T sẽ được xem xét để xác nhận nó có trùng với mẫu P1 hay P2 Bảng 2.3 mô tả quá trình so trùng
Bảng 2.4: Quá trình so trùng
Input H() Giá trị trong bản hash Kết quả
25 (*) Đây là một vấn đề phổ biến trong phương pháp hashing, gọi là collision Collision xảy ra khi 1 hàm hash ra kết quả tương tư cho các key khác nhau Kết quả là, chúng ta cần thêm vào 1 bước so sánh để đảm bảo rằng đó có phải là trùng thực sự hay không
Bảng 2.5 so sánh các kĩ thuật State machine, Systolic array và Hashing về tốc độ (hiệu suất và thời gian delay giữa input và kết quả so trùng), diện tích (logic cell cost và SRAM cost) và khả năng cập nhật database
26 Bảng 2.5: So sánh ba phương pháp so trùng mẫu
Tốc độ (speed) Diện tích (area) Khả năng cập nhật
Nhanh vì sử dụng chủ yếu các flip- flop trong chip FPGA và cung cấp kết quả gần như tức thì
Phụ thuộc và số lượng và độ dài mẫu
Cần cập nhật lại toàn bộ hệ thống khi có 1 thay đổi về database
Nhanh vì sử dụng chủ yếu các flip- flop trong chip FPGA và cung cấp kết quả gần như tức thì
Phụ thuộc và số lượng và độ dài mẫu
Cần cập nhật lại toàn bộ hệ thống khi có 1 thay đổi về database
Hashing Nhanh hơn, sử dụng chủ yếu chủ yếu SRAM và cần bổ sung 1 bước so sánh để đảm bảo cho việc so trùng
Cần ít logic cell hơn
Số lượng các logic cell không phụ thuộc vào số lương cũng như độ dài của mẫu
Tuy nhiên, phương pháp này sử dụng nhiều SRAM
Số lượng SRAM phụ thuộc vào số lượng các mẫu, không phụ thuộc vào độ dài mẫu
Database có thể cập nhật mà không cần phải cấu hình lại toàn bộ hệ thống vì tất cả các thông tin được lưu trong SRAM
TỔNG HỢP CÁC CÔNG TRÌNH NGHIÊN CỨU LIÊN QUAN
Kết hợp phần cứng và phần mềm
Năm 2009, Ying-Dar Lin, Po-Ching Lin và Yuan-Cheng Lai [4] đã giảm tải cho chương trình ClamAV bằng cách đẩy một phần xử lý so trung chuỗi xuống hệ thống BFAST (Bloom Filter Accelerated Sublinear Time) Nhóm nghiên cứu đã hiện thực giải thuật Aho-Corasick trong chương trình ClamAV ở mức phần cứng
Nhóm nghiên cứu nhận thấy rằng quá trình truyền dữ liệu từ host PC xuống phần cứng làm giảm throughput của hệ thống một cách rõ rệt
28 Hình 3.1: Sơ đồ khối chung của hệ thống quét virus : phân hoạch hardware và software trong codesign
ClamAV đẩy những chức năng chính trong việc sao trùng chữ kí của virus xuống hệ thống BFAST vốn có thể nhanh chóng lọc ra những đoạn dữ liệu nào không có virus
Thư viện Matcher-bfast sẽ gọi driver để cho phép DMA truyền dữ liệu vào bộ nhớ trên BFAST, là hệ thống có thể quét được chữ kí trong những chuỗi đơn giản Nếu như hệ thống BFAST nghi ngờ dữ liệu có chứa virus thì nó sẽ đẩy dữ liệu này lên thư viện Matcher-bm để kiểm tra kĩ hơn xem có virus hay không
Phần lớn dữ liệu không chứa virus, bộ lọc sẽ trở nên rất hiệu quả Hệ thống BFAST có thể giúp cho việc quét những đoạn dài trong chữ kí gồm nhiều đoạn trong thư viện Matcher-ac vì hệ thống có thể thực hiện điều này rất nhanh Tuy nhiên, thư viện
29 Matcher-ac phải ngăn những đoạn ngắn trong quá trình làm ngắn khoảng cách dịch chuyển trong BFAST vì BFAST không xử lý các đoạn ngắn một cách có hiệu quả Mô hình có lợi điểm Bởi vì các string dài có thể tạo ra nhiếu nút trong quá trình biểu diễn máy trạng thái gây lãng phí bộ nhớ Do vậy, chúng ta nên để những đoạn dài này cho BFAST xử lý để giảm yêu cầu bộ nhớ Lưu ý là Hình 3.1 không cho thấy thư viện Matcher-ac vì nhóm nghiên cứu không xử lý ở đây
Hình 3.2: 5 module chính trong hệ thống BFAST
Module TextPoint: lưu trữ vị trí cửa sổ hiện tại, được khởi tạo bởi 2 thanh ghi chưa địa chỉ và chiều dài dữ liệu tương ứng
Module HashGenerator: tạo ra giá trị băm 14-bit dùng để tra trong Bloom filter từ 4 hàm băm: H0, H1, H2 và H3
BloomFiilterQuery: lái khoảng cách dịch chuyển của cửa sổ bằng cách truy vấn tới Bloom Filter Module này có 8 MbitVector 4KB lưu trữ chữ kí trong các Bloom filter
TPController điều khiển 4 module còn lại, bao gồm cả việc dịch cửa sổ tìm kiếm và lưu trữ trạng thái vào thanh ghi Có 5 TPController, mỗi TPController sẽ thực hiện một pipeline 5 giai đoạn, với mỗi giai đoạn quét một phần dữ liệu trong bộ đệm dữ liệu TexRam Ví dụ: TPController0 sẽ quét từ byte 0 đến byte 1599, TPController1 từ byte 1600 đến 3199, v.v.
ClamAV lấy thông tin từ BFAST bằng 2 cách Cách 1, nếu BFAST nghi ngờ có virust, nó sẽ interrupt CPU và báo cáo cho ClamAV để kiểm tra Với cách này, CPU có thể thực hiện những việc khác trong khi BFAST quét virus Tuy nhiên, việc chuyển ngữ cảnh sau khi interrupt là một chi phí overhead Nếu nhiều virus nghi ngờ xuất hiện thì chi phí overhead này có thể lơn Cách 2, ClamAV có thể biết được trạng thái của BFAST bằng cách polling Do đó, ClamAV có thể lập tức nhận diện ra virus bị nghi ngờ mà không cần phải đợi chuyển ngữ cảnh Cách này sẽ nâng throughput của quét virus nhưng lại làm giảm hiệu suất của hệ thống Để hiện thực thư viện Matcher-bfast, nhóm nghiên cứu thêm 3 chức năng BFAST vào trong Matcher-bm
1 Đầu tiên, hàm bfast_init mở thiết bị và trả về cho BFAST file descriptor
2 Khi ClamAV đọc chữ kí virus từ cơ sở dữ liệu của ClamAV, nó gọi hàm bfast_addpatt để lưu trữ patter vào trong MbitVectors
3 Cuối cùng, ClamAV gọi hàm bfast_scanbuff để quét dữ liệu trong buffer được load từ file
Giao tiếp giữa hardware và software:
ClamAV sử dụng thư viện Matcher-bfast để truy cập trình điều khiển cho phép BFAST quét dữ liệu TextRAM và kiểm tra trạng thái của BFAST Trình điều khiển cung cấp các hàm truy xuất dữ liệu trong TextRAM0, TextRAM1, HashGenerator và MbitVector, bao gồm các chức năng ghi bộ nhớ, quét vi-rút và kiểm tra trạng thái truy xuất.
31 đủ, TPController bắt đầu quét dữ liệu và ghi trạng thái vào trong thanh ghi DMA truyền dữ liệu từ bộ nhớ vật lý tới TextRAM trong BFAST
ClamAV load chữ kí từ cơ sở dữ liệu chữ kí vào trong module BloomFilter-Query Sau khi load chữ kí, ClamAV đọc file được quét vào trong block 128 KB và thư viên Matcher –bfast gọi driver để load tuần tự nội dung file vào trong buffer của driver và cho DMA chuyển dữ liệu từ buffer vào trong TextRAM Nếu BFAST xác định ko có virus, nó sẽ report là file không bị nhiễm virus Ngược lại, ClamAV sẽ pass phần dữ liệu đó tới Matcher-bm để kiểm tra kĩ hơn Ưu điểm:
Throughput của hệ thống BFAST (151 Mbps) tăng gấp 28 lần so với chương trình gốc ClamAV
Giá thành có thể chấp nhận
Dễ dàng cập nhật cơ sở dữ liệu virus cho hệ thống
Throughput đạt được vẫn còn thấp hơn rất nhiều so với mức độ mô phỏng hardware là 8.79 Gbps
Copy dữ liệu từ user space sang DMA buffer thì tiêu tốn rất nhiều thời gian
Throughput của toàn hệ thống có thể bị suy giảm do overhead từ việc truyền dữ liệu của DMA
Hướng tiếp cận chỉ dùng phần cứng
Năm 2009, Hiroki Nakahara, Tsutomu Sasao, Munehiro Matsuura và Yoshifumi Kawamura [1] đã đề xuất một kiến trúc mới cho hệ thống quét virus Phương pháp được đề xuất là sử dụng so trùng 2 tầng Tầng 1: một bộ lọc hardware sẽ nhanh chóng scan
To align partially 32 chains, the second level uses an MPU (Micro Processor Unit) to completely align within 514,287 virus samples To simplify the hardware filter, the team utilized FIMM (Finite Input Memory Machine) In order to minimize the memory, the research team introduced the parallel filtering method.
Hình 3.3: Hệ thống quét virus
Theo phân tích, giai đoạn 1 của ClamAV chiếm đến 83% CPU time, trong khi giai đoạn 2 chỉ chiếm 17% Do đó, để nâng cao thông lượng của hệ thống, nhóm nghiên cứu đã cân nhắc các biện pháp cải tiến như sau:
Hardware automation: để cải tiến giai đoạn đầu sử dụng bộ lọc hardware thay vì software Đối với hệ thống quét virus, thì do các packet có thể quét kiểm tra một cách độc lập nên quá trình xử lý song song cho bộ lọc hardware có thể được áp dụng
33 Giảm so trùng từng phần ở giai đoạn đầu: để giảm tải cho giai đoạn thứ 2 Việc tăng chiều dài so trùng mẫu có thể giảm match từng phần Điều này sẽ làm giảm tải cho MPU
Tuy nhiên, điều này sẽ tăng kích thước bộ nhớ cho giai đoạn đầu tiên
Hình 3.4: Một ví dụ về so trùng chuỗi 2 tầng
Hình 3.5: Hệ thống quét virus Ưu điểm:
Sử dụng bộ nhớ hiệu quả MUC (memory utilization coefficient) : amount of memory per a character = 1.7 Bytes/Char)
Khó cập nhật cơ sở dữ liệu virus cho hệ thống
Có khá nhiều các nghiên cứu đã được thực hiện để tăng tốc quét virus dựa trên phần cứng Tuy nhiên một framework toàn diện để quét virus với cơ sở dữ liệu của ClamAV vẫn chưa được nghiên cứu Đề tài quan tâm đến một kiến trúc tổng quát để tăng tốc việc so trùng mẫu của ClamAV để từ đó tăng tốc độ quét virus của ClamAV
GIỚI THIỆU HỆ THỐNG HIGH SPEED VIRUS SCANNER (HSVS)
Giải pháp Bloom – Bloomier Filter
Mặc dù các phương pháp perfect hashing tree, cuckoo hashing và bloomier filter đều cung cấp thời gian tìm kiếm hằng số, nhưng chúng đòi hỏi một bước so sánh chuỗi đầu vào với mẫu thật được lưu ngoài chip Bước so sánh này thường diễn ra trên bộ nhớ ngoài (off-chip memory) có tốc độ chậm, làm giảm hiệu suất tổng thể.
Bloom filter thì chỉ được dùng hiệu quả khi cần kiểm tra một chuỗi có thuộc một tập các mẫu cho trước hay không với một xác suất có thể chấp nhận được Đề đảm bảo xác suất đúng hoàn toàn, ta lại phải thực hiện bước so sánh chuỗi input với tất cả các mẫu có trong tập hợp
Dựa vào sự giống nhau giữa ý tưởng giải thuật, giải pháp của chúng tôi đưa ra là kết hợp Bloomier Filter và Bloom Filter để có thể giảm thiểu việc truy xuất bộ nhớ ngoài để thực hiện quá trình so sánh Chúng tôi sử dụng thêm một bit bên cạnh các Bloomier bit trong bảng chỉ mục và gọi đó là “Bloom bit” Bloom bit này không phải là phần thông tin được mã hóa mà hoạt động riêng lẻ như một Bloom Filter độc lập Chúng tôi sử dụng bảng Bloom này để kiểm tra một chuỗi có thuộc một tập cho trước hay không Nếu tất cả Bloom bit trong vị trí hash ra đều là 1 thì hệ thống sẽ giải mã thông tin được lưu trong bảng Bloomier và bắt đầu quá trình so sánh chuỗi
So sánh bloom filter, bloomier filter và HSVS
Giả sử ta có tập các mẫu P = {“a”, “b”, “c”, “d”, “e”, “f”}
Và tập các chuỗi input T = {“w”, “y”, d”}
Bảng 4.1: So sánh hoạt động của Bloom filter, Bloomier Filter và Bloom - Bloomier filter
Không tồn tại trong tập hợp
Tồn tại trong tập hợp
So sánh chuỗi “y” với tất cả các mẫu trong tập không trùng
Tồn tại trong tập hợp
So sánh chuỗi “d” với tất cả các mẫu trong tập trùng
So sánh chuỗi “w” với mẫu “b” không trùng
So sánh chuỗi “y” với mẫu “e” không trùng
So sánh chuỗi “d” với mẫu “d” trùng
Không tồn tại trong tập hợp
Tồn tại trong tập hợp
So sánh chuỗi “y” với mẫu “e” không trùng
Tồn tại trong tập hợp
So sánh chuỗi “d” với mẫu “d” trùng
Bảng 2.2 cho thấy Bloom – Bloomier Filter có tần suất truy cập bộ nhớ ngoài để so sánh chuỗi input với mẫu là ít nhất do đó hiệu suất hoạt động là cao nhất, tốc độ cao nhất
Kiến trúc hệ thống
Hình 4.1: Kiến trúc tổng thể hệ thống HSVS
Hệ thống HSVS ở Hình 4.1 bao gồm bộ quét kí tự (Character Scanning Unit), bộ so sánh (Comparison Unit) và bộ nhớ ngoài (off-chip) lưu các mẫu gốc Bộ quét kí tự có ba phần chính: bộ hash riêng lẻ (Stanalone Hash Unit), bộ Bloom – Bloomier (Bloom – Bloomier Unit) và bộ nhớ trong (on-chip memory) để lưu các chuỗi nghi ngờ Nếu một bộ Bloom – Bloomier phát ra tín hiệu trùng (match), chuỗi tình nghi được chuyển vào bộ nhớ trong
(on-chip memory) Sau đó, mẫu gốc và chuỗi được đưa vào bộ so sánh Khi một tín hiệu trùng được xác nhận (confirm), hệ thống xuất tín hiệu trùng và ID của mẫu Để tăng throughput, chúng tôi tổ chức các bộ SHU và BBU hoạt động song song (parallel) và pipeline như Hình 4.2 Mỗi bộ SHU và BBU sử dụng các kết quả hash nhận được từ các bộ phía trước và kí tự đầu vào đế tính toán giá trị hash của riêng nó Cấu
38 trúc này cho phép chúng ta quét các chuỗi con (substring) có độ dài khác nhau trong cùng một thời điểm [5]
Hình 4.2: Cơ chế quét chuỗi song song
NGHIÊN CỨU THIẾT KẾ FRAMEWORK
Tổng quan
Framework được thiết kế để tạo ra môi trường thống nhất giúp phần mềm giao tiếp với phần cứng ở tốc độ cao, tránh tạo ra nút thắt cổ chai Với bo mạch NetFPGA10G, giao tiếp giữa máy tính và bo mạch được thực hiện thông qua PCIe, một giao thức tốc độ rất cao Do đó, giao tiếp này sẽ được tận dụng trong framework của hệ thống HSAV Theo kế hoạch, framework sẽ được hiện thực theo mô hình card tăng tốc, tức là các hàm cần tăng tốc sẽ được thực hiện trên bo mạch NetFPGA Khi chương trình máy tính cần thực hiện một chức năng nào đó, nó chỉ cần gửi yêu cầu cùng dữ liệu xuống bo mạch NetFPGA.
HIGH SPEED ANTI-VIRUS (HSAV)
TX buffer cli_static_scanbuff() cli_dynamic_scanbuff()
Hình 5.1: HSAV system block diagram
41 Hình 5.2: Sơ đồ khối của hệ thống
NetFPGA 10G được phát triển dựa trên phần mềm Xilinx Embedded Development Kit (EDK) và AXI4 interface của kiến trúc ARM Việc sử dụng EDK và AXI4 interface thực sự là một nền tảng thiết kế hệ thống tốt AXI4 interface giúp thiết kế đạt hiệu năng và sự linh hoạt cao Khi sử dụng AXI4 interface, người thiết kế có thể chỉ cần biết một giao thức đơn giản do toàn bộ các module (IP) sẽ đều được kết nối vào một bus chung (AXI bus) Người thiết kế cũng không gặp phải nhiều khó khăn khi chuyển những thiết kế cũ của mình sang thiết kế mới sử dụng AXI4 interface
Trước đây, EDK chủ yếu được sử dụng trong những thiết kế System on Chip (SoC)
Từ phiên bản 12 trở đi, EDK hỗ trợ chuẩn giao diện AXI4, giúp nó trở thành công cụ thiết kế hiệu quả cho nhiều dự án, bao gồm cả những dự án không phải SoC EDK thay thế gần như hoàn toàn ISE, cho phép người dùng:
42 thiết kế hệ thống của mình một cách toàn diện hơn, dễ dàng hơn, trực quan hơn khi EDK hỗ trợ người dùng giao diện đồ họa kèm theo hệ thống IPcores lớn, đa dạng
Hình 5.3: Sơ đồ khối board NetFPGA10G
Nền tảng NetFPGA 10G là một thiết bị phần cứng được kết hợp với hệ thống mã nguồn mở Phần cứng chính của board là PCI Express với 4 cổng 10 Gigabit Ethernet và một chip FPGA là Xilinx Virtex-5
Chip Virtex-5 có tốc độ trung bình cao hơn khoảng 30% so với dòng chip trước đó là Virtex-4 và cao hơn gấp đôi so với Virtex II pro (được dùng trên board NetFPGA1G)
Ngoài tốc độ cao, Virtex-5 còn có thể đáp ứng các thiết kế lớn do có trên 300,000 logic cells, cao gấp 6 lần dòng chip Virtex II pro
Với 8 lane PCI Express, mỗi lane có tốc độ 5Gbps, NetFPGA10G cho tổng băng thông lên đến 40Gbps, giúp cho việc truyền nhận dữ liệu rất nhanh chóng Ngoài ra thông lượng dữ liệu nằm trong khoảng rất rộng từ 622 Mbps đến 6.5Gbps, hỗ trợ cho hầu hết các chuẩn giao tiếp khác nhau Kết hợp với bộ nhớ tốc độ cao 3x36bit QDRII SRAM
43 (3x27MB) và 2x64bit RLDRAMII (2x288MB), board NetFPGA10G cung cấp một giải pháp bộ nhớ lý tưởng cho các ứng dụng mạng.
Các thành phần trên board
Xilinx Virtex-5 XC5VTX240T-2FFG1759C FPGA
4 interface SFP+ (hỗ trợ cả 2 chế độ 1Gbps và 10Gbps)
X8 PCI Express Gen 2 (5Gbps/lane)
3 x36 Cypress QDR II (CY7C1515JV18)
4 x36 Micron RLDRAM II (MT49H16M36HT-25)
2 Xilinx Platform XL Flash (2x128mb)
Tổng quan về các đặc tính của chip Virtex-5 TX240T FPGA
Các giao diện cốt lõi của nền tảng NetFPGA-10G được dựa trên giao diện AXI4 phổ biến của ARM, sau đó được tinh chỉnh bởi Xilinx.
Có hai giao tiếp cơ bản:
Giao tiếp truyền tín hiệu điều khiển
Giao tiếp truyền dữ liệu
Định nghĩa giao thức truyền nhận dữ liệu với board NetFPGA
Để tối ưu hóa quá trình truyền dữ liệu giữa phần mềm ClamAV và phần cứng NetFPGA, chúng tôi đã thiết kế một giao thức truyền dữ liệu chuyên dụng nhằm tăng tốc độ hoạt động của ClamAV Giao thức này được xây dựng dựa trên những đặc tính riêng biệt của dữ liệu ClamAV, mang lại hiệu quả cao trong việc truyền nhận dữ liệu giữa hai thành phần quan trọng của hệ thống.
Dữ liệu trong các file cần quét được chia thành những khối dữ liệu nhỏ có kích thước khoảng 131KB trước khi chuyển vào các hàm quét cli_ac_scanbuff() và cli_bm_scanbuff().
44 Đối với driver truyền nhận qua DMA, một lần chỉ truyền tối đa 1.472 byte dữ liệu
Như vậy rõ ràng chúng ta phải chia nhỏ các block dữ liệu trong hàm quét thành nhiều gói nhỏ để truyền xuống board Đối với bộ quét, sẽ có những trường hợp không cần truy cập bộ nhớ ngoài, những trường hợp khác cần truy cập SRAM hay DRAM nên hai gói khác nhau có thể cho kết quả không theo thứ tự ban đầu Vì vậy việc xác định chính xác kết quả trả về thuộc gói nào và thuộc block nào là cần thiết Để làm được điều đó, hệ thống thêm thông tin định danh vào các gói dữ liệu truyền xuống và được cấu trúc dữ liệu như sau
Định dạng packet gửi đi từ PC xuống board NetFPGA10G
BUFFER_INFO: 24 bytes thông tin liên quan đến buffer ID nào đang quét
DATA: dữ liệu của buffer đang được quét
Định dạng packet trả về từ NetFPGA10G lên PC
Trong đó phần header của packet có định dạng như sau:
Header Sig Count Sig ID Sig Ofset Sig ID Sig Ofset
Hình 5.4: Gói packet đầu tiên
Hình 5.5: Các packet tiếp theo
0x01: Packet for cli_bm_scanbuff_wrapper
0x00: Packet for cli_ac_scanbuff_wrapper
Buffer ID (3 bytes): Phân biệt các buffer khác nhau
Packet info (1 byte) :chứa thông tin packet
[7:2]: 6 bits cho kích thước dữ liệu vì kích thước nhỏ nhất của 1 packet là 60 bytes
6'd0: Khi kích thước của packet lớn hơn hoặc bằng 60
6'd1-6'd60: Khi kích thước của packet nhỏ hơn 60 bytes
[1]: Set là 1 trong trường hợp packet đầu tiên
[0]: Set là 1 trong trường hợp packet cuối cùng
Sau khi quét hệ thống phần cứng, phần mềm sẽ trả về kết quả cho biết máy tính có bị nhiễm mã độc hay không, đồng thời cung cấp thông tin về loại và tên mã độc, cũng như các thống kê và tùy chọn kiểm soát khác.
Như đã nói trong phần 2.3, các gói dữ liệu truyền xuống có thể cho kết quả không theo thứ tự, và thời gian quét là không xác định trước Vì vậy khi trả kết quả về, hệ thống phần cứng đồng thời gửi kèm thông tin định danh gồm ID của khối dữ liệu ban đầu và thứ tự gói Nhờ vào những thông tin này mà phần mềm trên máy tính có thể biết được khối dữ liệu gửi xuống đã được quét xong hay chưa.
Giao tiếp truyền tín hiệu điều khiển
Giao tiếp truyền tín hiệu điều khiển được sử dụng phổ biến trong các project NetFPGA- 10G là giao tiếp AXI4 Lite protocol
AXI4 Lite protocol là giao tiếp đọc ghi đơn giản với 32 bit địa chỉ và 32 bit dữ liệu Nó được hiện thực dựa trên 5 FIFO: read data, read address, write data, write address and write response Trong thiết kế FPGA, AXI4 Lite có thể kết nối trực tiếp với pcore AXI4 lite interconnect trong đó tất cả các peripherals được hiểu như là một dãy các địa chỉ Cả
46 PCIe và microblaze đều là master của AXI4 lite interconnect và có thể đọc và ghi tất cả các peripherals
Bảng 5.1: Các đặc tính chip Virtex-5 TX240T
Các tính năng chính của giao tiếp AXI4-Lite:
Tất cả các giao dịch dưới dạng cố định
Các dữ liệu truy cập có cùng kích thước như chiều rộng của bus dữ liệu
Không hỗ trợ truy xuất độc quyền
Các tín hiệu của giao tiếp:
Bảng 5.2: Các tín hiệu của giao tiếp AXI4Lite
Channel Signal Status Description write address AWADDR required write address
AWVALID required write address valid
47 AWREADY required write address flow control write data WDATA required write data
WSTRB required write data byte strobe WVALID required write data valid WREADY required write data flow control write response BRESP required write response
BVALID required write response valid BREADY required write response flow control read address ARADDR required read address
ARVALID required read address valid ARREADY required read address flow control read data RDATA required read data
RRESP required read response RVALID required read data valid RREADY required read data flow control clock/reset ACLK required clock
ARESETN required low active reset
Các thông số của interface:
48 Bảng 5.3: Các thông số của AXI4Lite
Parameter name Description Default Type
C_BASEADDR AXI Base Address - integer
C_HIGHADDR AXI High Address - integer
C_AXI_ADDR_WIDTH AXI address bus width 32 integer C_AXI_DATA_WIDTH AXI data bus width 32 integer
C_AXI_PROTOCOL AXI flavour AXI4LITE string
Bảng 5.4: Cách đặt tên bus AXI4Lite
AXI Type Direction Signal name
49 Hình 5.6: Hoạt động đọc AXI4Lite
50 Hình 5.7: Hoạt động ghi AXI4Lite
Giao thức truyền dữ liệu
Giao tiếp truyền nhận dữ liệu được sử dụng trong các project NetFPGA-10G là giao tiếp Xilinx AXI4 Streaming Protocol v1.9 hay gọi tắt là AXI4 Stream [3]
AXI4 Stream được thiết kế để truyền dữ liệu một chiều từ Master đến Slave với mức giảm đáng kể các tín hiệu định tuyến Các tính năng chính của giao thức là:
Hỗ trợ đơn nhất hoặc nhiều dòng dữ liệu chia sẻ chung bộ dây
Hỗ trợ nhiều độ rộng của đường dữ liệu cùng kết nối
Lý tưởng để hiện thực trong FPGA
Các tín hiệu yêu cầu:
51 Bảng 5.5: Các tín hiệu AXI Stream
ARESETN Required Reset mức thấp
TVALID 1 Điều khiển dòng từ master đến slave
TDATA C_DAT_DATA_WIDTH Tín hiệu dữ liệu
TREADY 1 Điều khiển dòng từ slave đến master
TSTRB C_DAT_DATA_WIDTH/8 Tín hiệu byte enable
TLAST 1 Xác định kết thúc gói tin
TUSER fixed to 128 Chứa metadata trong clock đầu tiên theo tín hiệu dữ liệu
Bảng 5.6: Các thông số AXI Stream
Parameter name Description Details Type Default(s)
C_[MS]_AXIS_DATA_WIDTH bit width of
TDATA must be a multiple of 8 integer 8, 32, 64,
C_[MS]_AXIS_TUSER_WIDTH bit width of
Tín hiệu metadata được gửi qua tín hiệu TUSER Trong NetFPGA-10G tín hiệu TUSER được phân bố như sau:
- TUSER[15:0]: độ dài của packet (byte)
52 - TUSER[23:16]: source port: xác định gói tin được gửi từ port nào
- TUSER[31:24]: destination port: xác định gói tin được gửi tới port nào
- TUSER[47:32]: do người dùng tự định nghĩa
- TUSER[63:48]: do người dùng tự định nghĩa
- TUSER[79:64]: do người dùng tự định nghĩa
- TUSER[95:80]: do người dùng tự định nghĩa
- TUSER[111:96]: do người dùng tự định nghĩa
- TUSER[127:112]: do người dùng tự định nghĩa
Source port và destination port được mã hóa theo dạng one-hot (mỗi bit biểu diễn một port riêng biệt) Source port và destination port ở đây là 4 cổng mạng (MAC port) và 4 cổng PCIe trên board NetFPGA
Bit chẵn biểu diễn port MAC port Bit lẻ biểu diễn PCI queues.
Bảng 5.7: Mã hóa port trong TUSER
Bit 0 Bit 1 Bit 2 Bit 3 Bit 4 Bit 5 Bit 6 Bit 7 MAC0 CPU0 MAC1 CPU1 MAC2 CPU2 MAC3 CPU3 Trên board NetFPGA-10G, port 0 là port gần với bus PCIs nhất.
Hệ thống bộ nhớ
Board NetFPGA_10G được trang bị khá nhiều bộ nhớ tốc độ cao, bao gồm 27MB QDRII SRAM, và 288MB RLDRAM Trong đó:
QDRII (Quad Data Rate) SRAM là bộ nhớ SRAM có khả năng đọc ghi dữ liệu ở cả hai cạnh xung clock (lên và xuống), đồng thời mỗi phiên sẽ đọc ghi 4 cạnh tức 4 word liên
53 tiếp (quad) để giảm số lần đọc RAM, tăng throughput cho RAM Giản đồ xung cho việc đọc ghi RAM như Hình 5.8
Yêu cầu đọc/ghi RAM được đồng bộ với xung K tăng và giảm, trong khi dữ liệu ghi được đồng bộ với xung K tăng Việc đọc dữ liệu được đồng bộ với xung C tăng và giảm RAM QDRII sử dụng các đường dữ liệu đọc/ghi riêng biệt, cho phép thực hiện xen kẽ các lệnh đọc/ghi mà không phải đợi Độ rộng dữ liệu 36 bit cho phép đọc/ghi 144 bit dữ liệu cùng lúc, phù hợp để lưu trữ dữ liệu truy cập thường xuyên.
54 Hình 5.8: Giản đồ xung đọc ghi QDRII SRAM
Thông thường các loại DRAM có độ trễ (latency) rất lớn, khoảng trên dưới 10 chu kỳ xung clock RLDRAM (Reduced Latency) là một loại DRAM được thiết kế để thu giảm độ trễ tối đa RLDRAM trên board NetFPGA_10G có thể cho phép read latency nhỏ nhất 4 chu kỳ và write latency nhỏ nhất là 5 chu kỳ DRAM này cho phép đọc khi theo khối 2, 4, 8 word Giản đồ xong đọc ghi RLDRAM được thể hiện trong Hình 5.9
55 RLDRAM cũng sử dụng cả hai cạnh xung (lên xuống) nên mỗi xung clock sẽ có xung đảo đi kèm (từ đay sẽ chỉ gọi một xung) Các lệnh đọc/ghi và địa chỉ sẽ được đồng bộ với xung CK Dữ liệu ghi đồng bộ với xung DK và dữ liệu đọc đồng bộ với xung QK
Dộ rộng dữ liệu là 36 bit, như vậy tối đa một lần đọc ghi được 288 bit Đặc biệt, RLDRAM có thể đọc ghi xem kẽ các bank khác nhau mà không mất thời gian activate bank như DDRII thông thường, như vậy có thể dễ dàng đọc ghi liên tục một lượng lớn dữ liệu bất kỳ
Hình 5.9: Giản đồ xung đọc ghi RLDRAM
Hiện thực framework trên NetFPGA
Framework là cầu nối giữa phần mềm và hệ thống quét dữ liệu trên phần cứng Framework thực hiện nhiệm vụ nhận dữ liệu từ phần mềm qua PCIe, sau đó truyền dữ liệu này cho bộ quét virus Tiếp theo, framework thu thập kết quả quét và trả về phần mềm cũng thông qua giao tiếp PCIe Ngoài ra, framework còn cung cấp giao diện truy cập bộ nhớ cho bộ quét virus Hình 5.1 mô tả mô-đun HSVS (High speed virus scanner) nằm trong framework HSAV.
High speed virus scanner (HSVS)
Dis p at ch er Coll ec tor
Hình 5.10: Sơ đồ khối High speed virus scanner (HSVS)
5.6.1 Giao tiếp với PCIe DMA
Pcore DMA_PCIe được NetFPGA phát triển hỗ trợ giao tiếp giữa hệ thống phần cứng và máy tính thông qua hai giao tiếp AXI_Lite và AXI_Stream AXI_Lite cho phép đọc/ghi dữ liệu memory-mapped để debug, còn AXI_Stream hỗ trợ đọc/ghi dữ liệu tốc độ cao Nhờ vậy, người dùng có thể dễ dàng thực hiện đồng thời các chương trình truyền dữ liệu quét tốc độ cao và các chương trình để debug hệ thống.
Hình 5.11: Giản đồ xung giao tiếp dispatcher và scanner
Dispatcher là module có chức năng nhận các dữ liệu từ bus AXI_Stream của
DMA_PCIe, đệm lại dữ liệu và chuyển sang một giao tiếp đơn giản hơn cho bộ quét virus Bên dưới là các tín hiệu giao tiếp bắt tay với bộ quét virus
dpt_dvld_scn: Tín hiệu báo cho bộ scan biết có dữ liệu hợp lệ
dpt_cmd_scn[7:0]: Tín hiệu reserved cho tương lai, ý nghĩa là lệnh áp dụng cho dữ liệu tương ứng
dpt_id_scn[31:0]: Tín hiệu cho biết ID của dữ liệu, ID này tương ứng với khối dữ liệu cần quét (chẳng hạn như đoạn PE segment của file thực thi), được truyền từ phần mềm, do phần mềm sinh ra Trong trường hợp cả phần mềm và phần cứng đều làm việc tuần tự thì không cần tín hiệu này
dpt_seq_scn[15:0]: Thông thường, các khối dữ liệu đưa xuống PCIe sẽ phải cắt thành các gói nhỏ, dưới 2KB Tín hiệu dpt_seq_scn cho biết thứ tự gói nhỏ trong một gói lớn Trong trường hợp bộ quét làm việc tuần tự thì không cần tín hiệu này
dpt_data_scn[255:0]: Dữ liệu cần quét do phần mềm đưa xuống
dpt_bvld_scn[31:0]: Tín hiệu byte valid, cho biết các byte có nghĩa trong trường hợp các byte có nghĩa không chiếm hết đường dữ liệu (dữ liệu cuối)
dpt_end_scn: Tín hiệu cho biết đã kết thúc một phiên làm việc (truyền hết các gói trong một block dữ liệu), bộ quét có thể reset các thanh ghi tạm để quét dữ liệu mới
scn_rdy_dpt: Tín hiệu cho biết bộ quét virus sẵn sàng nhận dữ liệu
Collector có nhiệm vụ gần như ngược lại với dispatcher Nó nhận kết quả quét từ bộ quét virus rồi chuyển sang giao thức AXI_Stream để gửi ngược lại máy tính qua giao tiếp PCIe Giao tiếp giữa Collector và bộ quét virus được mô tả trong Hình 5.12
58 Hình 5.12: Giản đồ xung giao tiếp scanner và collector
scn_dvld_clt: Tín hiệu báo cho bộ collector biết có dữ liệu hợp lệ
scn_id_ clt [31:0]: Tín hiệu cho biết ID của dữ liệu được quét
scn_seq_ clt [15:0]: Thứ tự của gói
scn_data_ clt [255:0]: Kết quả trả về (có nhiễm virus hay không, nếu có thì virus nào)
scn_bvld_ clt [31:0]: Tín hiệu byte valid, cho biết các byte có nghĩa trong trường hợp các byte có nghĩa không chiếm hết đường dữ liệu (dữ liệu cuối)
clt_rdy_scn: Tín hiệu cho biết bộ collector sẵn sàng nhận dữ liệu
Hình 5.13: Giản đồ xung bộ điều khiển SRAM
Mặc dù các bộ nhớ QDRII SRAM và RLDRAM trên board NetFPGA_10G có throughput rất cao và nhanh, việc điều khiển các bộ nhớ này khá phức tạp vì sử dụng nhiều xung clock có độ lệch pha khác nhau Nhằm tạo thuận lợi cho bộ quét virus truy
Module điều khiển bộ nhớ của chúng tôi cung cấp hai giao diện liên kết đơn giản cho hai loại bộ nhớ Module này cũng có giao diện AXI_Lite để đọc nội dung RAM cho mục đích gỡ lỗi và tải cơ sở dữ liệu ClamAV vào RAM.
5.6.2.1 SRAM controller Đối với QDRII SRAM, sau khi reset, bộ nhớ cần một khoảng thời gian khoảng 20us trước khi có thể hoạt động Ngoài ra, để cho việc đọc ghi dữ liệu chính xác, hệ thống cần canh chỉnh các xung clock để có thể đọc ghi đúng thời điểm Việc canh chỉnh này được thực hiện đến khi nào các dữ liệu mẫu được ghi xuống và đọc lên đúng một số lần đủ lớn Sau khi canh chỉnh xong, hệ thống có thể nhận các yêu cầu đọc/ghi từ bộ quét Virus
Giao tiếp với bộ quét Virus được mô tả trong hình sau
scn_req_sram: Tín hiệu yêu cầu SRAM
scn_cmd_sram[3:0]: Lệnh yêu cầu SRAM, bit[3] xác định lệnh yêu cầu là đọc (1) hay ghi (0) Bit[2:0] xác định kích thước đọc/ghi là bao nhiêu word (1 word có độ rộng bằng độ rộng đường dữ liệu) Trong một lần yêu cầu, có thể đọc/ghi từ 1 đến 8 word.
scn_addr_sram[20:0]: Tín hiệu cho biết địa chỉ SRAM, bit[20:19] cho biết chip RAM nào trong 3 chip SRAM được chọn
scn_data_sram[143:0]: Dữ liệu đọc/ghi SRAM Vì SRAM dùng một byte 9- bit (1 bit parity) nên 16 byte sẽ có 144 bit Bộ quét Virus có thể dùng hay không dùng bit thứ 9 này
scn_bw_sram[15:0]: Tín hiệu byte write, cho phép ghi một số byte trong một word
sram_rdy_scn: Tín hiệu cho biết bộ memory_controller sẵn sàng nhận yêu cầu SRAM
sram_dvld_scn: Tín hiệu cho biết dữ liệu đọc hợp lệ
sram_data_scn[143:0]: Dữ liệu đọc SRAM
5.6.2.2 DRAM controller Đối với QDRII SRAM, sau khi reset, bộ nhớ cần một khoảng thời gian khoảng 20us trước khi có thể hoạt động Ngoài ra, để cho việc đọc ghi dữ liệu chính xác, hệ thống cần canh chỉnh các xung clock để có thể đọc ghi đúng thời điểm Việc canh chỉnh này được thực hiện đến khi nào các dữ liệu mẫu được ghi xuống và đọc lên đúng một số lần đủ lớn Sau khi canh chỉnh xong, hệ thống có thể nhận các yêu cầu đọc/ghi từ bộ quét Virus
Giao tiếp với bộ quét virus được mô tả trong hình sau
Hình 5.14: Giản đồ xung bộ điều khiển DRAM
scn_req_dram: Tín hiệu yêu cầu SRAM
scn_cmd_dram[3:0]: Lệnh yêu cầu SRAM, bit[3] cho biết yêu cầu là đọc (1) hay ghi (0) Bit[2:0] cho biết kích thước đọc/ghi là bao nhiêu word (1 word có độ rộng bằng độ rộng đường dữ liệu) Có thể đọc/ghi từ 2 0 đến 2 7 word trong một lần request
scn_addr_dram[20:0]: Tín hiệu cho biết địa chỉ SRAM, bit[20:19] cho biết chip RAM nào trong 3 chip SRAM được chọn
Dữ liệu SRAM để đọc/ghi được lưu trữ trong scn_data_dram[143:0] Do SRAM sử dụng các byte 9 bit (có 1 bit chẵn lẻ), nên 16 byte sẽ tương ứng với 144 bit Bộ quét virus có tùy chọn sử dụng hoặc không sử dụng bit thứ 9 này.
scn_bw_dram[15:0]: Tín hiệu byte write, cho phép ghi một số byte trong một word
dram_rdy_scn: Tín hiệu cho biết bộ memory_controller sẵn sàng nhận yêu cầu SRAM
dram_dvld_scn: Tín hiệu cho biết dữ liệu đọc hợp lệ
dram_data_scn[143:0]: Dữ liệu đọc SRAM
Xây dựng phần mềm quản lý dựa trên nền web
Hiện tại nhóm đã hoàn thành khung chương trình theo kiến trúc được đề xuất trong nội dung 2.6 NodeJS được cài đặt trên nền hệ điều hành Ubuntu 14.04 Các module phía máy chủ, máy khách được kết nối và điều chỉnh phù hợp
Admin Interface transfer events data
Bit stream and Memory Initial File
NodeJS là một nền tảng thực thi ứng dụng mạng/máy chủ mạnh mẽ
Đa nền tảng: Unix, Windows, OS X
Javascript cho cả máy chủ và máy khác
62 Hình 5.15: Hiển thị tóm tắt kết quả quét
Hoàn thiện khung chương trình đóng vai trò quan trọng trong việc định hình và phát triển các module còn lại của phần mềm quản lý Giao diện chính của phần mềm được thể hiện ở Hình 5.15 Việc ghép nối các tác vụ phía client với các dịch vụ phía server đã tương đối hoàn chỉnh Nhiệm vụ tiếp theo của nhóm là hoàn thiện các module trong Application Module và HSAV Core Library.
KẾT QUẢ THỰC NGHIỆM HỆ THỐNG
Thử nghiệm hoạt động chương trình ClamAV
6.1.1 Điều kiện thử nghiệm Để thử nghiệm ClamAV trong điều kiện hoạt động thông thường, chúng tôi chuẩn bị một máy tính với cấu hình như sau:
CPU core-i7, 4 core, 8 thread, 3.4GHz, cache L3 8 MB,
Ổ cứng SSD Corsair 128 GB, bus 1600 MHz
Phần mềm ClamAV được cài đặt trên máy tính này, tập chữ ký được cập nhật mới nhất và các cấu hình được điều chỉnh phù hợp với từng bài thử nghiệm Trong quá trình thử nghiệm, hệ thống ở trạng thái không tải, CPU ~ 2-3% Khi tiến hành quét, CPU khá ổn định ở 50%
6.1.2.1 Thử nghiệm với số lượng chữ ký tối đa
ClamAV được cấu hình với số lượng chữ ký tối đa là 2.423.843 chữ ký Sau đó lần lượt thử nghiệm với các kích thước file để quét khác nhau Kết quả cho thấy thời gian ClamAV tăng tuyến tính theo kích thước file quét, với tốc độ sấp xỉ 10MB/s
65 Hình 6.1: Thời gian quét ClamAV với số mẫu tối đa và kích thước file thay đổi
6.1.2.2 Thử nghiệm mẫu chữ ký và giải thuật quét Aho-Corasick (AC)
Giải thuật AC được sử dụng chủ yếu để phát hiện các mẫu chữ ký virus đa hình (có sử dụng wildcard) Trong phần thử nghiệm này, chúng tôi lần lượt thay đổi số lượng mẫu và kích thước file để đánh giá thời gian quét của ClamAV với giải thuật AC (Hình 6.2)
Sau đó thử nghiệm với số mẫu thay đổi trong phạm vi lớn với kích thước cố định là 100MB, (Hình 6.3)
66 Hình 6.2 Thời gian quét giải thuật AC với kích thước file và số mẫu khác nhau
Hình 6.3 Thời gian quét giải thuật AC với số mẫu thay đổi, kích thước file 100MB
6.1.2.3 Thử nghiệm mẫu chữ ký và giải thuật quét Boyer-Moore (BM)
Giải thuật BM được sử dụng để phát hiện các mẫu chữ ký tĩnh Trong phần thử nghiệm này, chúng tôi lần lượt thay đổi số lượng mẫu và kích thước file để đánh giá thời gian quét của ClamAV với giải thuật BM (Hình 6.4) Sau đó thử nghiệm với số mẫu thay đổi trong phạm lớn với kích thước cố định là 100MB (Hình 6.5)
67 Hình 6.4 Thời gian quét giải thuật BM với kích thước file và số mẫu khác nhau
Hình 6.5 Thời gian quét giải thuật BM với số mẫu thay đổi, kích thước file 100MB
6.1.3 Phân tích sơ đồ gọi hàm trong ClamAV scanm ana ger 99 93 % (0.00 %) 1× scan file 99 86 % (0.00 %) 1 × 99 86 %
1× cl_ load 0 07 % (0.00 %) 1× 0.07 % 1× cl _engin e_com p ile 0.00 % (0.00 %) 1 × 0.00 % 1× optg et 0.00 % (0.00 %) 53 × 0.00 % 36 × cl _engin e_set_ num 0.00 % (0.00 %) 5× 0.00 % 5× cl_en gine_ get_n um 0.00 % (0.00 %) 2 × 0.00 % 2× file list 0.00 % (0.00 %) 2× 0.00 % 2× cl _engin e_free 0.00 % (0.00 %) 1× 0.00 % 1× cl _engin e_new 0.00 % (0.00 %) 1× 0.00 % 1 × cl _init 0.00 % (0.00 %) 1× 0.00 % 1×
0.00 % 2× lo gg 0.00 % (0.00 %) 13 × 0.00 % 1× cl_s ca ndesc 99 86 % (0.00 %) 1× 99 86 % 1× mp rintf 0.00 % (0.00 %)
13 × 0 00 % 1× c li_load 0.07 % (0.00 %) 1× 0.07 % 1× c li_cache_ init 0.00 % (0.00 %) 1× 0 00 % 1× phish ing_in it 0 00 % (0.00 %) 1× 0.00 % 1× c li_lo ad ftm 0.00 % (0.00 %)
1× 0.00 % 1× c li_ac _bu ild trie 0.00 % (0.00 %)
10 × 0.00 % 10 × c li_bu ild_re gex_ list 0.00 % (0.00 %)
2× 0.00 % 2× c li_byte code _p repa re2 0.00 % (0.00 %)
1 × 0.00 % 1× m pool_ free 0 00 % (0.00 %) 1485 4× 0.00 % 12 × c li_ac _ fre e 0.00 % (0.00 %) 10 × 0 00 % 10 × c li_bm _fr ee
0.00 % (0.00 %) 2 × 0.00 % 2 × c li_byte code_do ne 0 00 % (0.00 %)
1× 0.00 % 1× c li_cache_de st roy 0.00 % (0.00 %)
0.00 % (0.00 %) 1× 0.00 % 1 × m pool_ destr oy 0.00 % (0.00 %) 1× 0.00 % 1× phis hin g_done 0.00 % (0.00 %) 1× 0.00 % 1× c li_ca lloc 0.00 % (0.00 %) 40 × 0.00 %
1× m pool_ ca lloc 0.00 % (0.00 %) 11299× 0.00 % 1× c li_dconf_ init 0 00 % (0.00 %) 1× 0.00 % 1× m poo l_cre ate 0.00 % (0.00 %) 1× 0.00 % 1× byte code_ init 0.00 % (0.00 %) 1× 0.00 % 1× c li_ra rload 0.00 % (0.00 %) 1× 0.00 % 1× lt_ init 0.00 % (0.00 %) 1× 0.00 % 1× m ain 99 93 % (0.00 %)
12 × open_ soc ket 0.00 % (0.00 %) 2 × 0.00 % 2 × actse tup 0.00 % (0.00 %) 1 × 0.00 % 1× check_ flevel 0.00 % (0.00 %) 1× 0.00 % 1× ge t_ve rsio n 0.00 % (0.00 %) 1× 0.00 % 1× op tfree 0.00 % (0.00 %) 1× 0.00 % 1× optp a rse 0.00 % (0.00 %)
0.00 % 12 × 0.00 % 3× cl_re tflevel 0.00 % (0.00 %) 31 × 0.00 % 1× op tadd 0.00 % (0.00 %) 88 × 0.00 %
88 × optg et_ i 0.00 % (0.00 %) 26 × 0.00 % 13 × my _geto pt_ lon g 0.00 % (0.00 %) 14 × 0.00 %
11 × c li_reg free 0 00 % (0.00 %) 12 × 0 00 % 11 × c li_re gexec 0.00 % (0.00 %) 11 × 0.00 %
11 × cl_s ca ndesc_ca llback 99 86 % (0.00 %) 1 × 99 86 % 1 × c li_m agic _scandesc 99 86 % (0.00 %) 1× 99 86 %
1 × c li_logg_ unsetu p 0.00 % (0.00 %) 1× 0.00 % 1× m agic _scandes c 99 86 % (0.00 %) 1× 99 86 % 1×
0 00 % (0.00 %) 1× 0.00 % 1× c li_ filety pe2 0.00 % (0.00 %) 1× 0.00 % 1× cache_a dd 0.00 % (0.00 %) 1× 0.00 % 1× c li_update lim its 0.00 % (0.00 %)
1 × 0.00 % 1 × c li_md 5_update 87 55 % (0.00 %) 260363 × 87 55 % 260363× fm ap_need _o ff_on ce 11 77 % (0.00 %)
2765 03× 11 08 % 2603 63× c li_md 5_ final 0.00 % (0.00 %) 1× 0.00 % 1× cache_lo okup_ha sh 0.00 % (0.00 %) 1 × 0.00 % 1× c li_md 5_in it 0 00 % (0.00 %) 1× 0.00 % 1× c li_fm ap_scand esc 1.23 % (0.00 %) 1× 1.23 % 1×
0.00 % 2× fm a p_re adn 0.00 % (0.00 %) 14 × 0.00 % 7× c li_raw addr 0.00 % (0.00 %) 2× 0.00 % 1× 0.00 % 1× c li_ filety pe 0 00 % (0.00 %) 1× 0.00 % 1× getke y 0.00 % (0.00 %) 2 × 0.00 % 1× cach eset_ add 0.00 % (0.00 %) 1 × 0.00 % 1× c li_check lim its 0.00 % (0.00 %) 1× 0.00 % 1× fm ap _check_em pty 0.00 % (0.00 %) 1× 0.00 % 1× body 87 55 % (87 07 %) 2603 64× 87 55 %
0 47 % 33 326385× fm ap_ag ing 10 07 % (10 07 %) 27650 3× 10 07 % 276503 × fm ap_ read page 1.56 % (1.56 %) 2765 03× 1.56 % 276503 × fm ap_w hich _page 0.07 % (0.07 %) 5530 06× 0.07 % 553006× 0.69 % 1612 5× ma tcher_ ru n 0 54 % (0.00 %) 32250 × 0.54 %
3 2250× ta rge tinfo 0 00 % (0.00 %) 1× 0.00 % 1× c li_ac _c aloff 0.00 % (0.00 %) 2× 0 00 % 2× c li_ac _fre edata 0.00 % (0.00 %) 2× 0.00 % 2× c li_ac _ in itdata 0.00 % (0.00 %)
2× 0.00 % 2× c li_ls ig_ eval 0.00 % (0.00 %) 2× 0.00 % 2× c li_ha sh set_d estroy 0.00 % (0.00 %) 1× 0.00 % 1×
0.00 % (0.00 %) 1× 0.00 % 1× c li_hashset_ in it_noa lloc
0.00 % 1× spec_ iter 0.07 % (0.07 %) 39 056× c li_ac _addsig 0.07 % (0.00 %) 3052×
0.00 % 74 × m pool_ m a lloc 0.00 % (0.00 %) 1485 4× 0.00 % 37 × 0.00 % 3089× m pool_ re a lloc 0.00 % (0.00 %) 6447× 0.00 % 37 × c li_ac _ad dpatt 0.00 % (0.00 %)
0.07 % 3 9056× spec_ ith_char 0.00 % (0.00 %) 8271 4× 0 00 % 39390 × get_ score 0.00 % (0.00 %) 2176 5× 0.00 % 21765× filter_ set_ atp os 0.00 % (0.00 %) 20764× 0.00 % 3648 × ad d_choic e 0.00 % (0.00 %) 4450× 0.00 % 4450× filte r_ set_ end 0.00 % (0.00 %) 3053 × 0.00 % 518× filte r_ add_s ta tic 0.00 % (0.00 %) 25 35× 0.00 % 2535 × spam 0 00 % (0.00 %) 42319 × 0.00 % 14854× a llocbase_fr om frag 0 00 % (0.00 %) 1485 4× 0.00 % 14 854×
0.00 % 13 7× fr om_ b its 0.00 % (0.00 %) 421 65× 0.00 % 14 717× to _b its 0.00 % (0.00 %) 29571× 0.00 % 1485 4× a lign _incre ase
0 00 % 1260 8× 0.00 % 12 731× 0.00 % 4866 × 0.00 % 6410× c li_isnum ber 0.00 % (0.00 %) 512× 0.00 % 23 × 0 00 % 3 052× c li_re alh ex2ui 0.00 % (0.00 %) 3052× 0.00 % 3052 ×
0.00 % 1 55× c li_hex2s tr_to 0 00 % (0.00 %) 155× 0.00 % 1 55× qcom pa re 0.00 % (0.00 %) 37 × 0.00 % 37 × s wapfu nc 0.00 % (0.00 %) 8× 0.00 % 8 ×
0.00 % 255 × x 86 _Con vert 0 07 % (0.07 %) c li_loa ddb 0 07 % (0.00 %)
0.00 % 10 × c li_ac _in it 0.00 % (0.00 %) 10 × 0.00 % 10 × c li_bm _init 0.00 % (0.00 %)
2389 04× is ins ets 0.00 % (0.00 %) 2921 × doe mit 0.00 % (0.00 %)
29 × sste p 0 00 % (0.00 %) 98 × ac _free_spe cial 0.00 % (0.00 %) 18 ×
92 × _ge topt_ in te rnal 0.00 % (0.00 %) 14 × 0.00 % 14 × 0.00 % 13 × cate go rize 0.00 % (0.00 %)
0.00 % 4172 × 0 00 % 29 21× c li_re gcom p_re al 0.00 % (0.00 %) 12 × 0.00 % 12 ×
12 × sm atc her 0.00 % (0.00 %) 11 × 0.00 % 11 × sfa st 0.00 % (0.00 %)
0.00 % 4× 0.00 % 20 × filte r_in it 0 00 % (0.00 %) 4× 0.00 % 4 × enla rge
0.00 % 1× 0.00 % 1× c li_byte code_done _jit 0.00 % (0.00 %) 1× 0.00 % 1×
0.00 % 1× 0.00 % 1× do main list_ done 0.00 % (0.00 %) 1× 0.00 % 1 × free_ reg ex 0.00 % (0.00 %) 1× 0.00 % 1 × wh ite list_ done 0.00 % (0.00 %) 1× 0.00 % 1× 0.00 % 1×
0.00 % (0.00 %) 1× 0.00 % 1× lt_d lfin d 0.00 % (0.00 %) 1× 0.00 % 1× c li_getc tx 0.00 % (0.00 %) 1× c li_getp agesize 0.00 % (0.00 %) 1 × c li_w arn m sg 0.00 % (0.00 %) 1× 0.00 %
Hình 6.6: Sơ đồ gọi hàm trong ClamAV
Sử dụng công cụ mã nguồn mở Linux gprof, chúng tôi tiến hành thực nghiệm phân tích hiệu suất các hàm chính của phần mềm trên Linux Kết quả cho thấy hai hàm cli_ac_scanbuff() và cli_bm_scanbuff() thực thi giải thuật Aho-Corasik và Boyer Moore có thời gian chạy lâu Do đó, việc tăng tốc các hàm này là yêu cầu quan trọng để cải thiện hiệu suất tổng thể của phần mềm.
6.1.4 Thực nghiệm quét các file EXE có tổng kích thước 3 GB
Dùng chương trình clamscan để quét 2385 file thực thi ELF có kích thước 2 KB đến 512 MB bằng các chữ kí mẫu tĩnh lẫn mẫu động trong main.cvd Tổng cộng có 2423843 chữ kí mẫu tĩnh trong file này sau khi extract
Bảng 6.1: Thống kê thời gian quét với các file exe 3 GB
% time cumulative seconds self seconds self calls name 22.5 83.10 83.10 32714 cli_ac_scanbuff 65.85 326.35 243.25 16357 cli_bm_scanbuff
Ta nhận thấy 2 hàm cli_ac_scanbuff() và cli_bm_scanbuff() chiếm tỉ lệ thời gian thực thi nhiều nhất (65.85% và 22.5%) Thời gian thực thi của 2 hàm chiếm tổng cộng 88 % trong toàn bộ chương trình
Trong clamscan thì khi quét file thì chương trình sẽ quét từng block, kích thước block tối đa khi hàm này gửi xuống cho cli_bm_scanbuff tối đa là 131072 bytes Nếu như một file có dung lượng lớn hơn 131072 bytes, thì clamscan sẽ chia thành nhiều block Khi bất kì một block nào bị phát hiện nhiễm virus thì quá trình quét sẽ thông báo file bị nhiễm và kết thúc quá trình quét virus file đó
Tổng hợp hệ thống so trùng chữ ký tĩnh trên NetFPGA platform
Chúng tôi hiện thực thử nghiệm ClamAV trên platform NetFPGA, đây cũng chính là platform chính nhắm tới của đề tài Platform NetFPGA 10G có một số thông số kỹ thuật nổi bật như sau: Chip FPGA Virtex 5 XC5VTX240T, 27 MBytes QDRII SRAM (3x72Mbit) và 288 MBytes RLDRAM-II
Máy so trùng mẫu chữ ký tĩnh được xây dựng trên chip FPGA, sử dụng 89.904 mẫu chữ ký tĩnh trong tập cơ sở dữ liệu mẫu của ClamAV Sau quá trình tiền xử lý, 83.781 mẫu được đưa vào cơ sở dữ liệu của hệ thống thử nghiệm Thiết bị chiếm khoảng 22.419 slices và hoạt động ổn định ở tần số 233 MHz Do bus dữ liệu chung của hệ thống là 8 bit, tốc độ quét của module có thể đạt 1,86 gigabit dữ liệu mỗi giây.
Hình 6.7 Đồ thị phân bổ về chiều dài mẫu Bảng 6.2: Kết quả tổng hợp về tài nguyên trên chip Virtex XC5VTX240T
Module Quantity Slices Block-RAMs
Thử nghiệm truyền dữ liệu PCIe
Việc truyền nhận dữ liệu với phần mềm thông qua giao thức PCIe giữa phần mềm máy tính và phần cứng trên bo mạch cần sự phối hợp chặt chẽ Đối với việc truyền nhận dữ liệu từ framework vào/ra bộ quét virus, hệ thống framework cung cấp giao tiếp bắt tay tốc độ cao, không có overhead nhằm đảm bảo có thể hỗ trợ lên đến 32 Gbps Do đó, tốc độ xử lý chỉ phụ thuộc vào khối quét virus.
Thử nghiệm đọc ghi bộ nhớ ngoài
Mặc dù RAM trên hệ thống cho phép tốc độ đỉnh tại bus dữ liệu là gần 23.9 Gbps đối với SRAM và 38.4 Gbps đối với DRAM, nhưng do việc điều khiển cần những máy trạng thái phức tạp nên tốc độ thực tế khi qua bộ điều khiển sẽ giảm đi đáng kể Đặc biệt, với DRAM, bộ nhớ này cần phải tốn thời gian refresh định kỳ nên sẽ làm giảm throughput đáng kể, và làm cho độ trễ các yêu cầu khó xác định trước Tuy nhiên, nhờ cho phép đọc/ghi theo khối lớn nên throughput tổng thể của hệ thống bộ nhớ khá cao, đáp ứng được yêu cầu bộ quét virus Hình sau thể hiện throughput của từng loại RAM với các burst khác nhau
72 Hình 6.8: Thông lượng giao tiếp với bộ nhớ Đối với SRAM, bộ quét virus cần đọc các dữ liệu tương đối nhỏ, nhưng delay cũng phải nhỏ (
