Bản vá lỗi trực tiếp Linux Kernel trên Ubuntu 20.04 LTS

[theanh]

Điều gì đã xảy ra với lời hứa về bản vá lỗi trực tiếp cho nhân Linux? Bài viết này sẽ xem xét lịch sử của nó, các vấn đề của nó và những cách rẻ nhất và dễ nhất để thực hiện trên UbuntuFocal Fossa (20.04 LTS).

Giới thiệu​

'Bản vá lỗi trực tiếp' là hành động cập nhật chương trình mà không dừng hệ thống đang chạy chương trình đó. Lần đầu tiên, nó được thực hiện bằng hàn và dây, sau đó là bằng kéo và keo dán—không có gì mới. Ngày nay, bản vá lỗi trực tiếp cho nhân Linux ít dính hơn nhiều.

Trong bài viết này, tôi sẽ giải thích bản vá lỗi trực tiếp là gì, hoạt động như thế nào (theo thuật ngữ không chuyên môn) và nguồn gốc của nó. Tôi sẽ kết thúc bằng cách chỉ cho bạn cách tự động hóa các bản cập nhật bảo mật hạt nhân trên Ubuntu 20.04 LTS (Focal Fossa) bằng Dịch vụ Livepatch Canonical và KernelCare.

Live Patching là gì?​

Trong phần mềm, bản vá là một đoạn mã chỉnh sửa nhỏ. Bản vá là sửa chữa hoặc cải thiện một phần nhỏ của chương trình mà không làm gián đoạn hoạt động hoặc thông số kỹ thuật của toàn bộ. Bản vá trực tiếp (hoặc nóng) có nghĩa là thay đổi một chương trình đang chạy mà không dừng nó lại.

Hãy tưởng tượng bạn bị kẹt trong một chiếc ô tô đang chạy và bạn cần sửa một bóng đèn. Không tệ lắm, bạn có thể nói, nếu nó ở bên trong, nhưng hơi khó hơn một chút ở bên ngoài. Bây giờ hãy tưởng tượng việc sửa trục cam, thay thế thanh piston hoặc bịt kín một khối bị nứt.

Điều này tương tự như những gì bản vá trực tiếp đang cố gắng thực hiện trên hạt nhân Linux. Nó đang cố gắng sửa chữa các bộ phận của một thứ gì đó đang chuyển động, mà không thay đổi hoặc phá vỡ nó, nhưng quan trọng nhất là không dừng nó lại. Nhân là phần duy nhất của hệ thống Linux cần tắt máy và khởi động lại để áp dụng bản cập nhật. Khi nhà cung cấp phát hành bản cập nhật nhân, quản trị viên hệ thống không có lựa chọn nào khác ngoài việc lên lịch khởi động lại máy chủ.

Khởi động lại có gì tệ?​

Khởi động lại có ý nghĩa khác nhau đối với những người khác nhau, tùy thuộc vào việc họ có đang sử dụng hệ thống hay chịu trách nhiệm về hệ thống đó hay không. Nhiều quản trị viên hệ thống coi việc khởi động lại thường xuyên là dấu hiệu của sức khỏe tốt, giống như việc đi tiêu đều đặn. Cũng giống như nhiều người khác, họ chống lại mọi sự gián đoạn đối với các ứng dụng mà họ đầu tư và kiếm tiền từ đó, chẳng hạn như các ứng dụng như thế này.

• máy chủ web, với những người dùng bận rộn, năng động trên nhiều múi giờ
• trò chơi nhiều người chơi trực tuyến
• phát trực tiếp hoặc ghi lại video trả tiền theo lượt xem
• khai thác tiền điện tử
• dịch vụ giám sát và ghi hình video từ xa, 24/7

Đối với tôi, hầu hết Lý do dễ hiểu là nỗi lo sợ rằng hệ thống sẽ không còn như trước nữa và các ứng dụng quan trọng (kiếm tiền) sẽ không khởi động được. Tôi nghĩ chính điều này, chứ không phải viễn cảnh về những người dùng hung hăng, khiến nhiều quản trị viên hệ thống trì hoãn việc cập nhật kernel, ngay cả loại cập nhật quan trọng nhất, cập nhật bảo mật.

(Ở đây, tôi chỉ nói về cập nhật. nâng cấp kernel là một thứ khác. Nâng cấp là kernel hoàn toàn mới. Bản vá là bản cập nhật cho các phần của kernel, thường là bản sửa lỗi không thể chờ đợi vì chúng có liên quan đến bảo mật hoặc các tác động rộng khác.)

Khi một nhà cung cấp Linux phát hành bản vá kernel, thường là để khắc phục sự cố bảo mật. Ghi chú tư vấn liên quan sẽ nói đại loại như, ‘Cài đặt sớm nhất có thể.’ Trên cùng một trang sẽ có phiên bản của, ‘Nếu bạn không cài đặt, bạn sẽ dễ bị khai thác bởi các lỗ hổng mà chúng tôi đã vá mà mọi người hiện đều biết. Chúc một ngày tốt lành.’

Những ghi chú được viết một cách vô cảm như vậy làm nổi bật tình thế tiến thoái lưỡng nan thúc đẩy sự ra đời của bản vá trực tiếp: bạn nên giữ cho người dùng "đau đớn nhưng an toàn" hay "bình tĩnh nhưng bị phơi bày"? Bản vá trực tiếp hứa hẹn sẽ là Đảo Thiên đường giữa Đá và Nơi Khó khăn. Bản vá trực tiếp hứa hẹn sẽ giúp giữ cho máy chủ của bạn an toàn và ở mức bảo mật mới nhất, mà không ảnh hưởng đến thời gian ngừng hoạt động và không ảnh hưởng đến các dịch vụ.

Đảo Thiên đường? Cái bẫy ở đây là gì?​

Mặc dù mã nguồn cho phần mềm vá trực tiếp có sẵn miễn phí, nhưng các bản vá thì không. Lời hứa ngọt ngào của bản vá trực tiếp trở nên tệ hại khi bạn phải tự viết các bản vá của riêng mình. Huyết áp của bạn sẽ giảm khi ít quản trị hơn nhưng lại tăng trở lại khi xử lý mã hạt nhân phức tạp.

Mặc dù về mặt kỹ thuật, bạn có thể tự tạo các bản vá của riêng mình, nhưng điều này đòi hỏi rất nhiều công sức và kiến thức chuyên môn. Và nó rất rủi ro - một bản vá được viết kém có thể làm sập hệ thống. (Thông báo này trên trang github kpatch giống như một thông báo từ sổ tay hướng dẫn vận hành máy búa hơi nước: 'CẢNH BÁO: Sử dụng thận trọng! Kernel bị sập, tự khởi động lại và có thể mất dữ liệu!')

Các nhà cung cấp Linux biết rằng việc vá lỗi trực tiếp đúng cách khó khăn như thế nào và đã phát triển các dịch vụ có lợi nhuận để tận dụng thực tế này. Mỗi bản phân phối Linux chính đều có một phương pháp vá lỗi trực tiếp miễn phí khi cài đặt nhưng không được sử dụng. Các bản vá, nếu không có chúng thì toàn bộ ý tưởng này là vô dụng, phải trả tiền.

Tuy nhiên, lợi ích của việc vá lỗi nhân trực tiếp rất hấp dẫn đến mức các mô hình kinh doanh này phát triển mạnh trong hệ sinh thái phần mềm nguồn mở và miễn phí chủ yếu của Linux. Đối với tôi, đây là dấu hiệu cho thấy công nghệ này có ý nghĩa và đóng vai trò quan trọng trong tương lai của các hệ thống dựa trên Linux.

Cách thức hoạt động của Live Patching​

Vẫn bị mắc kẹt trong chiếc xe tưởng tượng đó, giờ đang lao xuống dốc về phía một đống hộp các tông rỗng (hy vọng là) tưởng tượng, bạn sẽ sửa phanh như thế nào? Xây dựng một con đội lăn tạm thời để thực hiện công việc? Nghiêng người trên ba bánh xe, đợi một bánh xe dừng lại, tháo nó ra, lặp lại cho đến khi hoàn thành?

Các lập trình viên nhân Linux hẳn đã sử dụng cùng một kiểu suy nghĩ để giải quyết vấn đề vá lỗi trực tiếp. Tôi cảm nhận được cùng một loại thiết bị khái niệm (treo, hoán đổi, sử dụng các cấu trúc hỗ trợ tạm thời) đang hoạt động trong các giải pháp của họ. Phép loại suy thô sơ về thay đổi phanh ở trên minh họa cho hai chiến lược đối lập được các nhà cung cấp phần mềm vá lỗi trực tiếp triển khai.

• Dừng mọi thứ và thực hiện tất cả các bản sửa lỗi cùng một lúc.
• Đợi các thành phần riêng lẻ dừng lại, sau đó hoán đổi chúng. Lặp lại cho đến khi hoàn tất.

Phân chia này giải thích lý do tại sao mỗi nhà cung cấp đưa ra các cách tiếp cận khác nhau để giải quyết cùng một vấn đề. Tuy nhiên, điểm chung của chúng là sử dụng khuôn khổ mô-đun hạt nhân có thể tải của Linux. Phần mềm điều phối và triển khai quy trình vá lỗi là mô-đun hạt nhân Linux. Điều đó có nghĩa là dễ dàng thêm chức năng vá lỗi vào các hạt nhân tương thích và cũng dễ dàng xóa chức năng đó.

Trước khi đi sâu hơn, tôi phải đề cập đến những cảnh báo.

Phạm vi và quy mô của các bản vá lỗi phần mềm mà bạn có thể áp dụng cho các hệ thống đang chạy bị giới hạn. Trước hết, các hạt nhân tùy chỉnh, được tối ưu hóa hoặc không chuẩn khiến việc vá lỗi trực tiếp cho một hạt nhân trở nên khó khăn hoặc không thể thực hiện được. Mặt khác, việc vá lỗi trực tiếp không thể ánh xạ lại dữ liệu hoặc bộ nhớ trên các bản vá; nó chỉ có thể thay đổi định nghĩa hàm.

Những thiếu sót này không ngăn cản Ksplice trở thành công cụ đầu tiên trong lĩnh vực vá lỗi trực tiếp Linux. Công cụ này hoạt động bằng cách so sánh mã nguồn cũ và mới, từ đó tạo ra bản vá nhị phân. Công cụ này đóng băng hệ thống, tìm ra hàm nào cần thay đổi và chỉnh sửa tiêu đề của chúng. Khi được gọi, các hàm sẽ chuyển hướng sang phiên bản mới. Nếu bản vá được viết tốt, quá trình kiểm soát sẽ diễn ra như thể không có chuyện gì xảy ra.

Một sự kiện địa chấn (được mô tả trong phần tiếp theo) đã chứng kiến Kpatch của Red Hat và Kgraft của SUSE tham gia vào bối cảnh này với những diễn giải riêng của họ về các vấn đề cốt lõi của bản vá trực tiếp.

Kpatch so sánh mã nguồn cũ và mới để tạo bản vá. Giống như Ksplice, nó hoạt động bằng cách chuyển hướng các lệnh gọi hàm bằng cách sử dụng kernel ftrace framework để chuyển đổi các hàm đã thay đổi cùng một lúc.

Kgraft hoạt động theo cách khác. Nó sử dụng hai tập hợp hàm đồng thời, cũ và mới, với một mô-đun orchestrator quyết định thời điểm chuyển hướng các hàm tùy thuộc vào nơi thực thi đã đạt đến. Không thể dự đoán được con trỏ chương trình nằm ở đâu trong một hàm tại bất kỳ thời điểm nào, vì vậy quá trình chuyển đổi diễn ra dần dần chứ không phải ngay lập tức.

Nguồn gốc của Live Patching​

Làm thế nào mà ý tưởng sửa phần mềm mà không ai nhận ra lại xuất hiện trong khối thống nhất luôn thay đổi của nỗ lực con người, hạt nhân Linux?

Mặc dù khái niệm này có nguồn gốc từ những ngày đầu tiên của điện toán có thể lập trình, nhưng đối với mục đích của chúng ta, dấu vết bắt đầu vào năm 2001 khi Hewlett Packard cấp bằng sáng chế cho một phương pháp cập nhật phần mềm động để bù đắp cho chức năng phần cứng bị thiếu. Một năm sau, Microsoft đưa ra ý tưởng cập nhật hệ thống (Windows) mà không bị gián đoạn.

Không đề cập đến Linux, nhưng các ứng dụng rất rộng, mỗi ứng dụng mô tả cách khắc phục sự cố phần mềm hoặc phần cứng trên máy tính mà không làm gián đoạn các quy trình đang chạy trên máy. (Nếu ý tưởng này không khiến bạn thấy đặc biệt hữu ích, có lẽ hai từ sau sẽ khiến bạn phải suy nghĩ lại: Meltdown và Spectre.)

Năm 2008, Jeff Arnold công bố Ksplice, phần mềm vá lỗi nhân Linux mà không cần khởi động lại. Đây là phần mềm đầu tiên thuộc loại này dành cho Linux. Và chúng ta phải cảm ơn một hacker vô danh, không rõ tên vì điều này.

Để biết lý do, hãy để tôi đưa bạn trở lại thời sinh viên MIT của Jeff. Anh ấy là thành viên của một nhóm tình nguyện quản lý máy chủ cho cộng đồng sinh viên. Một trong những máy chủ cần bản vá bảo mật. Anh ấy không muốn đuổi người dùng của mình đi nên đã để nó trôi qua trong vài ngày.

Trong vài ngày đó, trước khi anh ấy có thể cập nhật, ai đó đã hack hệ thống. Cách duy nhất để đưa nó trở lại trực tuyến là cài đặt lại hoàn toàn từ đầu. Giả sử các đồng nghiệp của anh ấy nhận thấy điều đó. Ngay cả khi họ không phải chịu đau khổ, tôi vẫn tưởng tượng Jeff dành phần còn lại của học kỳ để chậm rãi nướng than của sự chế giễu của sinh viên.

Nếu câu chuyện là ngụy tạo, thì hãy coi đó là một câu chuyện ngụ ngôn, một lời nhắc nhở rằng việc vá lỗi trực tiếp là con đẻ của sự an toàn, không phải của sự tiện lợi. Và giống như tất cả những câu chuyện ngụ ngôn hay, có một kết thúc có hậu.

Sự cố này đã truyền cảm hứng cho Jeff nghiên cứu cách cài đặt các bản vá lỗi hạt nhân Linux mà không chậm trễ và không bị gián đoạn. Anh lấy vấn đề này làm chủ đề cho luận văn thạc sĩ năm 2006 của mình. Giải pháp nằm ở dạng phần mềm có tên là Ksplice. Cùng với một đồng nghiệp, anh đã viết một bài báomô tả nó, có tiêu đề là 'Ksplice: Cập nhật hạt nhân tự động không cần khởi động lại.'

Jeff và ba người bạn sinh viên của mình thành lập một công ty và vào tháng 5 năm 2009, họ đã giành được giải thưởng Cuộc thi khởi nghiệp trị giá 100.000 đô la của MIT. Họ ra mắt một dịch vụ thương mại vào năm 2010. Một năm sau, trong kiểu kết thúc nghiệp chướng mà mọi nhà phát triển phần mềm đều mơ ước, Oracle mua Ksplice Inc.

Karma không hề tồn tại trong tâm trí của người dùng và khách hàng của tiện ích mới vô cùng hữu ích này. Đối với họ, đây là khởi đầu của một chuỗi ác mộng dài và mệt mỏi. Oracle đồng hóa hoàn toàn Ksplice, biến công cụ này thành miễn phí chỉ dành cho khách hàng của các phiên bản Linux do họ tài trợ, có phí hỗ trợ.

Cú sốc địa chấn này thúc đẩy SUSE và Red Hat phát triển các giải pháp riêng của họ, không bên nào nói với bên kia về ý định hoặc kiến trúc giải pháp của mình. Họ làm việc độc lập từ năm 2011 đến năm 2014, phát hành các phương pháp tiếp cận riêng biệt của mình cách nhau vài tuần. Vào tháng 5 năm 2014, CloudLinux, nhà sản xuất biến thể Linux nổi tiếng trong lĩnh vực lưu trữ web, đã phát hành dịch vụ vá lỗi trực tiếp cho nhân Linux thương mại dưới tên KernelCare.

Cùng lúc đó, một bản vá lỗi trực tiếp ABI đang dần đi vào dòng chính của nhân, và được đưa vào sử dụng trong Bản phát hành 4.0 dưới tên Livepatch. Vào tháng 10 năm 2016, Canonical, những người sáng tạo ra Ubuntu, sử dụng nó làm cơ sở cho dịch vụ thương mại dưới cái tên không biết xấu hổ là ‘Canonical Livepatch Service’. Canonical phát hành đầu tiên cho 16.04 LTS, sau đó là 14.04 LTS, cả hai đều yêu cầu thiết lập trên dòng lệnh. Trong 18.04 LTS, nó trở nên dễ thấy hơn, dễ sử dụng hơn và được tích hợp tốt hơn vào trải nghiệm máy tính để bàn Ubuntu và hiện đã có sẵn cho 20.04 LTS.

Cách thực hiện: Cập nhật bảo mật hạt nhân tự động trên Ubuntu 20.04 LTS​

Bây giờ là lúc xem nó hoạt động. Có hai giải pháp vá lỗi trực tiếp cho Ubuntu, được đề cập trong hai phần tiếp theo.

Cài đặt Canonical Livepatch Service (CLS)​

CLS miễn phí cho các cá nhân không phải là doanh nghiệp thương mại, cho tối đa ba máy. Nó yêu cầu phải đăng ký, nhưng bạn có thể sử dụng tài khoản Ubuntu One nếu có. Nếu bạn muốn cài đặt trên nhiều hơn ba máy, bạn sẽ phải mua thỏa thuận dịch vụ hỗ trợ theo kiểu doanh nghiệp.

Trước khi bắt đầu​

• Đảm bảo hệ thống của bạn được cập nhật và sao lưu.
• Đăng ký Livepatch hoặc Ubuntu One tài khoản.
• Đối với Máy chủ 20.04 LTS, lấy một khóavà ghi lại khóa đó. (Không cần khóa này trên phiên bản Máy tính để bàn.)

Cài đặt Livepatch trên Máy tính để bàn Ubuntu 20.04 LTS​

Máy tính để bàn Ubuntu 20.04 LTS có cài đặt GUI để kích hoạt CLS. Bạn có thể thực hiện cài đặt này trong quá trình thiết lập sau khi cài đặt hoặc sau đó bằng cách mở Phần mềm & Cập nhật và chuyển đến tab Livepatch.

Trên bản cài đặt Ubuntu mới​

Sau lần khởi động lại đầu tiên của bản cài đặt mới, hãy chú ý đến màn hình thứ hai của cửa sổ hộp thoại ‘Có gì mới trong Ubuntu’. Màn hình này cho phép bạn thiết lập Livepatch.

1. Nhấp vào ‘Thiết lập Livepatch…’
2. Tại màn hình ‘Tài khoản đăng nhập một lần Ubuntu’, hãy đăng nhập bằng tài khoản Livepatch hoặc Ubuntu One của bạn.
3. Nếu bạn đang sử dụng GUI cài đặt dạng văn bản, trong ‘Featured Server Snaps’, hãy chọn canonical-livepatch.

Trên bản cài đặt Ubuntu hiện có​

1. Mở ‘Phần mềm & Cập nhật’ và đi đến tab ‘Livepatch’.
2. Đăng nhập.
3. Sau khi đăng nhập, hãy nhấp vào Tiếp tục khi cửa sổ bật lên xác nhận bạn đã đăng nhập xuất hiện.
4. Vậy là xong. Livepatch được thiết lập trên Desktop Ubuntu 20.04 của bạn.

Lỗi trong Ubuntu 20.04 với Livepatch

Bạn có thể gặp phải lỗi sau khi bật Livepatch trên Ubuntu 20.04Focal Fossa:

Không bật được Livepatch: không thể bật máy: ID máy này đã được bật bằng khóa khác hoặc không phải là duy nhất. Hoặc "sudo canonical-livepatch disable" trên máy kia hoặc tạo lại một /etc/machine-id duy nhất trên máy này với "sudo rm /etc/machine-id /var/lib/dbus/machine-id && sudo systemd-machine-id-setup" phản hồi của máy chủ: Xung đột machine-id

Để sửa lỗi, hãy nhập các lệnh sau vào thiết bị đầu cuối:

cp /etc/machine-id /etc/machine-id.original 
cp /var/lib/dbus/machine-id /var/lib/dbus/machine-id.original 
nano /etc/machine-id (để xóa giá trị hiện tại) 
systemd-machine-id-setup 
> Khởi tạo ID máy từ ID máy D-Bus. 
cat /etc/machine-id[/b]

Cài đặt Livepatch trên Máy chủ Ubuntu 20.04 LTS​

Đây là phương pháp dòng lệnh dành cho các phiên bản máy chủ tiêu chuẩn không cài đặt hệ thống cửa sổ. Nó cũng hoạt động trên các phiên bản 16.04 LTS, 14.04 LTS và 18.04 LTS.

Mở một thiết bị đầu cuối và nhập hai lệnh sau:

sudo snap install canonical-livepatch[B]sudo canonical-livepatch enable

Mẹo​

​

• Lệnh thứ hai trả về một mã thông báo máy. Nó không có mục đích gì và không cần phải ghi lại.
• Theo dõi các máy bạn đang đăng ký. Nếu bạn mất dấu hoặc vứt bỏ máy hoặc VM trước khi hủy đăng ký, về cơ bản bạn đang vứt bỏ một trong ba giấy phép miễn phí của mình. (Có trợ giúp tại đây.)
• Để hủy đăng ký máy chủ, hãy sử dụng lệnh này:

sudo canonical-livepatch disable

• Để kiểm tra trạng thái của dịch vụ, hãy sử dụng lệnh này:

sudo canonical-livepatch status --verbose[B][/b]

Cài đặt KernelCare​

KernelCare sử dụng thiết lập dòng lệnh; không có GUI. Nó hỗ trợ nhiều hệ điều hành hơn, bao gồm CentOS, RHEL, Oracle Linux, Debian, Ubuntu và các hệ điều hành khác. Nó cũng hỗ trợ dòng kernel 2.6.32 cũ hơn.

Trái ngược với CLS, nó hoàn toàn tự động và sẽ kiểm tra các bản vá phát hành bốn giờ một lần, cài đặt chúng mà không cần giám sát nếu có. Nếu bạn cần ghi đè khả năng đó hoặc liên kết máy chủ với các bản vá ngày cố định, có một tiện ích dòng lệnh (kcarectl) cho phép bạn thực hiện việc này và những việc khác.

KernelCare miễn phí cho các tổ chức phi lợi nhuận hoặc có bản dùng thử miễn phí 30 ngày cho những người còn lại. (Nếu bạn là người dùng Ksplice, bạn có thể muốn dùng thử Ksplice-to-KernelCare hai bước script di chuyển.)

Trước khi bắt đầu​

• Đảm bảo hệ thống của bạn được cập nhật và sao lưu.
• Nhận khóa dùng thử miễn phí từ tại đây.

Cài đặt KernelCare trên máy tính để bàn và máy chủ Ubuntu 20.04 LTS​

Mở một thiết bị đầu cuối và nhập hai lệnh sau:

sudo wget -qq -O - https://repo.cloudlinux.com/kernelcare/kernelcare_install.sh | bash[B]sudo /usr/bin/kcarectl --register KEY

Các lệnh này cũng hoạt động trên các phiên bản 16.04 LTS, 14.04 LTS và 18.04 LTS.

Mẹo[/b]​

• Để hủy đăng ký máy chủ, hãy sử dụng lệnh này:

sudo kcarectl --unregister

• Để kiểm tra trạng thái của dịch vụ, hãy sử dụng lệnh này:

sudo kcarectl --info[B][/b]

Kết luận​

Bản vá trực tiếp trên Linux hữu ích đến mức không thể miễn phí trong thời gian dài.

Với bản phát hành 20.04 LTS của Ubuntu, bạn có thể dễ dàng tận hưởng những lợi ích của bản vá bảo mật trực tiếp cho hạt nhân Linux và bản vá này miễn phí cho tối đa ba máy chủ. Sau đó, hàng năm, mỗi máy chủ sẽ áp dụng mức phí phí.

Nếu bạn chạy nhiều phiên bản Linux nhưng không muốn tìm hiểu các sản phẩm khác nhau hoặc đăng ký nhiều hợp đồng hỗ trợ khác nhau, hãy xem KernelCare. Giá rẻ hơn khoảng năm lần khi đăng ký theo năm và họ cung cấp các gói đăng ký theo tháng linh hoạt.