Kees nấu ăn Tôi tạo một bài blog trong đó đã làm dấy lên lo ngại về quy trình sửa lỗi đang diễn ra trong các nhánh ổn định của nhân Linux và đó là đề cập rằng mỗi tuần, khoảng một trăm lần sửa chữa được bao gồm trên các nhánh ổn định, quá nhiều và đòi hỏi nhiều nỗ lực để duy trì các sản phẩm dựa trên nhân Linux.
Theo Kees, quá trình xử lý lỗi hạt nhân bị bỏ qua và hạt nhân thiếu ít nhất 100 nhà phát triển bổ sung để làm việc một cách đồng bộ trong lĩnh vực này. Ngoài việc đề cập rằng các nhà phát triển hạt nhân lớn thường xuyên sửa lỗi, nhưng không có gì đảm bảo rằng các bản sửa lỗi này sẽ chuyển sang các biến thể hạt nhân của bên thứ ba.
Khi làm như vậy, ông đề cập rằng người dùng các sản phẩm dựa trên nhân Linux khác nhau cũng không có cách nào để kiểm soát lỗi nào được sửa và nhân nào được sử dụng trên thiết bị của họ. Cuối cùng, các nhà cung cấp chịu trách nhiệm về bảo mật cho sản phẩm của họ, nhưng phải đối mặt với tỷ lệ bản vá lỗi rất cao trên các nhánh hạt nhân ổn định, họ phải đối mặt với sự lựa chọn di chuyển tất cả các bản vá, di chuyển có chọn lọc những bản quan trọng nhất hoặc bỏ qua tất cả các bản vá. .
Các nhà phát triển nhân thượng nguồn có thể sửa lỗi, nhưng họ không kiểm soát được những gì mà nhà cung cấp hạ nguồn chọn để đưa vào sản phẩm của họ. Người dùng cuối có thể chọn sản phẩm của họ, nhưng nhìn chung họ không kiểm soát được lỗi nào được sửa hoặc hạt nhân nào được sử dụng (bản thân nó là một vấn đề). Cuối cùng, các nhà cung cấp có trách nhiệm giữ cho lõi sản phẩm của họ an toàn.
Kees nấu ăn gợi ý rằng giải pháp tối ưu sẽ là chỉ chuyển các bản sửa lỗi và lỗ hổng bảo mật quan trọng nhất, nhưng vấn đề chính là phải tách những lỗi này ra khỏi quy trình chung, vì hầu hết các vấn đề nổi lên là hệ quả của việc sử dụng ngôn ngữ C, vốn đòi hỏi phải cẩn thận khi làm việc với bộ nhớ và con trỏ.
Để làm cho vấn đề tồi tệ hơn, nhiều bản sửa lỗi lỗ hổng tiềm ẩn không được gắn thẻ với số nhận dạng CVE hoặc không nhận được số nhận dạng CVE một thời gian sau khi bản vá được phát hành.
Trong một môi trường như vậy, rất khó cho các nhà sản xuất tách các bản sửa lỗi nhỏ khỏi các vấn đề bảo mật lớn. Theo thống kê, hơn 40% lỗ hổng bảo mật được loại bỏ trước khi chuyển nhượng CVE và trung bình thời gian trì hoãn giữa bản phát hành sửa chữa và chuyển nhượng CVE là ba tháng (nghĩa là ngay từ đầu, người dùng coi giải pháp là một sai lầm phổ biến,
Kết quả là không có một nhánh riêng với các bản sửa lỗi cho các lỗ hổng và không nhận được thông tin về kết nối với bảo mật của vấn đề này hoặc vấn đề đó, các nhà sản xuất sản phẩm dựa trên nhân Linux phải liên tục chuyển tất cả các bản sửa lỗi của các nhánh mới ổn định. Nhưng công việc này đòi hỏi nhiều lao động và vấp phải sự phản đối từ các công ty do lo ngại những thay đổi thoái trào có thể làm gián đoạn hoạt động bình thường của sản phẩm.
phím nấu ăn tin rằng giải pháp duy nhất để giữ hạt nhân an toàn với chi phí hợp lý trong dài hạn là chuyển các kỹ sư vá lỗi để xây dựng hạt nhân điên rồtôi làm việc cùng nhau một cách phối hợp để duy trì các bản vá và lỗ hổng trong nhân ngược dòng. Như hiện tại, nhiều nhà cung cấp không sử dụng phiên bản hạt nhân mới nhất trong sản phẩm của họ và tự sửa lỗi backport, có nghĩa là các kỹ sư từ các công ty khác nhau sẽ sao chép công việc của nhau, giải quyết cùng một vấn đề.
Ví dụ: nếu 10 công ty, mỗi công ty có một kỹ sư hỗ trợ các bản sửa lỗi giống nhau, chuyển hướng các kỹ sư này sửa lỗi ngược dòng, thay vì di chuyển một bản sửa lỗi, họ có thể sửa 10 lỗi khác nhau vì lợi ích chung hoặc đến cùng nhau để xem xét các thay đổi được đề xuất. . Và tránh bao gồm mã lỗi trong hạt nhân. Các tài nguyên này cũng có thể được sử dụng để tạo các công cụ phân tích và kiểm tra mã mới sẽ tự động phát hiện ở giai đoạn đầu các lớp lỗi điển hình xuất hiện lặp đi lặp lại.
phím nấu ăn cũng đề xuất sử dụng tích cực hơn thử nghiệm tự động và làm mờ trực tiếp trong quá trình phát triển hạt nhân, sử dụng các hệ thống tích hợp liên tục và từ bỏ việc quản lý phát triển cổ điển thông qua e-mail.
Fuente: https://security.googleblog.com