W^X ( write xor executeหรืออ่านว่า ดับเบิลยูเอ็กซ์ )เป็นนโยบายความปลอดภัยในระบบปฏิบัติการและเฟรมเวิร์กซอฟต์แวร์มันใช้ในการป้องกันพื้นที่ที่สามารถเรียกใช้งานได้โดยทำให้มั่นใจว่าทุกหน้าหน่วยความจำ (บล็อกขนาดคงที่ใน พื้นที่แอดเดรสเสมือนของโปรแกรมซึ่งเป็นโครงสร้างหน่วยความจำที่โปรแกรมใช้) สามารถเขียนได้หรือเรียกใช้งานได้แต่ไม่ใช่ทั้งสองอย่างพร้อมกัน หากไม่มีการป้องกันดังกล่าว โปรแกรมสามารถเขียน (ในรูปข้อมูล "W") คำสั่งของ CPU ในพื้นที่หน่วยความจำที่ตั้งใจไว้สำหรับข้อมูล แล้วเรียกใช้ (ในรูปที่สามารถเรียกใช้งานได้ "X" หรืออ่านและเรียกใช้งานได้ "RX") คำสั่งเหล่านั้น ซึ่งอาจเป็นอันตรายได้หากผู้เขียนหน่วยความจำนั้นมีเจตนาร้าย

คำศัพท์นี้ได้รับการแนะนำครั้งแรกในปี 2546 สำหรับ ระบบ ที่คล้าย Unixแต่ปัจจุบันระบบหลายแพลตฟอร์มบางระบบก็ใช้เช่นกัน (เช่น.NET ^{[ 1 ]} ) ระบบปฏิบัติการอื่นๆ ได้นำนโยบายที่คล้ายกันมาใช้ภายใต้ชื่อที่แตกต่างกัน (เช่นDEPใน Windows)

ในเคอร์เนลของระบบปฏิบัติการที่คล้าย Unix เช่นเคอร์เนล LinuxหรือXNUหรือเคอร์เนลที่ใช้เป็นส่วนประกอบในระบบปฏิบัติการขนาดใหญ่ เช่นFreeBSD , OpenBSD , SolarisและUNIX System ServicesของZ/OSนั้น W^X ถูกควบคุมผ่านการ เรียกใช้ระบบ mprotectซึ่งค่อนข้างง่ายในสถาปัตยกรรมโปรเซสเซอร์ ที่รองรับสิทธิ์การ เข้าถึง หน้าหน่วยความจำแบบละเอียด เช่นSPARC , x86-64 , PA-RISC , AlphaและARM

คำว่า W^X ยังถูกนำไปใช้กับสิทธิ์การเขียน/เรียกใช้งานของระบบไฟล์เพื่อลดช่องโหว่ในการเขียนไฟล์ (เช่นเดียวกับในหน่วยความจำ) และการคงอยู่ของผู้โจมตี^{[ 2 ]}การบังคับใช้ข้อจำกัดเกี่ยวกับสิทธิ์ของไฟล์ยังสามารถปิดช่องว่างในการบังคับใช้ W^X ที่เกิดจากไฟล์ที่แมปหน่วยความจำได้^{[ 3 ] [ 4 ]}การห้ามใช้โค้ดเนทีฟโดยเด็ดขาดยังสามารถลดช่องโหว่ของเคอร์เนลและซีพียูที่ไม่เปิดเผยผ่านโค้ดที่มีอยู่บนคอมพิวเตอร์ได้^{[ 5 ]}แนวทางที่รบกวนน้อยกว่าคือการล็อกไฟล์ในช่วงเวลาของการแมปใดๆ ลงในหน่วยความจำที่สามารถเรียกใช้งานได้ ซึ่งเพียงพอที่จะป้องกันการหลีกเลี่ยงหลังการตรวจสอบ

โปรเซสเซอร์Intel 64รุ่นแรกๆ บางรุ่น ขาด บิต NXที่จำเป็นสำหรับ W^X แต่บิตนี้ปรากฏในชิปรุ่นหลังๆ สำหรับโปรเซสเซอร์ที่มีข้อจำกัดมากกว่า เช่นIntel i386นั้น W^X จำเป็นต้องใช้ ขีดจำกัด ของส่วนโค้ด CS เป็น " เส้นแบ่ง " ซึ่งเป็นจุดในพื้นที่แอดเดรสที่สูงกว่านั้นไม่อนุญาตให้ดำเนินการและจะวางข้อมูลไว้ที่นั่น และต่ำกว่านั้นจะอนุญาตให้ดำเนินการและวางเพจที่สามารถเรียกใช้งานได้ แผนการนี้ถูกใช้ในExec Shield ^{[ 6 ]}

โดยทั่วไปจำเป็นต้องมีการเปลี่ยนแปลง ตัวเชื่อมโยงเพื่อแยกข้อมูลออกจากโค้ด (เช่นแทรมโพลีนที่จำเป็นสำหรับ ฟังก์ชัน รันไทม์ ของตัวเชื่อมโยงและ ไลบรารี ) โดยปกติแล้วสวิตช์ที่อนุญาตให้ผสมจะถูกเรียกใช้ในระบบที่คล้าย Unix ^{[ 7 ]}execstack

W^X ยังอาจก่อให้เกิดปัญหาเล็กน้อยสำหรับการคอมไพล์แบบ just-in-timeซึ่งเกี่ยวข้องกับตัวแปลภาษาที่สร้างรหัสเครื่องแบบทันทีทันใดแล้วจึงเรียกใช้ วิธีแก้ปัญหาที่ง่ายที่สุดที่ใช้กันส่วนใหญ่ รวมถึงFirefox ในอดีต คือการทำให้เพจสามารถเรียกใช้งานได้หลังจากที่ตัวแปลภาษาเขียนรหัสเครื่องเสร็จแล้ว โดยใช้VirtualProtectบน Windows หรือmprotectระบบปฏิบัติการที่คล้าย Unix วิธีแก้ปัญหาอีกวิธีหนึ่งคือการแมปพื้นที่หน่วยความจำเดียวกันไปยังสองเพจ เพจหนึ่งมีสิทธิ์อ่านและเขียน (RW) และอีกเพจหนึ่งมีสิทธิ์อ่านและเขียน (RX) ^{[ 8 ]}ยังไม่มีข้อสรุปที่ชัดเจนว่าวิธีแก้ปัญหาใดปลอดภัยกว่ากัน ผู้สนับสนุนแนวทางหลังเชื่อว่าการอนุญาตให้เพจที่เคยเขียนได้สามารถเรียกใช้งานได้นั้นขัดกับจุดประสงค์ของ W^X (มี นโยบาย SELinuxเพื่อควบคุมการดำเนินการดังกล่าวเรียกว่าallow_execmod) และการสุ่มเค้าโครงพื้นที่แอดเดรสจะทำให้ปลอดภัยที่จะวางทั้งสองเพจไว้ในกระบวนการเดียวกัน ผู้สนับสนุนแนวทางแรกเชื่อว่าแนวทางหลังจะปลอดภัยก็ต่อเมื่อมอบสองเพจให้กับสองกระบวนการที่แยกจากกัน และการสื่อสารระหว่างกระบวนการจะมีค่าใช้จ่ายมากกว่าการเรียกmprotectใช้

W^X ถูกนำมาใช้ครั้งแรกในOpenBSD 3.3 ซึ่งวางจำหน่ายในเดือนพฤษภาคม 2003 ในปี 2004 ไมโครซอฟต์ได้แนะนำคุณสมบัติที่คล้ายกันนี้เรียกว่า DEP ( Data Execution Prevention ) ในWindows XP คุณสมบัติที่คล้ายกันนี้มีอยู่ในระบบปฏิบัติการอื่นๆ รวมถึง แพตช์ PaXและExec ShieldสำหรับLinuxและการใช้งาน PaX ของNetBSD ใน Red Hat Enterprise Linux (และCentOS โดยอัตโนมัติ ) เวอร์ชัน 5 หรือใน Linux Kernel 2.6.18-8 นั้นSELinuxได้รับ นโยบาย allow_execmem, allow_execheap, และallow_execmodที่ให้ W^X เมื่อถูกปิดใช้งาน

แม้ว่า W^X (หรือ DEP) จะปกป้องเฉพาะโปรแกรมผู้ใช้เป็นส่วนใหญ่ตลอดระยะเวลาที่มีอยู่ แต่ในปี 2012 ไมโครซอฟต์ได้ขยายไปสู่เคอร์เนลของ Windows บนสถาปัตยกรรม x86 และ ARM ^{[ 9 ]}ในช่วงปลายปี 2014 และต้นปี 2015 W^X ได้ถูกเพิ่มเข้าไปในเคอร์เนลของ OpenBSD บนสถาปัตยกรรม AMD64 ^{[ 10 ]}ในช่วงต้นปี 2016 W^X ได้ถูกนำไปใช้งานอย่างสมบูรณ์บนเคอร์เนล AMD64 ของ NetBSD และบางส่วนบนเคอร์เนล i386

คอมพิวเตอร์ macOSที่ใช้ โปรเซสเซอร์ Apple Siliconจะบังคับใช้ W^X กับโปรแกรมทั้งหมด ส่วน Mac ที่ใช้ Intel จะบังคับใช้นโยบายนี้เฉพาะกับโปรแกรมที่ใช้โหมด Hardened Runtime ของระบบปฏิบัติการเท่านั้น^{[ 11 ] [ 12 ]}

ตั้งแต่Firefox 46 ในปี 2016 จนถึงFirefox 116 ในปี 2023 เครื่องเสมือนของ Firefox สำหรับJavaScriptได้นำนโยบาย W^X มาใช้^{[ 8 ]}ต่อมานโยบายนี้ถูกยกเลิกในบางแพลตฟอร์มเนื่องจากเหตุผลด้านประสิทธิภาพ แต่ยังคงใช้บนแพลตฟอร์มอื่น ๆ ซึ่งบังคับใช้ W^X สำหรับทุกโปรแกรม^{[ 13 ]}

.NET ใช้ W^X ตั้งแต่ .NET 6.0 ในปี 2021 ^{[ 1 ]}

• ประกาศ OpenBSD-3.3 การเปิดตัว W^X สู่สาธารณะ
• สไลด์จากงานนำเสนอของ Theo de Raadt หัวหน้าทีมพัฒนา OpenBSD ซึ่งครอบคลุมหัวข้อ W^X