System call — cách chương trình xin kernel làm việc

TL;DR: Một system call là cách duy nhất hợp pháp để chương trình (user mode) nhờ kernel (kernel mode) làm việc đặc quyền: đọc file, gửi mạng, cấp bộ nhớ. Khi bạn gọi write(), hàm thư viện glibc đặt số hiệu syscall và đối số vào các thanh ghi rồi chạy lệnh syscall. Lệnh này chuyển CPU sang kernel mode, nhảy tới điểm vào cố định, kernel tra bảng syscall để tìm handler, chạy nó, đặt kết quả trở lại rax, rồi trả về user mode. Toàn bộ vòng này là mode switch (đổi đặc quyền trong cùng tiến trình), khác hẳn context switch; chi phí cỡ hàng trăm nano-giây — rẻ so với I/O nhưng đắt nếu gọi hàng triệu lần.

Ở bài trước, bạn thấy user code không được đụng phần cứng: thử chạy lệnh đặc quyền là bị SIGSEGV. Nhưng chương trình vẫn đọc file, in màn hình, gửi request mạng mỗi ngày. Vậy nó làm bằng cách nào, nếu không được tự tay đụng ổ đĩa hay card mạng?

Câu trả lời là system call — cây cầu được kiểm soát chặt bắc qua ranh giới hai mode. Bài này trace một write() từ dòng C của bạn, qua hàm thư viện, xuống lệnh syscall, vào kernel, chạy handler, rồi quay ngược về — từng chặng một, ở mức thanh ghi. Hiểu con đường này, bạn đọc được output strace và biết vì sao "gọi nhiều syscall nhỏ" là một anti-pattern hiệu năng.

1. Analogy — gọi tổng đài dịch vụ công

Bạn muốn cấp lại căn cước. Bạn không tự đi vào kho dữ liệu quốc gia sửa hồ sơ — bạn gọi tổng đài dịch vụ công, đọc đúng mã thủ tục ("thủ tục 1234"), cung cấp thông tin cần thiết, rồi chờ. Nhân viên có quyền (kernel) vào kho làm giúp, xong báo kết quả ra cho bạn. Bạn không bao giờ trực tiếp chạm vào kho.

System call hoạt động y hệt: chương trình của bạn "gọi tổng đài" bằng lệnh syscall, đưa số hiệu (mã thủ tục) và đối số (thông tin), rồi kernel — bên có đặc quyền — làm việc đó và trả kết quả.

2. Từ printf tới syscall — ai thật sự đọc đĩa?

Khi bạn viết printf("hi") trong C, chuỗi lệnh thật sự dài hơn bạn tưởng. printf là hàm của thư viện chuẩn C (glibc): nó định dạng chuỗi, gộp vào buffer, rồi cuối cùng gọi write() — cũng là hàm glibc. Bản thân write() vẫn chưa đụng đĩa; nó chỉ là lớp bọc mỏng (wrapper) phát ra một system call.

Thử đoán trước khi đọc giải thích: trong đoạn dưới, ai thật sự đẩy 3 byte ra màn hình — hàm write bạn gọi, wrapper glibc, hay kernel?

// vd_write.c -- goi write() truc tiep, khong qua printf
#include <unistd.h>

int main(void) {
    // write(fd, buf, count): fd=1 la stdout
    write(1, "hi\n", 3);
    return 0;
}

Ba tầng, tách bạch:

• Code của bạn (user): gọi write(1, "hi\n", 3).
• Wrapper glibc (vẫn user): đặt số hiệu syscall của write vào rax, các đối số vào thanh ghi, chạy lệnh syscall.
• Kernel (kernel mode): thực sự đẩy 3 byte ra file descriptor 1.

Điểm cần khắc: không có tầng nào ở user mode chạm phần cứng. Wrapper glibc chỉ chuẩn bị thanh ghi rồi "gọi tổng đài". Đây là lý do bạn có thể viết chương trình đọc/ghi file mà chưa từng học một lệnh I/O phần cứng nào.

3. Cơ chế bên dưới — đường đi một system call

Đây là phần cốt lõi. Ta trace write(1, "hi\n", 3) ở mức thanh ghi, trên x86-64.

3.1 Phía user chuẩn bị

Wrapper glibc nạp các thanh ghi theo quy ước gọi syscall của Linux x86-64:

Các đối số tiếp theo (nếu có) đi vào r10, r8, r9. Chuẩn bị xong, wrapper chạy đúng một lệnh:

syscall

3.2 Phần cứng chuyển mode

Lệnh syscall làm mấy việc nguyên tử: chuyển mode bit sang kernel mode, lưu địa chỉ trở về (vào rcx) và cờ trạng thái (vào r11), rồi nhảy tới một địa chỉ cố định mà kernel đã đăng ký sẵn lúc khởi động (điểm vào syscall). User code không tự chọn được nhảy vào đâu trong kernel — nó chỉ có một cửa vào duy nhất. Đó là điều khiến system call an toàn.

3.3 Kernel tra bảng và chạy handler

Vào kernel rồi, code điểm vào đọc rax để biết đây là syscall số mấy, rồi dùng nó làm chỉ số tra vào bảng syscall (sys_call_table) — một mảng con trỏ hàm, mỗi ô trỏ tới handler tương ứng. Số 1 → sys_write. Kernel gọi sys_write, hàm này kiểm tra đối số (fd hợp lệ? buffer nằm trong vùng nhớ user hợp lệ?) rồi thực sự đẩy byte ra.

3.4 Trả về user

sys_write trả về số byte đã ghi (ở đây là 3). Kernel đặt giá trị này vào rax, chạy lệnh sysret để chuyển mode bit về user mode và nhảy về đúng chỗ đang dở (địa chỉ đã lưu trong rcx). Wrapper glibc đọc rax: nếu là số không âm, đó là kết quả; nếu là giá trị âm nhỏ (khoảng từ -4095 tới -1), đó là mã lỗi -errno — wrapper đặt errno tương ứng và trả -1 cho bạn.

sequenceDiagram
    participant U as User code (ban)
    participant G as glibc wrapper
    participant C as CPU (phan cung)
    participant K as Kernel
    U->>G: write(1, "hi", 3)
    G->>G: rax=1, rdi=1, rsi=buf, rdx=3
    G->>C: lenh "syscall"
    C->>K: doi sang kernel mode, nhay diem vao co dinh
    K->>K: tra sys_call_table[1] = sys_write
    K->>K: chay sys_write, ghi 3 byte
    K->>C: dat rax=3, lenh "sysret"
    C->>G: doi ve user mode, tra ve cho dang do
    G->>U: return 3

4. Mode switch khác context switch

Hai khái niệm này rất dễ lẫn, nhưng phân biệt được là bạn hiểu quá nửa module.

• Mode switch (đổi chế độ): CPU chuyển giữa user mode và kernel mode trong cùng một tiến trình. Không đổi không gian địa chỉ, không nạp lại page table, không đá tiến trình ra khỏi CPU. Chỉ đổi mode bit + lưu vài thanh ghi. Đây là những gì xảy ra ở mọi system call.
• Context switch (đổi bối cảnh): kernel thay hẳn tiến trình đang chạy bằng tiến trình khác. Phải lưu toàn bộ thanh ghi của tiến trình cũ, nạp thanh ghi tiến trình mới, và đổi page table (nạp cr3 mới) — kéo theo xả TLB (Translation Lookaside Buffer — cache dịch địa chỉ ảo sang vật lý, học ở Course 2 — MMU & TLB), làm cache "nguội". Đắt hơn mode switch nhiều lần.

Một system call luôn là mode switch. Nó có thể dẫn tới context switch (ví dụ read() phải chờ đĩa → kernel cho tiến trình khác chạy trong lúc chờ), nhưng bản thân việc gọi syscall không đồng nghĩa với đổi tiến trình. Nhầm hai cái này là nhầm "hỏi tổng đài một câu" với "nghỉ việc để người khác vào chỗ".

5. Chi phí của một system call

Một mode switch không miễn phí: một system call "rỗng" (ví dụ getpid()) mất cỡ hàng chục tới hàng trăm nano-giây (cao hơn khi bật mitigation như KPTI) — gồm lệnh syscall/sysret, lưu/khôi phục thanh ghi, và xáo trộn cache/pipeline. Hệ quả thực tế: gọi ít syscall lớn nhanh hơn nhiều syscall nhỏ — đọc 1 MB bằng một read(fd, buf, 1MB) rẻ hơn hẳn gọi read một triệu lần mỗi lần 1 byte, vì mỗi lần gọi phải trả lại chi phí vượt biên. Đây là lý do các thư viện I/O dùng buffer.

6. Pitfall — những hiểu nhầm thường gặp

❌ Nhầm 1 — "Gọi write() là một lời gọi hàm bình thường."

✅ Không. Một lời gọi hàm bình thường (myFunc()) chỉ nhảy trong cùng user mode. write() cuối cùng chạy lệnh syscall, cố ý gây mode switch sang kernel — đắt hơn lời gọi hàm thường hàng trăm lần (hơn nữa khi bật mitigation như KPTI). Đó là lý do vòng lặp gọi syscall triệu lần thì chậm dù mỗi lần "chỉ ghi 1 byte".

❌ Nhầm 2 — "System call luôn kéo theo đổi tiến trình."

✅ Không. System call luôn là mode switch nhưng không nhất thiết là context switch. getpid() chẳng hạn: vào kernel, đọc PID, trả về ngay — cùng tiến trình từ đầu tới cuối. Chỉ khi syscall phải chờ (I/O, lock) kernel mới có thể chuyển sang tiến trình khác.

❌ Nhầm 3 — "Giá trị trả về âm nghĩa là bug."

✅ Không. Kernel mã hoá lỗi bằng cách trả -errno (giá trị âm nhỏ). Ví dụ open() một file không tồn tại: kernel trả -2 (-ENOENT). Wrapper glibc dịch thành errno = ENOENT và trả -1. Đây là hợp đồng bình thường, không phải lỗi hệ thống — bạn phải kiểm tra giá trị trả về và errno.

7. 📚 Deep Dive

8. Liên hệ các bài khác

• Bài 01 — Kernel mode vs user mode: ranh giới mà system call bắc cầu qua; lệnh syscall chính là cách hợp pháp để chuyển mode mà bài trước nói tới.
• Bài 03 — Interrupt, trap & exception: system call là một dạng trap (chủ động vào kernel); bài này đặt nó cạnh interrupt và exception.
• Bài 04 — Đọc syscall bằng strace: công cụ để nhìn thấy từng syscall bạn vừa học, với đối số và giá trị trả về thật.
• Course 1 — Spectre & Meltdown: vì sao mitigation KPTI làm mọi system call đắt hơn.

9. Tóm tắt

• System call là giao diện duy nhất để user code nhờ kernel làm việc đặc quyền; hàm glibc (read, write) chỉ là wrapper mỏng.
• Cơ chế x86-64: số hiệu vào rax, đối số vào rdi/rsi/rdx/r10/r8/r9, chạy lệnh syscall → CPU sang kernel mode, nhảy tới điểm vào cố định.
• Kernel đọc rax, tra bảng syscall để tìm handler (sys_write...), chạy, đặt kết quả vào rax, rồi sysret về user.
• Giá trị trả về âm nhỏ mã hoá lỗi (-errno); glibc dịch thành errno + trả -1.
• Một system call luôn là mode switch (rẻ, cùng tiến trình), khác context switch (đắt, đổi tiến trình + đổi page table + xả TLB).
• Chi phí syscall cỡ hàng trăm ns, cao hơn do KPTI; nên gom thành ít syscall lớn (buffer) thay vì nhiều syscall nhỏ. vDSO tránh mode switch cho vài truy vấn hay gặp.

10. Tự kiểm tra

Bài tiếp theo: Interrupt, trap & exception — ba lối vào kernel