计算机安全的重要性一、计算机安全的概念对于计算机安全，国际标准化委员会的定义是“为 数据处理系统和采取的技术的和管理的安全保护，保护计算机硬件、 软件、数据不因偶然的或恶意的原因而遭到破坏、更改、显露。我国公安部计算机管理监察司的定义是是指计算机资产安全，即 计算机信息系统资源和信息资源不受自然和人为有害因素的威胁和危害。二、我们在日常生活和工作中遇到的计算机安全威胁计算机容易受到许多威胁从而造成各种各样损害导致严重损失。这些损害从由于错误而破坏数据库的安全性到火灾摧毁整个计算机中心。损害的原因是多种多样的，例如，看上去可信的员工欺骗系统的行为、外部黑客或粗心的数据录入员。由于很多损害永远也无法被发现，有些机构为了避免公众形象受损所以对损害情况加以掩盖，所以准确的评估计算机安全相关的损害是不可能的。不同的威胁其后果也有所不同：一些是影响数据的机密性或完整性而另一些则影响系统的可用性。这些威胁包括：1.错误 和遗漏 2 .欺诈和盗窃3. 员工破坏 4.丧失物理和基础设施的支持5.网络安全攻击6.有害代码7.对个人隐私的威胁这里描述了如今系统运行环境中风险的基本情况。所提到的威 胁和相关损害是基于其在当今计算环境中的普遍程度和严重程度以及其预期扩展形势而提出的。

本清单并不详尽，有些威胁可以是不同领域的组合产物。这里描述的当前常见威胁概况可以为机构研究其自身的威胁环境提供帮助；但是由于这一话题涉及面比较广阔，所以特定系统所遭遇的威胁可能与这里讨论的有所不同 。为了控制运行信息系统的风险，管理人和用 户需要了解系统的缺陷和可能利用缺陷的威胁。对威胁环境的了解使系统管理人得以实施最具成本效益的安全措施。在有些情况下，管理人发现简单容忍预期损害更具有成本效益。这一决策应该基于风险分析的结果。1、错误和遗漏错误和遗漏是数据和系统完整性的重要威 胁。这些错误不仅由每天处理几百条交易的数据录入员造成，创建和编辑数据的任何类型的用户都可以造成。许多程序，特别是那些被设计用来供个人计算机用户使用的程序缺乏质量控制手段。但是，即使是最复杂的程序也不可能探测到所有类型的输入错误或遗漏。良好的意识和培训项目可以帮助机构减少错误和遗漏的数量和严重程度。 用户、数据录入员、系 统操作员和程序员的工作中经常会出现直接或间接影响安全的错误。在有些情况下，错误是一种威胁，例如数据录入错误或编程错误会使系统崩溃。在另一些情况下，错误导致了缺陷。错误可以在系统生命周期的任何阶段发生。

一项由计算机安全顾问、计算机系统安全和隐私咨询委员会的前成员 Robert 进行的关于计算机的经济损失的长期调查显示，机构百分之六十五的损失是错误和遗漏造成的。在私营和公共机构中，这种情况基本是一样的。编程和开发的错误通常被称为“臭虫”，其 严重程度从温和到灾难性不等。在 1989 年美国众议院科学、空间和技术委员会的研究报告《程序中的缺陷》中，调查和监督小组委员会成员对政府系统中此类问题的严重性作出了以下总结： 随着费用的不断增加，对于越来越大、越来越复杂的软件系统的稳定性、成本和准确性的关注也越来越多。随着计算机执行越来越关键的任务，其错误会导致经济混乱、事故，在极端的情况下会导致死亡，所以对此的关注也不断升温。自从这份研究报告发表以来，软件工业发 生了相当大的变化，软件质量有了可观的改善。但是关于软件的“恐怖故事“ 依然大量流传，报告中分析发现的基本根源和问题依然存在。虽然程序的质量有了很大的改善，减少了每 1000 行代码中包含的错误量，但是程序的规模同时也在扩大，这在很大程度上抵消了程序质量改进的好处。安装和维护的错误是安全问题的另一个根源。例如，由美国正直和效率总统委员会（PCIE）在 1988 年进行的审计中发现，被调查的每十个大型计算机站点中就有一个存在会导致严重安全缺陷的安装和维护错误。

2、欺诈和盗窃计算机系统会受到欺诈和盗窃的伤害，这种伤害可以是通过“自动化“了的传统手段进行也可以是通过新的手段进行。例如，有人可能会使用计算机在大型帐户中稍微减少一小部分数量的金钱，期望这个微小的差异不会被调查。金融系统不是这种风险的唯一受害者。控制资源访问的系统（如时间和考勤系统、存货系统、学籍系统以及长途电话系统）都可能成为受害者。计算机欺诈和盗窃可以是内部人所为也可以是外部人所为。欺诈主要是内部人（如系统的受权用户）所为。1993 年《信息周刊》／Ernst＆Young 公司研究发现百分之九十的首席信息官将“知道过多” 信息的员工视为一种威胁 。美国司法部计算机犯罪调查部门指出“内部人构成了计算机系统的最大威胁” 。因为内部人既可以访问受害的计算机系统（包括其控制和流动的资源）又对系统比较熟悉，受权用户在进行计算机犯罪时处于有利的地位。内部人可以是普通用户（如职员）也可以是技术人员。了解机构运行情况的机构的前员工也可能是一种威胁，在其访问权限没有得到适当终止的时侯尤其如此。另外， 对 于使用技 术手段进行欺诈和盗窃，计算机硬件、和软件都容易被窃取。例如，由 保险公司进行的一 项研究发现，在 1992 年中由于盗窃损失的计算机的价值高达 8 亿 8 千 2 百万美金。

3、员工破坏员工最熟悉其雇主的计算机和应用，包括知道何种行 为会导致最大的损害、故障或破坏。公共和私营机构中人员的不断缩减造成有一些人对整个机构都很熟悉，这些人可能会保留潜在的系统访问权（如系统帐户没有被及时删除） 。从数量上看，员工破坏事件比盗窃事件要少，但是这种事件造成的损失却很高。《美国工作场所的破坏》的作者 Martin Sprouse 报告说，破坏的动机从利他主义到报复不等：当员工在工作中感到受了欺骗、厌烦、疲倦、受到威胁或背叛的时侯，破坏将被当做获得工作满足感的直接手段，这种手段老板当然是不会同意的 。4 丧失物理和基础设施的支持丧 失基础设施的支持包括电力故障（中断、瞬间高压和电压不足）、丧失通信能力、水的中断和泄漏、下水管道问题、缺乏运输服务、火灾、洪水、国内混乱和罢工。这些损害包括如美国世贸中心爆炸和芝加哥隧道洪水这样的激烈事件，也包括像水管破裂这样的普通事件。基础设施的丧失通常导致系统停机，有时结果是在无法预料的。例如，在暴风雪的天气下员工无法上班，而计算机系统依然在工作。5、网络安全攻击（1）即时通信软件的安全性QQ,MSN 等都是这个被关注的软件；现象，号码被盗，欺 骗熟人， 骗钱；建议：密码弄的安全点，不要相信网上的人的借钱，即便认识，打款前先电话确认下；或者开通声频功能；或者直接说我也没钱（只要一说钱，就敏感点，先当骗子再说）（2）病毒，木马软件的安全性；现象：计算机速度慢，建议：不要随便打开网络上不认识或不熟悉的人发的图片，可执行文件等；保持经常杀病毒，木马；同时自己的文件做好备份，和操作系统分开放；比如操作系统 C 盘， 其他文件放 D 盘；免的万一要重新装系统，机器不行了，很麻烦。（3）网上银行的安全性一般开通好后网络银行，可以支持网上银行的转账功能，但可能会有不熟悉操作的人，被不熟悉的人不怀好意的教导下导致不好后果；建议：要么不开通网络银行功能，要开通的话，银行的 USB KEY 是最好的，动态口令次一点；U

NET的前景 关于准备运行的对话

准备运行（R2R）是.NET的本机可执行代码格式。R2R代码是使用工具生成的。

我们再次使用对话格式，这次是与三位准备运行代码生成工作的工程师一起使用。

扬·科塔斯（Jan Kotas）

扬·沃里切克（JanVorlíček）

托马斯·里勒克

准备运行解决了什么问题。没有它，我们会有什么问题？

Tomas：现在，我认为这主要是没有版本脆弱性的启动性能。从长远来看，我希望我们也能以更激进的方式争取运行时性能。

Tomas：换句话说，我们利用编译器产生的本机代码缓存来减轻繁重的JIT启动阶段的负担。尽管版本弹性约束有时会迫使我们生成次优的代码，所以可以预期的是，启动后重新编码代码以获得更好的稳态性能。

Jan K：R2R是AOT编译的.NET代码的二进制格式。没有它，我们就不会有.NET的AOT。因为我们知道大多数.NET运行时形状因子至少需要某种形式的AOT，所以这种方法不能很好地工作。在典型的.NET应用程序中，太多的代码无法进行JIT或全部解释。

托马斯：事实上，我之前曾回顾过其中一些问题和西蒙的答案，我认为可能需要进一步澄清的一件事是R2R和完整的本地AOT之间的关系，在我看来，西蒙的回答触及了这一点，也许我们可以更加发光点亮。

名字叫什么 为什么将这种格式称为“准备运行”？

Jan V：这意味着该代码可立即运行而无需加急。

Tomas：我相信这暗示了版本的弹性-顾名思义，代码应该“在任何地方运行”。

Tomas：也许也是如此，但是即使不满足版本限制，它仍然可以运行，即使它会丢弃R2R映像并仅使用运行时JIT。

Jan K：我们需要一个文件格式的名称，“ Ready to Run”听起来很不错。万斯·莫里森（Vance ）想到了这个名字。它很好地描述了文件格式背后的想法：可以立即运行的东西。

托马斯：但是我想JanK最接近这个名字的诞生，所以他可能最清楚它的初衷是什么。

格式的优点是什么？

Tomas：版本弹性与本机代码相结合，可提供更好的性能，与NGEN或纯JIT等以前的技术相比，这是一个至关重要的区别。

Tomas：这是更多技术细节，但是与NGEN相比，该格式的设计也更加简洁。

Jan V：我要说的是，版本弹性和通过版本控制的将来可扩展性是重要的优势。

Tomas：它也非常灵活，因此它在部分编译与完全编译，可扩展性，将来的选项（包括支持各种处理器扩展的多个版本的编译功能）方面支持广泛的选项。

Tomas：除其他外，它具有足够的灵活性以支持将来切换到OS本地可执行映像。

Jan K：文件格式的主要特征是版本弹性。这意味着以兼容方式更新依赖项不会使AOT编译代码无效。在编写和维护应用程序时，它的行为类似于IL（ECMA-335）文件格式，非常灵活且易于理解。早期版本的.NET AOT文件格式（例如.NET 上的NGen使用的文件格式）没有此属性。

格式的弱点是什么？

托马斯：嗯，我们尝试不断修复发现的问题。将其嵌入图像以进行单输入编译的当前方法的一个缺点是，它基本上挂在MSIL标头上。这就是我们为合成图像更改的功能，以将这两个图像解耦。

Tomas：目前尚不支持针对各种扩展指令集进行了优化的单个函数的变体编译，但添加起来并不难。

Jan V：基于Windows exec文件格式的事实。过去我们也讨论过支持unix本机格式（ELF，mach-o）的问题。

Jan K：版本弹性带来了性能上的损失，例如由于有限的内联而导致的性能下降。这意味着R2R编译的代码通常比JIT编译的代码运行慢一些。

Tomas：版本弹性概念和不匹配时自动切换到运行时JIT也意味着给定的R2R应用程序可以静默地体验性能下降，这对于最终用户而言可能很难理解。

准备运行和IL之间可观察到的区别是什么？

1月V：R2R的启动性能更好，文件大小更大，因为它除了IL之外还包含本机代码。

Tomas：对于单文件编译，理论上唯一可观察的方面应该是perf。如果有人弄乱了相关的程序集版本，则大型气泡R2R映像可能会在运行时迅速崩溃，并很快失败。

Tomas：当然还有JanV所说的更大的尺寸。

1月V：此外，R2R文件当前是特定于目标体系结构的。

Jan K：准备运行的文件格式可以包括一些可选部分。这些部分之一可以是IL。准备运行的文件文件通常是IL，其中添加了额外的内容。

对于不熟悉代码生成的人，您可以将准备好运行的代码与最佳代码进行比较吗？像已编译的C ++代码相对于现成的代码如何工作？

Tomas：我认为这是两个正交的问题，一个是将“ R2R弹性JIT”与“运行时JIT”进行比较，另一个是“托管与本机源代码编译质量”。前者在某种程度上更容易回答，因为后者将需要深入研究运行时，类型系统和内存管理方面的差异。

Tomas：对于“ R2R弹性JIT”与“运行时JIT”，我认为我们已经涉及到了这一差异的许多方面–无法跨版本控制边界内联或使用固定的字段偏移量，无法针对具体版本进行优化可能支持各种指令集扩展的CPU。

Jan V：由于版本具有弹性，因此存在固有的性能损失，如Jan K在对弱点的评论中所说，例如，使用程序集中超出版本泡沫之外的数据类型时。

Jan V：与最佳的编译的C ++代码相比，还有一个好处–能够使用JIT在运行时改进生成的代码，例如，通过优化特定的CPU体系结构或内联来自其他程序集的代码，这些代码在Java上是未知的编译时间。

托马斯：这也是事实–总的来说，我不愿意太过“将C＃与C ++进行比较”，因为我相信必须已经进行了100万次这样的比较。但是，如果需要的话，可能值得进行一次新的会议或类似于此会议的聊天。

Jan K：版本弹性R2R代码必须在许多地方使用额外的间接寻址。例如，假设字段在准备运行代码的版本中具有固定的偏移量是不安全的，并且必须在运行时通过间接获取该偏移量。C ++不会尝试处理版本弹性。字段偏移量在C ++编译程序中是固定的偏移量。

Jan K： C是一个非常接近准备运行的示例。是作为版本弹性系统构建的，而版本弹性R2R代码和 C代码使用的模式非常相似。例如，已编译的 C代码中的字段访问需要一个额外的间接访问，这与R2R代码中的非常相似。

Jan K：顺便说一句：目标C版本的弹性可以使Apple操作系统中的大部分API公开为目标C。

Tomas：我想我们可以将讨论分为类型系统/类形状，GC与本机内存分配，泛型与模板，托管代码花生酱，多重继承与接口分派等模块。

R2R与完整的AOT（与本机AOT项目中存在的）相比如何？类似的答案？

Tomas：如前所述，R2R格式非常灵活，并且支持从完全JIT到完全AOT的一系列产品。当前，R2R当然不是完整的AOT，也不是完整的AOT，这总是受到缺少JIT（例如，.Emit或编译正则表达式）的限制。

Tomas：我可能应该说，目前的 / 并不是完整的AOT，原则上不是R2R格式。

Jan K：我们想说的是，通用.NET运行时和都使用相同的AOT代码核心文件格式，只是它们添加的可选部分有所不同。我们还没到那儿。

结束语

准备运行以及与之相关的技术是.NET运行时工程师致力于使您的应用程序正常运行的主题的很好的例子。从答案中可以看出，至少在表面上，交付最快的代码和可版本性是矛盾的。团队一直在寻找机会来满足这两种需求，包括提供新的可选复合模式，该模式会禁用版本性。这对于诸如容器之类的因构造而无法改变的场景非常有用。

再次感谢Tomas，Jan和Jan在准备运行时分享了您的见解和背景。这是一次很棒的对话。

出处：微软博客

翻译：google协助翻译