1 điểm bởi GN⁺ 2024-01-16 | 1 bình luận | Chia sẻ qua WhatsApp
  • KB5034441 cho Windows 10 là bản cập nhật bảo mật nhằm chặn lỗ hổng vượt qua BitLocker, nhưng trên một số PC, quá trình cài đặt thất bại ở bước cài đặt
  • Trọng tâm của vấn đề là phân vùng khôi phục WinRE; kích thước phân vùng trong môi trường cài đặt Windows 10 tiêu chuẩn có thể không đủ để xử lý bản cập nhật
  • Khi cài đặt thất bại, mã 0x80070643 có thể được hiển thị, nhưng nguyên nhân thực tế có thể là lỗi phục vụ môi trường khôi phục tương ứng với CBS_E_INSUFFICIENT_DISK_SPACE
  • Giải pháp tạm thời của Microsoft là tắt WinRE từ Command Prompt quản trị viên rồi xóa và tạo lại phân vùng khôi phục, nên khá nguy hiểm với người dùng phổ thông
  • Người dùng phản ứng rằng quy trình này “quá kỹ thuật và đáng sợ”, trong khi sự bất bình ngày càng tăng rằng Microsoft nên tự phát hành bản sửa lỗi

Lỗi cài đặt KB5034441 và vấn đề phân vùng khôi phục

  • Microsoft đã phát hành KB5034441 cho Windows 10 21H2 và 22H2 vào ngày 9 tháng 1 năm 2024
    • Mục đích là chặn lỗ hổng có thể dùng Windows Recovery Environment, tức WinRE, để vượt qua mã hóa BitLocker
  • Một số người dùng gặp lỗi 0x80070643 trong quá trình cài đặt bản cập nhật
    • Mã này gần giống một thông báo lỗi cài đặt chung, và theo Microsoft, do “lỗi trong routine xử lý mã lỗi”, nó có thể không thể hiện chính xác nguyên nhân thực tế
  • Nguyên nhân thực tế có thể là thiếu dung lượng phân vùng khôi phục
    • Thông báo lỗi thực tế mà Microsoft đưa ra là Windows Recovery Environment servicing failed. (CBS_E_INSUFFICIENT_DISK_SPACE)
    • Có khả năng phân vùng khôi phục trên PC cài Windows 10 tiêu chuẩn không đủ lớn để xử lý bản cập nhật này

Quy trình vòng tránh thủ công đầy rủi ro

  • Microsoft hướng dẫn người dùng gặp vấn đề về dung lượng đĩa tự điều chỉnh phân vùng khôi phục theo KB5028997
    • Cần mở Command Prompt với quyền quản trị viên
    • Phải vô hiệu hóa WinRE rồi chạy các lệnh xóa và tạo lại phân vùng khôi phục
    • Đây là quy trình mà người dùng không quen rất dễ thao tác sai
  • Trên mạng xã hội, vấn đề đang xảy ra rộng rãi, và người dùng có xu hướng ngại áp dụng cách vòng tránh của Microsoft
    • Một số người dùng mô tả quy trình này là “quá kỹ thuật và đáng sợ”
    • Người dùng khác nói đây là “vấn đề Microsoft phải tự sửa”
    • Một người dùng khác nữa nói rằng người dùng không cần phải sửa sai lầm của Microsoft, và nếu hoãn cập nhật thì Microsoft sẽ phát hành bản sửa lỗi trong tương lai
  • Microsoft đã cập nhật tài liệu công khai liên quan vào ngày 16 tháng 1
    • Tuy nhiên, bản thân hướng dẫn không thay đổi
    • Công ty cho biết “chúng tôi đang làm việc trên một giải pháp và sẽ cung cấp bản cập nhật trong một bản phát hành tương lai”

1 bình luận

 
GN⁺ 2024-01-16
Ý kiến trên Hacker News
  • Trong lúc cài bản cập nhật, một số người dùng thấy lỗi 0x80070643; theo Microsoft thì có thể đây không phải lỗi thật mà là do “lỗi trong quy trình xử lý mã lỗi”
    Tức là mã lỗi dành cho lỗi lại hiển thị sai mã lỗi của lỗi vì bản thân nó cũng bị lỗi
    Tò mò không biết họ đụng vào phần mã xử lý mã lỗi thường xuyên đến mức nào mà vẫn còn sót một lỗi chưa được sửa từ rất lâu trước đây. Trông nó giống kiểu thứ làm một lần rồi để đó, nên nếu lỗi này tồn tại từ lâu mà không ai để ý thì có lẽ ngay cả việc đảm bảo chất lượng cho phần mã xử lý mã lỗi cũng có lỗi nốt

    • Vì vậy khi viết hoặc review mã xử lý ngoại lệ và đường đi lỗi, tôi luôn xem xét nó nghiêm ngặt và kỹ lưỡng hơn
      Theo tôi, nó phải đơn giản hơn mã ở luồng bình thường, cực kỳ dễ hiểu đến mức phi lý, và có độ kết dính thấp. Không kế thừa, không trừu tượng hóa, cây phụ thuộc cũng phải nông
      Tôi đã gặp quá nhiều lần hệ thống sập chỉ vì bug trong xử lý ngoại lệ. Các nhánh ngoại lệ vốn dĩ thường hầu như không được test hoặc bị bỏ sót, và ngoại lệ thì theo định nghĩa lại hay xuất hiện ở những chỗ không ai ngờ tới
    • Nói ra là lộ tuổi, nhưng bản OS/2 build tôi từng dùng ngày xưa thỉnh thoảng hiện “Thông báo lỗi này đã bị xóa”
    • Một bug tôi phụ trách khoảng 1 năm trước cuối cùng hóa ra là do ngoại lệ trong mã logging
      Chỉ đúng ở trường hợp mã logging ghi lại ngoại lệ do chính mã xử lý ngoại lệ ném ra thì mã logging lại tiếp tục phát sinh ngoại lệ. Vì là công cụ nội bộ nên tôi còn vui vẻ cố tình viết mục changelog sao cho khó hiểu nhất có thể
    • Thông báo tôi thích nhất là dòng chữ nhỏ “Something Happened”, rồi lại thêm “Something Happened”
  • Tôi đã làm thử theo hướng dẫn, và cũng hiểu vì sao với một số người dùng chuyện này có thể khá áp lực
    Tôi đã dùng Windows Disk Management để thu nhỏ phân vùng và tạo phần dung lượng cần thiết thay vì dùng dòng lệnh
    Tôi khá ngạc nhiên vì không có script cho quy trình này, nhưng có lẽ điều đó cũng cho thấy nó phức tạp và rất dễ sai. Vì thế tôi nghĩ lý do không có script chỉ cần double-click để xong cũng là vì bản thân công việc này vốn rắc rối
    Khó mà lạc quan về một bản sửa Windows Update nhanh như nhiều người mong đợi, nhưng có lẽ sắp có các nhà phát triển bên thứ ba tung ra script hoặc chương trình tự động hóa quy trình này

    • Tự động thay đổi đĩa/phân vùng có vẻ đi kèm rủi ro mất dữ liệu nghiêm trọng khá cao
    • Có vẻ giờ đã có script PowerShell, nhưng hình như nó không đổi kích thước phân vùng. Không biết đã có ai dùng thử chưa
      https://support.microsoft.com/en-us/topic/kb5034957-updating...
  • Có đoạn nói về “lỗ hổng cho phép kẻ tấn công lợi dụng Windows Recovery Environment (WinRE) để vượt qua mã hóa BitLocker”, nhưng từ trước đến nay tôi vẫn luôn thấy lạ vì môi trường khôi phục dường như cho phép truy cập vào ổ hệ thống đã được tự động giải mã với quyền SYSTEM
    Nhiều năm nay đã vậy, và còn có thể dùng nó để dump dữ liệu trong những máy bị quên mật khẩu đăng nhập. Có lẽ đây vốn không phải hành vi được chủ đích thiết kế

    • Chuyện đó chỉ đúng khi không dùng TPM PIN hoặc TPM thấp hơn 2.0
      Với cơ chế TPM của BitLocker khi dùng kèm PIN, không thể biết khóa ổ cứng nếu không hỏi TPM, và TPM thì sẽ yêu cầu PIN. Nó cũng có sẵn cơ chế chống brute-force và khóa truy cập
    • Nếu tôi nhớ không nhầm thì WinRE chẳng phải sẽ yêu cầu mật khẩu quản trị viên cục bộ trước khi làm thao tác khôi phục sao?
      Vì vậy “tự động mở khóa” thường là một tính năng có kèm rất nhiều điều kiện, và đó cũng là một trong những lý do người ta khuyến nghị dùng PIN, mật khẩu hoặc mở khóa qua mạng nếu có thể. Dù vậy, điểm bất tiện là mỗi lần cập nhật lại phải trông chừng laptop và mở khóa mỗi khi nó khởi động lại
  • Microsoft không thể xây lại một bộ phận đảm bảo chất lượng tử tế thay vì giao cho các Insiders không lương sao? Cứ như thể họ đang dựa vào những người uống Flavor-Aid và tin rằng Microsoft không thể nào viết sai dù chỉ một dòng mã

    • Nhìn vào cộng đồng phản hồi thì có lẽ đánh đồng toàn bộ Insiders như vậy là không chính xác
      Tuy nhiên đúng là họ đã bỏ bộ phận đảm bảo chất lượng truyền thống gần 10 năm nay, và bộ phận đó từng làm nhiều hơn là chỉ tận dụng xác minh từ người dùng bên ngoài. Thành thật mà nói, khó bảo rằng Windows hiện nay hay nổ tung hơn 10 năm trước đó, nhưng tôi rất muốn xem số liệu thực tế về thống kê sự cố do lỗi bản vá trong 20 năm qua ở những nơi như hệ thống y tế
  • Dù cách sửa trông đáng sợ, tôi vẫn thấy đáng cảm ơn vì ít nhất họ cũng đưa ra cái gì đó
    Vài năm trước có một bản cập nhật phá hỏng mảng ReFS của không ít người, khi đó ngoài rollback ra thì chẳng có giải pháp nào, rồi cuối cùng bản cập nhật ấy lại trở thành bắt buộc nên cũng không thể gỡ nữa, khiến phải dựng lại cả mảng từ đầu

    • Có đưa ra cái gì đó thật, nhưng đây vẫn là một sự cố lớn
      Không nên biết ơn chỉ vì một sản phẩm trả phí ném cho mình chút vụn vặt. Nếu tôi đọc khác ý bạn thì xin lỗi
      Microsoft phải chịu trách nhiệm vì làm hỏng quá trình cài đặt rồi đưa ra một biện pháp khắc phục nửa vời. Dù vấn đề có phức tạp đi nữa, đây vẫn là công ty dẫn đầu thị trường hệ điều hành desktop và kiếm rất nhiều tiền từ đó, nên họ phải làm tốt hơn
  • Vấn đề là phân vùng khôi phục không tồn tại hoặc không đủ lớn
    Trên máy ảo Win10, tôi không cần phân vùng khôi phục nên đã xóa nó sau khi cài đặt, và giờ thì không thể cập nhật bản cài đó nữa

    • Tôi đã làm theo hướng dẫn để vô hiệu hóa phân vùng khôi phục, và có lẽ ngay từ đầu tôi cũng không cấp không gian cho nó
      Sau khi khởi động lại, tôi đã có thể nâng cấp lên Windows 11, và hy vọng về sau không phát sinh vấn đề lớn hơn. Tôi thực sự không muốn động vào bước tiếp theo được hướng dẫn là đổi kích thước phân vùng hệ thống
      Tùy từng trường hợp, nhưng thật thú vị khi bug tôi tình cờ gặp lại xuất hiện trên trang nhất Hacker News
  • Có câu kiểu như “tôi dùng Windows vì không muốn phải chui vào dòng lệnh chỉ để sửa một lỗi đơn giản”, nhưng hóa ra là đã ở sẵn trong câu lạc bộ đó rồi
    Vài năm trước, Windows đột nhiên cho rằng tôi không có quyền truy cập thư mục người dùng của mình, khiến Explorer và thanh tác vụ hỏng hóc kỳ quặc
    Muốn sửa thì phải vào console quản trị, tạo người dùng mới, chuyển các tệp từ tài khoản cũ sang tài khoản mới, rồi đổi quyền sở hữu và quyền truy cập. Vì vậy, ý nghĩ rằng Windows dễ vì có giao diện đồ họa là chuyện vớ vẩn
    Đằng nào nếu cũng rơi vào các chế độ lỗi quái đản và phải gõ lệnh để khắc phục thì tôi thà tiếp tục dùng Linux và NetBSD

  • Với tư cách là cựu lập trình viên Windows, tôi nhớ mình từng cực kỳ bực bội vì nâng cấp Windows
    Không còn có thể ghi vào thư mục cài đặt một cách ổn định nữa, rồi họ bắt ghi vào registry, sau đó lại bắt chia ra ghi vào thư mục dữ liệu và các vị trí khác. Thành ra phải chẻ quá trình cài đặt thành “mười nhánh” để quản lý vị trí dữ liệu, xử lý HKEY_LOCAL_MACHINE, HKEY_CURRENT_USER, v.v., rồi sau đó còn phải yêu cầu nâng quyền khi cài đặt
    Tôi cũng còn lờ mờ nhớ đã từng debug một lỗi mà sau khi xóa tệp trong thư mục cài đặt, Windows lại tự khôi phục phiên bản cũ của tệp đó ở nền. c:\program files đã bị ảo hóa nên không còn hoạt động như một thư mục thật nữa

    • Việc không còn có thể ghi ổn định vào thư mục cài đặt có lẽ là thay đổi được đưa vào từ thời Windows XP, và tôi cho đó là thay đổi tốt
      Để chương trình người dùng ghi vào thư mục đầy các tệp thực thi là điều kinh khủng về mặt bảo mật
  • Cũng có thể cho rằng tốt hơn là đừng cài mọi bản cập nhật ngay khi chúng vừa được phát hành

    • Với macOS và iOS thì tôi dùng kiểu chờ một chút, nhưng với Windows thì tôi không tìm ra cách nào để giải thích rằng mình không muốn cập nhật tự động
      Đặc biệt là rất phiền nếu nó cập nhật giữa chừng khi đang chạy các tác vụ tính toán qua đêm
    • Microsoft đã thay đổi chuyện đó chưa, hay Windows 10 Home vẫn còn ép người dùng cài ngay các bản cập nhật mới nhất?
    • Microsoft có tự thử ăn các bản cập nhật đó trước trong nội bộ như cách Google làm với Android và Chrome OS không?
  • Nếu nhà báo đã từng dùng Linux thì hẳn đã biết rằng nó hiển thị thông báo lỗi tốt hơn nhiều so với các mã lỗi trông như dãy số ngẫu nhiên

    • Chẳng phải đây đúng nghĩa là trường hợp hiển thị sai thông báo lỗi sao?
      Theo Microsoft, do “lỗi trong routine xử lý mã lỗi” nên lỗi này có thể không phải là lỗi đúng
    • Thứ khiến Windows dễ dùng không phải là thông báo lỗi mà là sửa bằng một cú nhấp chuột
    • Mã thoát 139 à, hừm
    • Đúng, nhưng đôi khi thông báo hữu ích chỉ có thể tìm thấy trong dmesg