VI: Linux Kernel đang chuẩn bị loại bỏ lớp crypto_rng trong Crypto API. Đây không phải là thay đổi làm người dùng máy tính để bàn hay máy chủ thấy khác ngay lập tức, nhưng lại là một tín hiệu quan trọng với lập trình viên kernel, đội vận hành hệ thống Linux, nhà phát triển driver và các nhóm đang duy trì module phụ thuộc vào API cũ.
Điều gì đang xảy ra?
Theo bài viết gốc từ Linux Journal, cộng đồng phát triển Linux Kernel đang tiến tới kế hoạch loại bỏ lớp API crypto_rng, một phần lâu đời trong hệ thống mật mã của kernel. Lớp này từng cung cấp cách gọi sinh dữ liệu ngẫu nhiên thông qua Crypto API. Tuy nhiên, theo thời gian, bộ sinh số ngẫu nhiên chính của kernel đã trưởng thành hơn nhiều, nên việc đi vòng qua lớp crypto trở nên dư thừa trong phần lớn tình huống.
Các giao diện hiện đại như get_random_bytes(), get_random_u32() và get_random_u64() đã được dùng rộng rãi trong kernel. Khi một lớp trung gian không còn đem lại lợi ích rõ ràng, nó làm tăng chi phí bảo trì, tăng số đường code cần kiểm thử và khiến người mới đóng góp khó hiểu kiến trúc hơn. Vì vậy, hướng đi mới là chuyển những phần còn dùng crypto_rng sang API sinh ngẫu nhiên trực tiếp, sau đó loại bỏ lớp cũ khi không còn phụ thuộc.
Vì sao việc này quan trọng với quản trị viên?
Với người dùng cuối, các đường như /dev/urandom, getrandom(), OpenSSL hoặc GnuTLS không thay đổi vì chúng hoạt động ở tầng khác. Website, dịch vụ, ứng dụng người dùng thông thường gần như không cần hành động. Tuy nhiên, quản trị viên vẫn nên hiểu bối cảnh vì thay đổi này có thể ảnh hưởng gián tiếp đến môi trường dùng kernel tùy biến, driver nội bộ, module bảo mật tự viết, appliance Linux, bản build embedded hoặc các bản phân phối đang backport patch sâu.
Nếu doanh nghiệp chỉ dùng kernel chuẩn từ Ubuntu, Debian, RHEL, AlmaLinux, Rocky Linux, Proxmox hoặc nhà cung cấp cloud, việc phù hợp nhất là theo dõi advisory và cập nhật bình thường. Nếu có module tự biên dịch, cần kiểm tra mã nguồn xem còn gọi API crypto RNG cũ hay không. Đây là loại thay đổi không gây sự cố ngay hôm nay, nhưng có thể trở thành lỗi build trong một chu kỳ kernel tương lai.
Góc nhìn kỹ thuật
crypto_rng thuộc Crypto API, còn bộ sinh số ngẫu nhiên chính của kernel là hạ tầng chuyên trách cho nhu cầu random trong kernel. Khi cả hai cùng tồn tại, nhà phát triển có thêm lựa chọn nhưng cũng có thêm sự không nhất quán. Việc giảm bớt lớp trừu tượng giúp việc audit bảo mật tập trung hơn: thay vì duy trì nhiều đường gọi tạo entropy và random output, kernel có thể đẩy contributor về một nhóm API được xem là chuẩn.
Điểm quan trọng: loại bỏ crypto_rng không có nghĩa Linux yếu hơn về mật mã. Ngược lại, việc bỏ code dư thừa thường làm hệ thống dễ kiểm tra hơn. Ít API cũ hơn đồng nghĩa ít tài liệu cũ, ít hành vi đặc biệt, ít test case lặp lại và ít khả năng một driver tiếp tục bám vào interface không còn được khuyến nghị.
Checklist thực tế
- Kiểm tra xem hệ thống có dùng kernel tùy biến, DKMS module, driver vendor hoặc module bảo mật tự viết hay không.
- Tìm trong mã nguồn các tham chiếu đến
crypto_rnghoặc API RNG cũ thuộc Crypto API. - Nếu có, lập kế hoạch chuyển sang
get_random_bytes(),get_random_u32()hoặcget_random_u64()tùy kiểu dữ liệu cần lấy. - Theo dõi mailing list, changelog kernel và ghi chú phát hành của bản phân phối đang dùng.
- Không vá nóng production chỉ vì tin này; hãy thử trên môi trường staging hoặc máy test trước.
- Ghi lại module nào phụ thuộc kernel internal API để tránh bị bất ngờ khi nâng kernel trong tương lai.
Kết luận tiếng Việt
Đây là một thay đổi “sau hậu trường”, nhưng rất đúng tinh thần phát triển Linux: dọn nợ kỹ thuật, giảm code dư, gom nhà phát triển về API hiện đại và làm kernel dễ bảo trì hơn. Với người dùng phổ thông, không cần lo lắng. Với đội IT có kernel tùy biến hoặc driver riêng, đây là lúc rà soát nhẹ, không phải lúc hoảng.
EN: The Linux Kernel is preparing to phase out the crypto_rng layer from the Crypto API. This is not a change that ordinary desktop or server users will notice immediately, but it matters for kernel developers, Linux operations teams, driver maintainers, and organizations that carry custom kernel modules.
What is changing?
According to the original Linux Journal report, Linux kernel developers are moving toward removing the long-standing crypto_rng API layer. Historically, this layer allowed kernel components to request random data through the Crypto API. Over time, the kernel’s primary random number generation subsystem became stronger, clearer, and more widely adopted, making the extra abstraction less useful.
Modern kernel code already has direct interfaces such as get_random_bytes(), get_random_u32(), and get_random_u64(). When an older abstraction no longer provides a meaningful benefit, it adds maintenance cost: more code paths, more documentation, more tests, and more ways for contributors to choose the wrong interface. The practical plan is to convert remaining users away from crypto_rng, then remove the layer once it is no longer needed.
Operational impact
User-space applications should not be affected. Interfaces such as /dev/urandom, getrandom(), OpenSSL, and GnuTLS are separate from this internal kernel cleanup. For standard servers running vendor kernels from Ubuntu, Debian, RHEL-compatible distributions, Proxmox, or cloud providers, the right response is normal patch management and release-note tracking.
The teams that should pay attention are the ones maintaining custom kernels, out-of-tree drivers, DKMS packages, embedded Linux images, security appliances, or vendor modules. If those components still call the old crypto RNG interface, they may need source changes before future kernel versions compile cleanly.
Security meaning
This removal should not be read as a reduction in Linux cryptographic capability. The opposite interpretation is more accurate: consolidating random number generation around the recommended kernel interfaces can make the codebase easier to audit and maintain. Fewer legacy paths mean fewer special cases and a smaller long-term support burden.
Practical checklist
- Inventory custom kernel modules, DKMS packages, vendor drivers, and embedded builds.
- Search source code for
crypto_rngreferences and older Crypto API RNG usage. - Map each use case to direct kernel random APIs such as
get_random_bytes(),get_random_u32(), orget_random_u64(). - Test changes on staging kernels before production rollout.
- Track upstream kernel mailing list notes and distribution release notes.
- Document which systems depend on internal kernel APIs so future upgrades are predictable.
Conclusion
The planned removal of crypto_rng is a behind-the-scenes cleanup, but a useful one. It reduces technical debt, simplifies the Crypto API, and nudges developers toward modern random number generation interfaces. Regular users do not need to act. Administrators with custom kernel code should review dependencies now so a future kernel upgrade does not become an emergency.
Source reference
Source: Linux Journal. ITCuli.NET rewrote this into Vietnamese and English operational guidance.