การเปิดตัวภาษาการเขียนโปรแกรม Rust 1.74 การตรวจสอบ RustVMM เขียน Binder ใหม่ใน Rust

การเปิดตัวของภาษาการเขียนโปรแกรมสำหรับวัตถุประสงค์ทั่วไปของ Rust 1.74 ซึ่งก่อตั้งโดยโครงการ Mozilla แต่ปัจจุบันได้รับการพัฒนาภายใต้การอุปถัมภ์ขององค์กรอิสระ Rust Foundation ที่ไม่แสวงหาผลกำไร ได้รับการเผยแพร่แล้ว ภาษานี้เน้นไปที่ความปลอดภัยของหน่วยความจำและให้แนวทางเพื่อให้ได้งานที่มีความเท่าเทียมกันสูง ในขณะที่หลีกเลี่ยงการใช้ตัวรวบรวมขยะและรันไทม์ (รันไทม์จะลดลงเหลือเพียงการเริ่มต้นพื้นฐานและการบำรุงรักษาไลบรารีมาตรฐาน)

วิธีการจัดการหน่วยความจำของ Rust ช่วยนักพัฒนาจากข้อผิดพลาดเมื่อจัดการพอยน์เตอร์และป้องกันปัญหาที่เกิดขึ้นเนื่องจากการจัดการหน่วยความจำระดับต่ำ เช่น การเข้าถึงพื้นที่หน่วยความจำหลังจากปล่อยให้ว่าง การยกเลิกการอ้างอิงพอยน์เตอร์ null บัฟเฟอร์เกิน เป็นต้น เพื่อแจกจ่ายไลบรารี่ จัดเตรียมการสร้างและจัดการการอ้างอิง โครงการพัฒนาตัวจัดการแพ็คเกจสินค้า ที่เก็บ crates.io รองรับการโฮสต์ไลบรารี

ความปลอดภัยของหน่วยความจำมีให้ใน Rust ณ เวลาคอมไพล์ผ่านการตรวจสอบการอ้างอิง การติดตามความเป็นเจ้าของออบเจกต์ การติดตามอายุอ็อบเจ็กต์ (ขอบเขต) และการประเมินความถูกต้องของการเข้าถึงหน่วยความจำระหว่างการดำเนินการโค้ด สนิมยังให้การป้องกันการล้นของจำนวนเต็ม, จำเป็นต้องมีการกำหนดค่าเริ่มต้นที่จำเป็นของค่าตัวแปรก่อนใช้งาน, จัดการข้อผิดพลาดได้ดีขึ้นในไลบรารีมาตรฐาน, ใช้แนวคิดของการอ้างอิงและตัวแปรที่ไม่เปลี่ยนรูปแบบตามค่าเริ่มต้น, เสนอการพิมพ์แบบคงที่ที่แข็งแกร่งเพื่อลดข้อผิดพลาดเชิงตรรกะ

นวัตกรรมหลัก:

  • เพิ่มความสามารถในการกำหนดค่าการตรวจสอบผ้าสำลีผ่านไฟล์ Cargo.toml ด้วยรายการตัวจัดการแพ็คเกจ ในการกำหนดการตั้งค่าผ้าสำลี เช่น ระดับการตอบสนอง (ห้าม ปฏิเสธ เตือน อนุญาต) มีการเสนอส่วนใหม่ "[lints]" และ "[workspace.lints]" การเปลี่ยนแปลงที่จะนำมาพิจารณาเมื่อทำการตัดสินใจเกี่ยวกับ การสร้างใหม่ ตัวอย่างเช่น แทนที่จะระบุแฟล็ก “-F”, “-D”, “-W” และ “-A” เมื่อประกอบหรือเพิ่มแฟล็ก “#![forbid(unsafe_code)]” และ “#![deny(clippy :” คุณลักษณะของโค้ด) :enum_glob_use)]" สามารถใช้ในรายการสินค้า Cargo: [lints.rust] unsafe_code = "forbid" [lints.clippy] enum_glob_use = "deny"
  • ตัวจัดการแพ็คเกจ Crate ได้เพิ่มความสามารถในการตรวจสอบสิทธิ์เมื่อเชื่อมต่อกับที่เก็บ การแจกจ่ายขั้นพื้นฐานรวมถึงการรองรับการวางพารามิเตอร์การรับรองความถูกต้องในที่เก็บข้อมูลรับรอง Linux (ขึ้นอยู่กับ libsecret), macOS (Keychain) และ Windows (Windows Credential Manager) แต่ในตอนแรกระบบถูกสร้างขึ้นแบบแยกส่วนและช่วยให้คุณสามารถจัดระเบียบงานกับผู้ให้บริการต่างๆ สำหรับการจัดเก็บและ การสร้างโทเค็น เช่น มีการจัดเตรียมปลั๊กอินสำหรับการใช้ตัวจัดการรหัสผ่าน 1Password ที่เก็บข้อมูลอาจจำเป็นต้องมีการตรวจสอบสิทธิ์สำหรับการดำเนินการใดๆ ไม่ใช่แค่เพื่อยืนยันว่าแพ็กเกจได้รับการเผยแพร่แล้ว ~/.cargo/config.toml [รีจิสทรี] global-credential-providers = ["cargo:token", "cargo:libsecret"]
  • การสนับสนุนสำหรับการคาดการณ์ประเภทการส่งคืน (impl_trait_projections) ได้รับความเสถียร ทำให้สามารถกล่าวถึง Self และ T::Assoc ในประเภทการส่งคืน เช่น "async fn" และ "->impl Trait" struct Wrapper<'a, T>(&'a T); // ประเภทการส่งคืนแบบทึบที่กล่าวถึง `Self`: impl Wrapper<'_, ()> { async fn async_fn() -> Self { /* … */ } fn impl_trait() -> impl Iterator { /* … */ } } ลักษณะ ลักษณะ<'a> { ประเภท Assoc; fn ใหม่ () -> ตนเอง :: รอง; } } ลักษณะโดยนัย<'_> สำหรับ () { พิมพ์ Assoc = (); fn new() {} } // ประเภทการส่งคืนทึบแสงที่กล่าวถึงประเภทที่เกี่ยวข้อง: impl<'a, T: Trait<'a>> Wrapper<'a, T> { async fn mk_assoc() -> T::Assoc { /* … */ } fn a_few_assocs() -> impl Iterator { /* … */ } }
  • ส่วนใหม่ของ API ถูกย้ายไปยังหมวดหมู่ของความเสถียร ซึ่งรวมถึงวิธีการและการใช้งานลักษณะต่างๆ ที่ได้รับการทำให้เสถียร:
  • คุณลักษณะ “const” ซึ่งกำหนดความเป็นไปได้ในการใช้งานในบริบทใดๆ แทนที่จะเป็นค่าคงที่ ถูกใช้ในฟังก์ชัน:
    • หลัก::mem::transmute_copy
    • STR::is_ascii
    • [u8]::is_ascii
    • core::num::กำลังอิ่มตัว
    • บอกเป็นนัยจากสำหรับ std::process::Stdio
    • บอกเป็นนัยจากสำหรับ std::process::Stdio
    • โดยนัยจากสำหรับ std::process::Child {Stdin, Stdout, Stderr}
    • โดยนัยจากสำหรับ std::process::Child {Stdin, Stdout, Stderr}
    • มาตรฐาน::ffi::OsString::from_encoded_bytes_unchecked
    • มาตรฐาน::ffi::OsString::into_encoded_bytes
    • มาตรฐาน::ffi::OsStr::from_encoded_bytes_unchecked
    • มาตรฐาน::ffi::OsStr::as_encoded_bytes
    • std::io::ข้อผิดพลาด::other
    • บอกเป็นนัยว่า TryFrom สำหรับคุณอายุ 16 ปี
    • นัย จาก<&[T; N]>สำหรับเวค
    • นัย จาก<&mut [T; N]>สำหรับเวค
    • นัย จาก<[T; N]> สำหรับส่วนโค้ง<[T]>
    • นัย จาก<[T; N]> สำหรับ RC<[T]>
  • คอมไพเลอร์ ชุดเครื่องมือ ไลบรารีมาตรฐาน และโปรแกรมปฏิบัติการของแอปพลิเคชันที่สร้างขึ้นได้เพิ่มข้อกำหนดสำหรับแพลตฟอร์ม Apple ซึ่งขณะนี้ต้องใช้ macOS 10.12 Sierra, iOS 10 และ tvOS 10 เป็นอย่างน้อยจึงจะทำงานได้
  • การสนับสนุนระดับที่สามได้ถูกนำมาใช้สำหรับแพลตฟอร์ม i686-pc-windows-gnullvm ระดับที่สามเกี่ยวข้องกับการสนับสนุนขั้นพื้นฐาน แต่ไม่มีการทดสอบอัตโนมัติ การเผยแพร่บิลด์อย่างเป็นทางการ หรือการตรวจสอบว่าสามารถสร้างโค้ดได้หรือไม่
  • การสนับสนุนระดับที่สองสำหรับแพลตฟอร์มเป้าหมาย loongarch64-unknown-none ได้ถูกนำมาใช้แล้ว การสนับสนุนระดับที่สองเกี่ยวข้องกับการรับประกันการประกอบ

นอกจากนี้ ยังมีสองเหตุการณ์ที่เกี่ยวข้องกับภาษา Rust อีกด้วย:

  • OSTIF (กองทุนปรับปรุงเทคโนโลยีโอเพ่นซอร์ส) ซึ่งสร้างขึ้นเพื่อเสริมสร้างความปลอดภัยของโครงการโอเพ่นซอร์ส ได้เผยแพร่ผลการตรวจสอบโครงการ RustVMM ซึ่งมีส่วนประกอบสำหรับการสร้างไฮเปอร์ไวเซอร์เฉพาะงานและจอภาพเครื่องเสมือน (VMM) บริษัทต่างๆ เช่น Intel, Alibaba, Amazon, Google, Linaro และ Red Hat เข้าร่วมในการพัฒนาโครงการนี้ Intel Cloud Hypervisor และ Dragonball ไฮเปอร์ไวเซอร์กำลังได้รับการพัฒนาโดยใช้ RustVMM การตรวจสอบยืนยันคุณภาพสูงของฐานโค้ดและการใช้เทคนิคในสถาปัตยกรรมและการใช้งานที่มุ่งให้เกิดความปลอดภัยสูงสุด ในระหว่างการตรวจสอบ พบปัญหา 6 ประการที่ไม่ส่งผลกระทบโดยตรงต่อความปลอดภัย
  • Google นำเสนอการใช้งานกลไกการสื่อสารระหว่างกระบวนการ Binder ใหม่ ซึ่งเขียนใหม่ในภาษา Rust ไปยังรายชื่อผู้รับจดหมายของนักพัฒนาเคอร์เนล Linux การปรับปรุงใหม่ดำเนินการโดยเป็นส่วนหนึ่งของโครงการเพื่อเสริมสร้างความปลอดภัย ส่งเสริมเทคนิคการเขียนโปรแกรมที่ปลอดภัย และเพิ่มประสิทธิภาพในการระบุปัญหาเมื่อทำงานกับหน่วยความจำใน Android (ประมาณ 70% ของช่องโหว่ที่เป็นอันตรายทั้งหมดที่ระบุใน Android เกิดจากข้อผิดพลาดเมื่อทำงานกับหน่วยความจำ ). การใช้งาน Binder ใน Rust ได้รับความเท่าเทียมกันในการทำงานกับเวอร์ชันดั้งเดิมในภาษา C ผ่านการทดสอบ AOSP (โครงการโอเพ่นซอร์ส Android) ทั้งหมด และสามารถใช้เพื่อสร้างเฟิร์มแวร์รุ่นที่ใช้งานได้ ประสิทธิภาพของการใช้งานทั้งสองอยู่ในระดับใกล้เคียงกัน (ส่วนเบี่ยงเบนภายใน -1.96% และ +1.38%)

ที่มา: opennet.ru

เพิ่มความคิดเห็น