Kees Cook ຂອງ Google ຮຽກຮ້ອງໃຫ້ປັບປຸງຂະບວນການເຮັດວຽກກ່ຽວກັບຂໍ້ບົກພ່ອງໃນ Linux kernel

Kees Cook, ອະດີດຫົວຫນ້າຜູ້ບໍລິຫານລະບົບຂອງ kernel.org ແລະຜູ້ນໍາຂອງທີມງານຄວາມປອດໄພ Ubuntu ຜູ້ທີ່ປະຈຸບັນເຮັດວຽກຢູ່ Google ເພື່ອຮັບປະກັນ Android ແລະ ChromeOS, ສະແດງຄວາມກັງວົນກ່ຽວກັບຂະບວນການປະຈຸບັນຂອງການແກ້ໄຂຂໍ້ບົກພ່ອງໃນສາຂາທີ່ຫມັ້ນຄົງຂອງ kernel. ທຸກໆອາທິດ, ປະມານຫນຶ່ງຮ້ອຍການແກ້ໄຂແມ່ນລວມຢູ່ໃນສາຂາທີ່ຫມັ້ນຄົງ, ແລະຫຼັງຈາກປ່ອງຢ້ຽມສໍາລັບການຍອມຮັບການປ່ຽນແປງໃນການປ່ອຍຕໍ່ໄປຖືກປິດ, ມັນເຂົ້າຫາຫນຶ່ງພັນຄົນ (ຜູ້ຮັກສາຮັກສາການແກ້ໄຂຈົນກ່ວາປ່ອງຢ້ຽມປິດ, ແລະຫຼັງຈາກການສ້າງຕັ້ງ " -rc1” ພວກເຂົາເຜີຍແຜ່ສະສົມໃນຄັ້ງດຽວ), ເຊິ່ງມີຫຼາຍເກີນໄປແລະຕ້ອງການແຮງງານຫຼາຍສໍາລັບການບໍາລຸງຮັກສາຜະລິດຕະພັນໂດຍອີງໃສ່ Linux kernel.

ອີງຕາມການ Keys, ຂະບວນການເຮັດວຽກກັບຄວາມຜິດພາດໃນ kernel ບໍ່ໄດ້ຮັບຄວາມສົນໃຈອັນເນື່ອງມາຈາກແລະ kernel ຂາດຢ່າງຫນ້ອຍ 100 ນັກພັດທະນາເພີ່ມເຕີມສໍາລັບການເຮັດວຽກປະສານງານໃນຂົງເຂດນີ້. ນັກພັດທະນາ kernel ຕົ້ນຕໍແກ້ໄຂຂໍ້ບົກຜ່ອງເປັນປະຈໍາ, ແຕ່ບໍ່ມີການຮັບປະກັນວ່າການແກ້ໄຂເຫຼົ່ານີ້ຈະຖືກນໍາໄປໃຊ້ກັບຕົວແປ kernel ທີ່ໃຊ້ໂດຍພາກສ່ວນທີສາມ. ຜູ້ໃຊ້ຜະລິດຕະພັນຕ່າງໆໂດຍອີງໃສ່ Linux kernel ຍັງບໍ່ມີວິທີທີ່ຈະຄວບຄຸມວ່າແມງໄມ້ໃດຖືກແກ້ໄຂແລະ kernel ໃດຖືກໃຊ້ໃນອຸປະກອນຂອງພວກເຂົາ. ໃນທີ່ສຸດ, ຜູ້ຜະລິດມີຄວາມຮັບຜິດຊອບຕໍ່ຄວາມປອດໄພຂອງຜະລິດຕະພັນຂອງພວກເຂົາ, ແຕ່ດ້ວຍຄວາມເຂັ້ມຂົ້ນສູງຂອງການແກ້ໄຂການພິມເຜີຍແຜ່ໃນສາຂາແກ່ນທີ່ຫມັ້ນຄົງ, ພວກເຂົາປະເຊີນຫນ້າກັບທາງເລືອກ - port ການແກ້ໄຂທັງຫມົດ, ເລືອກ ports ທີ່ສໍາຄັນທີ່ສຸດ, ຫຼືບໍ່ສົນໃຈການແກ້ໄຂທັງຫມົດ. .

ການແກ້ໄຂທີ່ດີທີ່ສຸດແມ່ນການເຄື່ອນຍ້າຍພຽງແຕ່ການແກ້ໄຂທີ່ສໍາຄັນທີ່ສຸດແລະຈຸດອ່ອນ, ແຕ່ການແຍກຄວາມຜິດພາດດັ່ງກ່າວອອກຈາກການໄຫຼທົ່ວໄປແມ່ນບັນຫາຕົ້ນຕໍ. ຈໍານວນທີ່ໃຫຍ່ທີ່ສຸດຂອງບັນຫາທີ່ປາກົດຂຶ້ນເປັນຜົນມາຈາກການໃຊ້ພາສາ C, ເຊິ່ງຕ້ອງການການດູແລຫຼາຍໃນເວລາທີ່ເຮັດວຽກກັບຫນ່ວຍຄວາມຈໍາແລະຕົວຊີ້. ເພື່ອເຮັດໃຫ້ບັນຫາຮ້າຍແຮງກວ່າເກົ່າ, ຫຼາຍໆຈຸດແກ້ໄຂຊ່ອງໂຫວ່ທີ່ອາດບໍ່ຖືກສະໜອງໃຫ້ກັບຕົວລະບຸ CVE, ຫຼືຖືກມອບໝາຍຕົວລະບຸ CVE ບາງຄັ້ງຫຼັງຈາກ patch ໄດ້ຖືກເຜີຍແຜ່. ໃນສະພາບແວດລ້ອມດັ່ງກ່າວ, ມັນເປັນການຍາກຫຼາຍສໍາລັບຜູ້ຜະລິດທີ່ຈະແຍກການແກ້ໄຂເລັກນ້ອຍອອກຈາກບັນຫາຄວາມປອດໄພທີ່ສໍາຄັນ. ອີງຕາມສະຖິຕິ, ຫຼາຍກວ່າ 40% ຂອງຊ່ອງໂຫວ່ໄດ້ຖືກແກ້ໄຂກ່ອນທີ່ CVE ຈະຖືກມອບຫມາຍ, ແລະໂດຍສະເລ່ຍຄວາມລ່າຊ້າລະຫວ່າງການປ່ອຍການແກ້ໄຂແລະການມອບຫມາຍ CVE ແມ່ນສາມເດືອນ (i.e., ໃນຕອນທໍາອິດການແກ້ໄຂແມ່ນຮັບຮູ້ວ່າເປັນ. bug ປົກກະຕິ, ແຕ່ວ່າພຽງແຕ່ຫຼັງຈາກຫຼາຍເດືອນມັນຈະກາຍເປັນທີ່ຊັດເຈນວ່າຊ່ອງໂຫວ່ໄດ້ຖືກແກ້ໄຂ).

ດັ່ງນັ້ນ, ໂດຍບໍ່ມີສາຂາແຍກຕ່າງຫາກທີ່ມີການແກ້ໄຂຄວາມອ່ອນແອແລະບໍ່ໄດ້ຮັບຂໍ້ມູນກ່ຽວກັບການເຊື່ອມຕໍ່ຄວາມປອດໄພຂອງບັນຫາສະເພາະໃດຫນຶ່ງ, ຜູ້ຜະລິດຜະລິດຕະພັນໂດຍອີງໃສ່ Linux kernel ຖືກປະໄວ້ຢ່າງຕໍ່ເນື່ອງເພື່ອໂອນການແກ້ໄຂທັງຫມົດຈາກສາຂາທີ່ຫມັ້ນຄົງຫລ້າສຸດ. ແຕ່ການເຮັດວຽກນີ້ຮຽກຮ້ອງໃຫ້ມີແຮງງານຫຼາຍແລະປະເຊີນກັບການຕໍ່ຕ້ານໃນບໍລິສັດຍ້ອນຄວາມຢ້ານກົວຂອງການເກີດໃຫມ່ຂອງການປ່ຽນແປງ regressive ທີ່ສາມາດລົບກວນການດໍາເນີນງານປົກກະຕິຂອງຜະລິດຕະພັນ.

ໃຫ້ພວກເຮົາຈື່ໄວ້ວ່າອີງຕາມ Linus Torvalds, ຄວາມຜິດພາດທັງຫມົດແມ່ນສໍາຄັນແລະຈຸດອ່ອນບໍ່ຄວນຖືກແຍກອອກຈາກປະເພດຄວາມຜິດພາດອື່ນໆແລະຈັດສັນເປັນປະເພດບູລິມະສິດທີ່ສູງກວ່າແຍກຕ່າງຫາກ. ຄວາມຄິດເຫັນນີ້ໄດ້ຖືກອະທິບາຍໂດຍຄວາມຈິງທີ່ວ່າສໍາລັບນັກພັດທະນາທົ່ວໄປທີ່ບໍ່ຊ່ຽວຊານໃນບັນຫາຄວາມປອດໄພ, ການເຊື່ອມຕໍ່ລະຫວ່າງການແກ້ໄຂແລະຊ່ອງໂຫວ່ທີ່ອາດຈະເກີດຂຶ້ນແມ່ນບໍ່ຊັດເຈນ (ສໍາລັບການແກ້ໄຂຈໍານວນຫຼາຍ, ພຽງແຕ່ການກວດສອບແຍກຕ່າງຫາກເຮັດໃຫ້ມັນເປັນໄປໄດ້ທີ່ຈະເຂົ້າໃຈວ່າພວກເຂົາກ່ຽວຂ້ອງກັບຄວາມປອດໄພ. ). ອີງຕາມ Linus, ຜູ້ຊ່ຽວຊານດ້ານຄວາມປອດໄພຈາກທີມງານທີ່ຮັບຜິດຊອບໃນການຮັກສາແພັກເກັດ kernel ໃນການແຈກຢາຍ Linux ຄວນມີສ່ວນຮ່ວມໃນການກໍານົດຈຸດອ່ອນທີ່ອາດຈະເກີດຂື້ນຈາກກະແສທົ່ວໄປຂອງ patches.

Kees Cook ເຊື່ອວ່າທາງອອກດຽວໃນການຮັກສາຄວາມປອດໄພຂອງແກ່ນໃນຄ່າໃຊ້ຈ່າຍໃນໄລຍະຍາວທີ່ສົມເຫດສົມຜົນແມ່ນສໍາລັບບໍລິສັດທີ່ຈະຍ້າຍວິສະວະກອນທີ່ມີສ່ວນຮ່ວມໃນການແກ້ໄຂການແກ້ໄຂກັບແກ່ນທ້ອງຖິ່ນເພື່ອສ້າງຮ່ວມກັນ, ຄວາມພະຍາຍາມປະສານງານເພື່ອຮັກສາການແກ້ໄຂແລະຈຸດອ່ອນໃນແກ່ນຕົ້ນຕໍ (ຕົ້ນນ້ໍາ. ). ໃນຮູບແບບປະຈຸບັນ, ຜູ້ຜະລິດຈໍານວນຫຼາຍບໍ່ໃຊ້ kernel ຮຸ່ນຫຼ້າສຸດໃນຜະລິດຕະພັນຂອງພວກເຂົາແລະ backport ການແກ້ໄຂພາຍໃນ, i.e. ມັນປະກົດວ່າວິສະວະກອນໃນບໍລິສັດທີ່ແຕກຕ່າງກັນເຮັດຊ້ໍາການເຮັດວຽກຂອງກັນແລະກັນ, ແກ້ໄຂບັນຫາດຽວກັນ.

ສໍາລັບຕົວຢ່າງ, ຖ້າຫາກວ່າບໍລິສັດ 10, ແຕ່ລະຄົນມີວິສະວະກອນຫນຶ່ງ backporting ການແກ້ໄຂດຽວກັນ, reassigned ວິສະວະກອນເຫຼົ່ານັ້ນເພື່ອແກ້ໄຂຂໍ້ບົກພ່ອງໃນຕົ້ນນ້ໍາ, ຫຼັງຈາກນັ້ນແທນທີ່ຈະ backporting ຫນຶ່ງການແກ້ໄຂ, ພວກເຂົາເຈົ້າສາມາດແກ້ໄຂ 10 ແມງໄມ້ທີ່ແຕກຕ່າງກັນສໍາລັບຜົນປະໂຫຍດທົ່ວໄປຫຼືເຂົ້າຮ່ວມໃນການທົບທວນຄືນສະເຫນີ. ປ່ຽນແປງແລະປ້ອງກັນລະຫັດ buggy ຈາກການຖືກລວມເຂົ້າໃນ kernel. ຊັບພະຍາກອນຍັງສາມາດຖືກອຸທິດໃຫ້ກັບການສ້າງເຄື່ອງມືໃຫມ່ສໍາລັບການທົດສອບແລະການວິເຄາະລະຫັດທີ່ຈະຊ່ວຍໃຫ້ມີການກວດສອບຄວາມຜິດພາດທົ່ວໄປທີ່ເກີດຂື້ນເລື້ອຍໆແລະອີກເທື່ອຫນຶ່ງ.

Kees Cook ຍັງແນະນໍາຢ່າງຫ້າວຫັນໃນການນໍາໃຊ້ການທົດສອບອັດຕະໂນມັດແລະ fuzzing ໂດຍກົງໃນຂະບວນການພັດທະນາ kernel, ການນໍາໃຊ້ລະບົບການເຊື່ອມໂຍງຢ່າງຕໍ່ເນື່ອງແລະການປະຖິ້ມການຄຸ້ມຄອງການພັດທະນາແບບເກົ່າແກ່ຜ່ານທາງອີເມວ. ໃນປັດຈຸບັນ, ການທົດສອບປະສິດທິພາບແມ່ນຂັດຂວາງໂດຍຄວາມຈິງທີ່ວ່າຂະບວນການທົດສອບຕົ້ນຕໍແມ່ນແຍກອອກຈາກການພັດທະນາແລະເກີດຂື້ນຫຼັງຈາກການປ່ອຍອອກມາ. Keys ຍັງແນະນໍາໃຫ້ໃຊ້ພາສາທີ່ສະຫນອງລະດັບຄວາມປອດໄພສູງກວ່າເຊັ່ນ Rust, ເມື່ອພັດທະນາເພື່ອຫຼຸດຜ່ອນຈໍານວນຂໍ້ຜິດພາດ.

ແຫຼ່ງຂໍ້ມູນ: opennet.ru