现有模式的一个弊端就是从信息安全角度来说，在进程的虚拟内存当中数据与指令发生混淆时，攻击者可以构造包含指令的特殊数据输入内存，并造成堆栈溢出后让计算机将其作为指令进行执行，从而威胁计算机的安全性。

假如说在CPU以外的计算机系统中，从OS内存管理机制的虚拟内存软件实现层面，也模仿哈佛架构的设计思想，设计两块完全独立的虚拟内存空间，指令虚拟内存空间和数据虚拟内存空间独立编制、独立访问，通过并行体系结构的方式由CPU从软件层面直接分别调用指令和数据（而不是同一块连接起来的虚拟内存空间中分区存放数据和指令）。具体实现方法的话，我觉得可尝试通过类似建立两张页表分别存放指令空间地址和数据空间地址对物理内存地址的对应关系等方案。

这样，如果单纯是由于程序设计未对读入空间进行限制，还是有可能出现堆栈溢出的情况，但当指令虚拟空间和数据虚拟空间完全隔离后，数据部分不管怎么溢出，也不可能溢出到指令虚拟空间去。这样是不是堆栈溢出就无法将恶意代码以数据的形式植入进程的内存空间并加以执行了，从而提升OS的信息安全特性？

———————————————————

PS：关于对高级语言动态解释特性的支持问题，如果一定要解决可以尝试这样采取折中方案：

因为进程本就分为内核进程和用户进程，而类似于动态解释型语言或脚本语言多用于用户进程，并且用户进程就算被堆栈溢出执行代码还有OS的进程访问权限控制机制兜底；内核进程的访问权限大，一旦被提权危害也更大，同时内核服务本就是多用C语言这样的静态语言实现的。

那就可以针对内核进程的虚拟内存空间进行分离，分设内核指令空间和内核数据空间，独立编址独立访问。针对用户进程还是保持单一进程虚拟内存空间，便于满足上层应用开发的动态解释需求。这样至少从内核root权限安全角度，还是能极大地改善内核进程针对溢出攻击执行代码方面的防护力的，而对于用户进程为了兼容相关高级语言特性，还是得要采取普通的用户进程权限控制和数据输入长度控制等现有手段了。

----------------------------------------------------------

PS：根据针对Return-Oriented Programming攻击的相关防护需求，我觉得这个内存分离方案可以进一步设计为不仅有数据空间和指令空间两套虚拟内存分区独立编址、独立访问，而且也必须由数据指针和指令指针两个指针分别访问各自的内存空间，一个指针对另一个内存空间的读、写、执行权限都应设置为不允许。 指令空间和数据空间各拥有各自的栈，由指令空间的栈记录调用关系。同时，函数指针也要求在指令空间记录。

其次，在数据内存空间的读取数据机制上，直接以类似数据结束符一类标识告诉读取数据的进程读取完毕，而不再使用返回函数地址进行返回；当进程通过数据指针读取数据时，指令指针停留在原执行语句处不动，等待读取数据完毕后，继续执行写一条指令。

最终的设计目标就是，数据内存空间内的内容只能是纯粹的数据，或者说进程只能将其当做纯粹的数据，而不应是类似可执行的代码或可重跳转的内存地址或什么其他的可以影响进程操作或活动的内容，以此来确保进程在执行层面的安全性。