举个例子来说，你不会想去解开一个循环而产生过多的变量给JIT编译器，因此JIT编译器必须进行寄存器分配(一个NP完成的问题) 。Visual C 小组正对这些问题进行研究，并在整个系统发布时会得到一个经过妥善调整的解决方案。
 安全性
逆@风@者
在 2002 年，比尔.盖茨倡导开发高信度计算机软件精神，这对微软开发的所有产品都有着不可小视的冲击力。Windows 操作系统的开发人员花费了数月的时间在安全性培训和代码讨论上，这使Windows
Server 2003 成为公司曾经发布过的安全性最高的一个操作系统。微软 Office 2003 也包含了许多安全特性，像信息权利管理(IRM)，更好的宏安全性和在 Outlook 中的 HTML 下载屏蔽等等。而编译器小组也大踏步的将他们开发的编译器及其产生的代码变得更为安全。
Visual Studio .NET 2002 引入了一个缓冲安全性校验的/GS编译器选项。这一标志导致编译器对那些有缓冲溢出攻击嫌疑的函数返回地址之前就预先在栈上分配空间。在进入函数之后，一个带有经过计算的值的安全性 Cookie 会被放在这个缓冲区当中，而在退出函数时，编译器会检查并保证这个 Cookie 的值没有被修改。对 Cookie 值的改变就意味着函数的返回地址有覆盖其它地址的可能性，而这会生成一个错误并导致应用程序终止。
当然，这并不能防止所有的缓冲溢出攻击。Visual Studio .NET 2003又增强了/GS这一特性。它通过整理在栈上的局部变量来使数组的内存地址高于其它的局部变量的地址，来防止这些局部变量造成溢出。这样会阻止基于虚表 vtable 劫持攻击和其它基于指针的攻击。
Figure 7 原来的/GS
Visual C 2005 对这一强大的特性进行了又一次的更新。当一个函数被调用时，函数的激活记录是像 Figure 7 那样排放的。如果一个局部缓冲区发生了溢出，某个攻击性程序有可能会覆盖在其栈地址上的所有东西，包括异常处理函数记录，安全性 cookie，帧指针，返回地址，和函数的参数。所有这些值都是由各种机制来保护的(像安全异常处理函数)，然而，在一个以函数指针做为参数的函数中，要进行缓冲溢出仍有可能。如果一个函数将函数指针(或是一个包含函数指针的结构体或是类) 作为参数，攻击程序可能会覆盖这一指针的值并导致代码去执行任何他/她想要运行的函数。为了防止这一点，Visual
C 2005 会分析所有的函数参数来查找这一弱点，并将函数激活记录像 Figure 8那样排放。那些易受攻击的参数会在局部变量的栈地址下面创建副本，而去使用这些副本而不是参数本身。一旦参数本身发生缓冲溢出，它们会因为副本的使用而仍然维持原始值，这样就不会有任何的破坏力了。
Figure 8 新的/GS
与“默认为安全的”这一高信度计算导向相一致的是，Visual C 2005 编译器使缓冲安全检验选项为默认激活。这会有助于使所有以 Visual
C 编译的产品都更加安全。实际上，微软现在正在以这个激活的选项来生成它所有的产品，包括 Windows,Office 和 SQL Server。
Visual C 2005 其它的进步就是确保代码是以安全性考虑为前提生成的。绝大多数C 应用程序都是依赖于C运行库(CRT)和标准模板库（STL）的。当先对这些事情进行设计时，代码的安全性就不会被优先考虑了，而许多现在流行的攻击缺口也会被忽略。这样做的结果是，许多由这些库提供的功能大多在一个不安全的方式下被使用，使应用程序对一些潜在的攻击城门大开。最近
推出的 Michael
Howard 所写的《编制安全的代码》（微软出版社2002）书中，他强调了在一些情况下不使用这些库的重要性。
在Visual C 2005 中，微软推出了这些库的新版本，它致力于找出所有可能导致一般安全性问题的函数，并提供另外一些更为安全的版本。这一努力的长远目标是不推荐使用所有的“不安全”的版本而提倡使用一些具有相同功能且更为完善的代替版本。仅是新的 CRT 这一个运行库，就引用了超过400个新的“安全”的函数，这样会确保对所有的指针参数进行检查是否为空指针，并且所有要进行内存复制操作的函数在知道目标地址和源缓冲区之外，还要知道将会复制多少字节的数据。
本文章更多内容：<<上一页 - 1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 - 9 - 下一页>> |
您的位置：逆风者
→ VC++
→ 正文
本文章所属分类：首页
→ VC++