Xây Dựng Hàng Rào Bảo Vệ Cho Các Module Của Bạn

Khi thiết kế bất kỳ module nào, chúng ta đều phải coi việc ẩn giấu các chi tiết triển khai là nguyên tắc vàng. Hãy chỉ giữ lại những điểm truy cập cần thiết để giao tiếp với thế giới bên ngoài. Việc định nghĩa các điểm giao tiếp này chính là yếu tố then chốt, nhưng đáng tiếc nhiều lập trình viên lại thường sa lầy vào việc tối ưu hóa triển khai mà quên mất việc suy nghĩ sâu sắc về thiết kế giao diện.

Trong đa số trường hợp, chúng ta thường sao chép các hệ thống đã tồn tại để xây dựng giao diện. Điều này khiến chúng ta xem các định nghĩa interface là hiển nhiên đúng mà không cần bàn cãi. Tuy nhiên chính tư duy này lại đưa chúng ta vào tình trạng “mù chữ” khi đối mặt với các lĩnh vực mới - hoặc là tùy tiện triển khai, hoặc là không biết bắt đầu từ đâu.

Ngay cả những module đã hoàn thiện về mặt thiết kế cũng phải đối mặt với nguy cơ bị sử dụng sai. Người thiết kế module không thể yêu cầu người dùng hiểu tường tận cơ chế hoạt động bên trong. Hy vọng rằng tài liệu sẽ cảnh báo tất cả các sai lầm tiềm ẩn là điều không tưởng. Dù bạn có viết được bộ tài liệu hoàn hảo đến đâu, cũng không thể đảm bảo mọi người đều đọc kỹ. Và ngay cả khi họ đọc rồi, vẫn có thể xảy ra những sơ suất không mong muốn.

Các module càng chuyên biệt thì càng không thể dựa vào tài liệu hay hướng dẫn truyền miệng. Việc yêu cầu các lập trình viên đọc kỹ mã nguồn đồng nghiệp cũng không khả thi trong thực tế - cuộc đời lập trình vốn ngắn ngủi, thà viết lại còn hơn mất thời gian đọc hàng ngàn dòng code của người khác. Nếu hệ thống của bạn xảy ra lỗi, thay vì đổ lỗi cho người dùng, hãy tự kiểm điểm lại thiết kế của chính mình. Microsoft với hàng chục gigabyte tài liệu MSDN cũng chỉ là nỗ lực bất đắc dĩ để đối phó với thực tế này.

Ví dụ điển hình: Module quản lý bộ nhớ trong C

Hãy cùng phân tích một module quen thuộc với mọi lập trình viên C: hệ thống quản lý bộ nhớ. Bộ API tiêu chuẩn gồm 3 hàm:

1
2
3

malloc
free
realloc

Đa số lập trình viên đều xem đây là những hàm “tự nhiên đúng”. Chỉ khi tiếp xúc với các cơ chế quản lý bộ nhớ hiện đại như garbage collection, họ mới nhận ra thế giới còn có những cách tiếp cận hoàn toàn khác biệt. Ngay cả khi được chuẩn hóa trong thư viện C, các trình quản lý bộ nhớ khác nhau vẫn có thể triển khai khác nhau. Ví dụ Windows API cung cấp bộ hàm phức tạp hơn như HeapAlloc.

Khi phân tích kỹ nhóm hàm malloc, chúng ta nhận ra rằng chúng không hoàn toàn đáng tin cậy. Một lập trình viên C có kinh nghiệm sẽ nhanh chóng chỉ ra những “bẫy” như:

• Gọi free hai lần trên cùng một con trỏ đã giải phóng
• Làm mất địa chỉ vùng nhớ sau khi cấp phát (memory leak)
• Sử dụng dữ liệu chưa được khởi tạo trong vùng nhớ mới cấp
• Truy cập vào vùng nhớ đã bị giải phóng (dangling pointer)
• Ghi vượt quá ranh giới vùng nhớ đã cấp (buffer overflow)
• Không kiểm tra kết quả trả về khi cấp phát thất bại
• Sử dụng địa chỉ cũ sau khi realloc thay đổi vị trí vùng nhớ

Giải pháp: Xây dựng cơ chế tự kiểm soát

Thay vì liên tục nhắc nhở lập trình viên tránh lỗi, cách tiếp cận thông minh hơn là xây dựng cơ chế phát hiện lỗi ngay trong chính module. Điều này giúp phát hiện và ngăn chặn sai lầm ngay từ đầu. Trong điều kiện cho phép, chúng ta nên cẩn trọng hơn trong việc định nghĩa interface, thậm chí sẵn sàng thiết kế lại khi phát hiện lỗi trong thiết kế ban đầu.

Trong nhiều trường hợp, các module quản lý bộ nhớ do bên thứ ba cung cấp, khiến việc nghiên cứu và sửa đổi mã nguồn trở nên khó khăn. Ngay cả khi tự triển khai, module này cũng cần đảm bảo tính độc lập cao để tối ưu hiệu năng trong phiên bản phát hành chính thức.

Kỹ thuật “đóng vỏ” (Wrapper) API

Với hàm malloc

Theo chuẩn ISO, khi thất bại malloc trả về NULL. Cho phép malloc(0) trả về NULL hoặc một địa chỉ hợp lệ là hành vi phụ thuộc vào từng nền tảng. Trong các dự án của tôi, tôi thường áp dụng các biện pháp tăng cường:

• Loại bỏ các hành vi không được định nghĩa rõ ràng bằng cách sử dụng assert
• Với các hệ thống có thể dự đoán tổng lượng bộ nhớ sử dụng, tôi yêu cầu malloc phải trả về NULL nếu phát hiện thất bại bất thường
• Thống nhất kết quả của malloc(0) và malloc(1) để tương thích với hành vi của operator new trong C++
• Ghi đè dữ liệu vùng nhớ đã cấp bằng giá trị 0xCC (tương ứng với lệnh int3 trong x86) để phát hiện việc sử dụng vùng nhớ chưa được khởi tạo

Với hàm free

• Tuân thủ chuẩn ISO cho phép free(NULL)
• Ghi đè dữ liệu vùng nhớ đã giải phóng để phát hiện lỗi dangling pointer
• Sử dụng cơ chế “cookie” để phát hiện các hành vi sai như giải phóng nhiều lần hay truy cập ngoài ranh giới

Với hàm realloc

• Sử dụng assert để đảm bảo mở rộng bộ nhớ thành công
• Xây dựng hàm reallocf tương tự freeBSD để tránh memory leak khi mở rộng thất bại
• Sử dụng kỹ thuật “thẻ nhận dạng” (guard bytes) để phát hiện lỗi viết tràn bộ nhớ

Phát hiện memory leak

Vấn đề memory leak cần được xử lý theo từng loại đối tượng:

1. Vùng nhớ tồn tại suốt vòng đời chương trình: Thêm API đặc biệt để phân bổ loại vùng nhớ này, gắn thẻ nhận dạng riêng để phát hiện việc cố ý giải phóng

2. Vùng nhớ động: Sử dụng danh sách liên kết hai chiều để theo dõi toàn bộ vùng nhớ đang sử dụng. Tự động kiểm tra danh sách này khi chương trình kết thúc

Kỹ thuật “đóng vỏ” cho thư viện C

Các thư viện C hiện đại như GNU C cung cấp cơ chế hook để tích hợp công cụ debug. Trong trường hợp không hỗ trợ, có thể sử dụng các phương pháp sau:

• Thay thế qua macro:

1

#define malloc(sz) my_malloc(sz, __FILE__, __LINE__)

• Tạo hàm proxy trả về con trỏ hàm:

1
2
3
4

typedef void* (*malloc_f)(size_t sz);
malloc_f malloc_proxy() {
    return my_malloc;
}

• Sử dụng biến toàn cục để ghi nhận vị trí mã nguồn:

1
2
3

#define malloc malloc_proxy(__FILE__, __LINE__)
malloc_f malloc_proxy(const char *filename, int line) {
    g_filename = filename;