标签 CPU 下的文章

上篇文章中 我说了操作系统行为的基本原理是,在任何一个给定的时刻,在一个 CPU 上有且只有一个任务是活动的。但是,如果 CPU 无事可做的时候,又会是什么样的呢?

事实证明,这种情况是非常普遍的,对于绝大多数的个人电脑来说,这确实是一种常态:大量的睡眠进程,它们都在等待某种情况下被唤醒,差不多在 100% 的 CPU 时间中,都处于虚构的“空闲任务”中。事实上,如果一个普通用户的 CPU 处于持续的繁忙中,它可能意味着有一个错误、bug、或者运行了恶意软件。

因为我们不能违反我们的原理,一些任务需要在一个 CPU 上激活。首先是因为,这是一个良好的设计:持续很长时间去遍历内核,检查是否一个活动任务,这种特殊情况是不明智的做法。最好的设计是没有任何例外的情况。无论何时,你写一个 if 语句,Nyan Cat 就会喵喵喵。其次,我们需要使用空闲的 CPU 去做一些事情,让它们充满活力,你懂得,就是创建天网计划呗。

因此,保持这种设计的连续性,并领先于那些邪恶计划一步,操作系统开发者创建了一个空闲任务,当没有其它任务可做时就调度它去运行。我们可以在 Linux 的 引导过程 中看到,这个空闲任务就是进程 0,它是由计算机打开电源时运行的第一个指令直接派生出来的。它在 rest\_init 中初始化,在 init\_idle\_bootup\_task 中初始化空闲 调度类 scheduling class

简而言之,Linux 支持像实时进程、普通用户进程等等的不同调度类。当选择一个进程变成活动任务时,这些类按优先级进行查询。通过这种方式,核反应堆的控制代码总是优先于 web 浏览器运行。尽管在通常情况下,这些类返回 NULL,意味着它们没有合适的任务需要去运行 —— 它们总是处于睡眠状态。但是空闲调度类,它是持续运行的,从不会失败:它总是返回空闲任务。

好吧,我们来看一下这个空闲任务到底做了些什么。下面是 cpu\_idle\_loop,感谢开源能让我们看到它的代码:

while (1) {
    while(!need_resched()) {
        cpuidle_idle_call();
    }

    /*
    [Note: Switch to a different task. We will return to this loop when the idle task is again selected to run.]
    */
    schedule_preempt_disabled();
}

cpu\_idle\_loop

我省略了很多的细节,稍后我们将去了解任务切换,但是,如果你阅读了这些源代码,你就会找到它的要点:由于这里不需要重新调度(即改变活动任务),它一直处于空闲状态。以所经历的时间来计算,这个循环和其它操作系统中它的“堂兄弟们”相比,在计算的历史上它是运行的最多的代码片段。对于 Intel 处理器来说,处于空闲状态意味着运行着一个 halt 指令:

static inline void native_halt(void)
    {
    asm volatile("hlt": : :"memory");
    }

native\_halt

hlt 指令停止处理器中的代码执行,并将它置于 halt 的状态。奇怪的是,全世界各地数以百万计的 Intel 类的 CPU 们花费大量的时间让它们处于 halt 的状态,甚至它们在通电的时候也是如此。这并不是高效、节能的做法,这促使芯片制造商们去开发处理器的深度睡眠状态,以带来着更少的功耗和更长休眠时间。内核的 cpuidle 子系统 是这些节能模式能够产生好处的原因。

现在,一旦我们告诉 CPU 去 halt(睡眠)之后,我们需要以某种方式让它醒来。如果你读过 上篇文章《你的操作系统什么时候运行?》 ,你可能会猜到中断会参与其中,而事实确实如此。中断促使 CPU 离开 halt 状态返回到激活状态。因此,将这些拼到一起,下图是当你阅读一个完全呈现的 web 网页时,你的系统主要做的事情:

除定时器中断外的其它中断也会使处理器再次发生变化。如果你再次点击一个 web 页面就会产生这种变化,例如:你的鼠标发出一个中断,它的驱动会处理它,并且因为它产生了一个新的输入,突然进程就可运行了。在那个时刻, need_resched() 返回 true,然后空闲任务因你的浏览器而被踢出而终止运行。

如果我们呆呆地看着这篇文章,而不做任何事情。那么随着时间的推移,这个空闲循环就像下图一样:

在这个示例中,由内核计划的定时器中断会每 4 毫秒发生一次。这就是 滴答 tick 周期。也就是说每秒钟将有 250 个滴答,因此,这个滴答速率(频率)是 250 Hz。这是运行在 Intel 处理器上的 Linux 的典型值,而其它操作系统喜欢使用 100 Hz。这是由你构建内核时在 CONFIG_HZ 选项中定义的。

对于一个空闲 CPU 来说,它看起来似乎是个无意义的工作。如果外部世界没有新的输入,在你的笔记本电脑的电池耗尽之前,CPU 将始终处于这种每秒钟被唤醒 250 次的地狱般折磨的小憩中。如果它运行在一个虚拟机中,那我们正在消耗着宿主机 CPU 的性能和宝贵的时钟周期。

在这里的解决方案是 动态滴答,当 CPU 处于空闲状态时,定时器中断被 暂停或重计划,直到内核知道将有事情要做时(例如,一个进程的定时器可能要在 5 秒内过期,因此,我们不能再继续睡眠了),定时器中断才会重新发出。这也被称为无滴答模式

最后,假设在一个系统中你有一个活动进程,例如,一个长时间运行的 CPU 密集型任务。那样几乎就和一个空闲系统是相同的:这些示意图仍然是相同的,只是将空闲任务替换为这个进程,并且相应的描述也是准确的。在那种情况下,每 4 毫秒去中断一次任务仍然是无意义的:它只是操作系统的性能抖动,甚至会使你的工作变得更慢而已。Linux 也可以在这种单一进程的场景中停止这种固定速率的滴答,这被称为 自适应滴答 模式。最终,这种固定速率的滴答可能会 完全消失

对于阅读一篇文章来说,CPU 基本是无事可做的。内核的这种空闲行为是操作系统难题的一个重要部分,并且它与我们看到的其它情况非常相似,因此,这将帮助我们理解一个运行中的内核。


via: https://manybutfinite.com/post/what-does-an-idle-cpu-do/

作者:Gustavo Duarte 译者:qhwdw 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

本文勘误与补充

长文预警: 这是一个目前严格限制的、禁止披露的安全 bug(LCTT 译注:目前已经部分披露),它影响到目前几乎所有实现虚拟内存的 CPU 架构,需要硬件的改变才能完全解决这个 bug。通过软件来缓解这种影响的紧急开发工作正在进行中,并且最近在 Linux 内核中已经得以实现,并且,在 11 月份,在 NT 内核中也开始了一个类似的紧急开发。在最糟糕的情况下,软件修复会导致一般工作负载出现巨大的减速(LCTT 译注:外在表现为 CPU 性能下降)。这里有一个提示,攻击会影响虚拟化环境,包括 Amazon EC2 和 Google 计算引擎,以及另外的提示是,这种精确的攻击可能涉及一个新的 Rowhammer 变种(LCTT 译注:一个由 Google 安全团队提出的 DRAM 的安全漏洞,在文章的后面部分会简单介绍)。

我一般不太关心安全问题,但是,对于这个 bug 我有点好奇,而一般会去写这个主题的人似乎都很忙,要么就是知道这个主题细节的人会保持沉默。这让我在新年的第一天(元旦那天)花了几个小时深入去挖掘关于这个谜团的更多信息,并且我将这些信息片断拼凑到了一起。

注意,这是一件相互之间高度相关的事件,因此,它的主要描述都是猜测,除非过一段时间,它的限制禁令被取消。我所看到的,包括涉及到的供应商、许多争论和这种戏剧性场面,将在限制禁令取消的那一天出现。

LWN

这个事件的线索出现于 12 月 20 日 LWN 上的 内核页面表的当前状况:页面隔离这篇文章。从文章语气上明显可以看到这项工作的紧急程度,内核的核心开发者紧急加入了 KAISER 补丁系列的开发——它由奥地利的 TU Graz 的一组研究人员首次发表于去年 10 月份。

这一系列的补丁的用途从概念上说很简单:为了阻止运行在用户空间的进程在进程页面表中通过映射得到内核空间页面的各种攻击方式,它可以很好地阻止了从非特权的用户空间代码中识别到内核虚拟地址的攻击企图。

这个小组在描述 KAISER 的论文《KASLR 已死:KASLR 永存》摘要中特别指出,当用户代码在 CPU 上处于活动状态的时候,在内存管理硬件中删除所有内核地址空间的信息。

这个补丁集的魅力在于它触及到了核心,内核的全部基柱(以及与用户空间的接口),显然,它应该被最优先考虑。遍观 Linux 中内存管理方面的变化,通常某个变化的首次引入会发生在该改变被合并的很久之前,并且,通常会进行多次的评估、拒绝、以及因各种原因爆发争论的一系列过程。

而 KAISER(就是现在的 KPTI)系列(从引入到)被合并还不足三个月。

ASLR 概述

从表面上看,这些补丁设计以确保 地址空间布局随机化 Address Space Layout Randomization (ASLR)仍然有效:这是一个现代操作系统的安全特性,它试图将更多的随机位引入到公共映射对象的地址空间中。

例如,在引用 /usr/bin/python 时,动态链接将对系统的 C 库、堆、线程栈、以及主要的可执行文件进行排布,去接受随机分配的地址范围:

$ bash -c ‘grep heap /proc/$$/maps’
019de000-01acb000 rw-p 00000000 00:00 0                                  [heap]
$ bash -c 'grep heap /proc/$$/maps’
023ac000-02499000 rw-p 00000000 00:00 0                                  [heap]

注意两次运行的 bash 进程的堆(heap)的开始和结束偏移量上的变化。

如果一个缓存区管理的 bug 将导致攻击者可以去覆写一些程序代码指向的内存地址,而那个地址之后将在程序控制流中使用,这样这种攻击者就可以使控制流转向到一个包含他们所选择的内容的缓冲区上。而这个特性的作用是,对于攻击者来说,使用机器代码来填充缓冲区做他们想做的事情(例如,调用 system() C 库函数)将更困难,因为那个函数的地址在不同的运行进程上不同的。

这是一个简单的示例,ASLR 被设计用于去保护类似这样的许多场景,包括阻止攻击者了解有可能被用来修改控制流的程序数据的地址或者实现一个攻击。

KASLR 是应用到内核本身的一个 “简化的” ASLR:在每个重新引导的系统上,属于内核的地址范围是随机的,这样就使得,虽然被攻击者操控的控制流运行在内核模式上,但是,他们不能猜测到为实现他们的攻击目的所需要的函数和结构的地址,比如,定位当前进程的数据段,将活动的 UID 从一个非特权用户提升到 root 用户,等等。

坏消息:缓减这种攻击的软件运行成本过于贵重

之前的方式,Linux 将内核的内存映射到用户内存的同一个页面表中的主要原因是,当用户的代码触发一个系统调用、故障、或者产生中断时,就不需要改变正在运行的进程的虚拟内存布局。

因为它不需要去改变虚拟内存布局,进而也就不需要去清洗掉(flush)依赖于该布局的与 CPU 性能高度相关的缓存(LCTT 译注:意即如果清掉这些高速缓存,CPU 性能就会下降),而主要是通过 转换查找缓冲器 Translation Lookaside Buffer (TLB)(LCTT 译注:TLB ,将虚拟地址转换为物理地址)。

随着页面表分割补丁的合并,内核每次开始运行时,需要将内核的缓存清掉,并且,每次用户代码恢复运行时都会这样。对于大多数工作负载,在每个系统调用中,TLB 的实际总损失将导致明显的变慢:@grsecurity 测量的一个简单的案例,在一个最新的 AMD CPU 上,Linux du -s 命令变慢了 50%。

34C3

在今年的 CCC 大会上,你可以找到 TU Graz 的另外一位研究人员,《描述了一个纯 Javascript 的 ASLR 攻击》,通过仔细地掌握 CPU 内存管理单元的操作时机,遍历了描述虚拟内存布局的页面表,来实现 ASLR 攻击。它通过高度精确的时间掌握和选择性回收的 CPU 缓存行的组合方式来实现这种结果,一个运行在 web 浏览器的 Javascript 程序可以找回一个 Javascript 对象的虚拟地址,使得可以利用浏览器内存管理 bug 进行接下来的攻击。(LCTT 译注:本文作者勘误说,上述链接 CCC 的讲演与 KAISER 补丁完全无关,是作者弄错了)

因此,从表面上看,我们有一组 KAISER 补丁,也展示了解除 ASLR 化地址的技术,并且,这个展示使用的是 Javascript,它很快就可以在一个操作系统内核上进行重新部署。

虚拟内存概述

在通常情况下,当一些机器码尝试去加载、存储、或者跳转到一个内存地址时,现代的 CPU 必须首先去转换这个 虚拟地址 到一个 物理地址 ,这是通过遍历一系列操作系统托管的数组(被称为页面表)的方式进行的,这些数组描述了虚拟地址和安装在这台机器上的物理内存之间的映射。

在现代操作系统中,虚拟内存可能是最重要的强大特性:它可以避免什么发生呢?例如,一个濒临死亡的进程崩溃了操作系统、一个 web 浏览器 bug 崩溃了你的桌面环境、或者一个运行在 Amazon EC2 中的虚拟机的变化影响了同一台主机上的另一个虚拟机。

这种攻击的原理是,利用 CPU 上维护的大量的缓存,通过仔细地操纵这些缓存的内容,它可以去推测内存管理单元的地址,以去访问页面表的不同层级,因为一个未缓存的访问将比一个缓存的访问花费更长的时间(以实时而言)。通过检测页面表上可访问的元素,它可能能够恢复在 MMU(LCTT 译注:存储器管理单元)忙于解决的虚拟地址中的大部分比特(bits)。

这种动机的证据,但是不用恐慌

我们找到了动机,但是到目前为止,我们并没有看到这项工作引进任何恐慌。总的来说,ASLR 并不能完全缓减这种风险,并且也是一道最后的防线:仅在这 6 个月的周期内,即便是一个没有安全意识的人也能看到一些关于解除(unmasking) ASLR 化的指针的新闻,并且,实际上这种事从 ASLR 出现时就有了。

单独的修复 ASLR 并不足于去描述这项工作高优先级背后的动机。

它是硬件安全 bug 的证据

通过阅读这一系列补丁,可以明确许多事情。

第一,正如 @grsecurity 指出 的,代码中的一些注释已经被编辑掉了(redacted),并且,描述这项工作的附加的主文档文件已经在 Linux 源代码树中看不到了。

通过检查该代码,这些补丁以运行时补丁的方式构建而成,在系统引导时仅当内核检测到该系统是受影响的系统时,这些补丁才会被应用。这里采用了和对著名的 Pentium F00F bug 的缓解措施完全相同的机制:

更多的线索:Microsoft 也已经实现了页面表的分割

通过对 FreeBSD 源代码的一个简单挖掘可以看出,目前,其它的自由操作系统没有实现页面表分割,但是,通过 Alex Ioniscu 在 Twitter 上的提示,这项工作已经不局限于 Linux 了:从 11 月起,公开的 NT 内核也已经实现了同样的技术。

猜测:Rowhammer

对 TU Graz 研究人员的工作的进一步挖掘,我们找到这篇 《当 rowhammer 仅敲一次》,这是 12 月 4 日通告的一个 新的 Rowhammer 攻击的变种

在这篇论文中,我们提出了新的 Rowhammer 攻击和漏洞的原始利用方式,表明即便是组合了所有防御也没有效果。我们的新攻击技术,对一个位置的反复 “敲打”(hammering),打破了以前假定的触发 Rowhammer bug 的前提条件。

快速回顾一下,Rowhammer 是多数(全部?)种类的商业 DRAM 的一类根本性问题,比如,在普通的计算机中的内存上。通过精确操作内存中的一个区域,这可能会导致内存该区域存储的相关(但是逻辑上是独立的)内容被毁坏。效果是,Rowhammer 可能被用于去反转内存中的比特(bits),使未经授权的用户代码可以访问到,比如,这个比特位描述了系统中的其它代码的访问权限。

我发现在 Rowhammer 上,这项工作很有意思,尤其是它反转的位接近页面表分割补丁时,但是,因为 Rowhammer 攻击要求一个目标:你必须知道你尝试去反转的比特在内存中的物理地址,并且,第一步是得到的物理地址可能是一个虚拟地址,就像在 KASLR 中的解除(unmasking)工作。

猜测:它影响主要的云供应商

在我能看到的内核邮件列表中,除了该子系统维护者的名字之外,e-mail 地址属于 Intel、Amazon 和 Google 的雇员,这表示这两个大的云计算供应商对此特别感兴趣,这为我们提供了一个强大的线索,这项工作很大的可能是受虚拟化安全驱动的。

它可能会导致产生更多的猜测:虚拟机 RAM 和由这些虚拟机所使用的虚拟内存地址,最终表示为在主机上大量的相邻的数组,那些数组,尤其是在一个主机上只有两个租户的情况下,在 Xen 和 Linux 内核中是通过内存分配来确定的,这样可能会有(准确性)非常高的可预测行为。

最喜欢的猜测:这是一个提升特权的攻击

把这些综合到一起,我并不难预测,可能是我们在 2018 年会使用的这些存在提升特权的 bug 的发行版,或者类似的系统推动了如此紧急的进展,并且在补丁集的抄送列表中出现如此多的感兴趣者的名字。

最后的一个趣闻,虽然我在阅读补丁集的时候没有找到我要的东西,但是,在一些代码中标记,paravirtual 或者 HVM Xen 是不受此影响的。

吃瓜群众表示 2018 将很有趣

这些猜想是完全有可能的,它离实现很近,但是可以肯定的是,当这些事情被公开后,那将是一个非常令人激动的几个星期。


via: http://pythonsweetness.tumblr.com/post/169166980422/the-mysterious-case-of-the-linux-page-table

作者:python sweetness 译者:qhwdw 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

bash 命令通常单线程运行。这意味着所有的处理工作只在单个 CPU 上执行。随着 CPU 规模的扩大以及核心数目的增加,这意味着只有一小部分的 CPU 资源用于处理你的工作。

当我们的工作受制于 CPU 处理数据的速度时,这些未使用的 CPU 资源能产生很大的效用。这种情况在进行多媒体转换(比如图片和视频转换)以及数据压缩中经常遇到。

本文中,我们将会使用 parallel 程序。parallel 会接受一个列表作为输入,然后在所有 CPU 核上并行地执行命令来处理该列表。Parallel 甚至会按顺序将结果输出到标准输出中,因此它可以用在管道中作为其他命令的标准输入。

如何使用 parallel

parallel 在标准输入中读取一个列表作为输入,然后创建多个指定命令的进程来处理这个列表,其格式为:

list | parallel command

这里的 list 可以由任何常见的 bash 命令创建,例如:catgrepfind。这些命令的结果通过管道从它们的标准输出传递到 parallel 的标准输入,像这样:

find . -type f -name "*.log" | parallel

find 中使用 -exec 类似,parallel 使用 {} 来表示输入列表中的每个元素。下面这个例子中,parallel 会使用 gzip 压缩所有 find 命令输出的文件:

find . -type f -name "*.log" | parallel gzip {}

下面这些实际的使用 parallel 的例子可能会更容易理解一些。

使用 parallel 来进行 JPEG 压缩

在这个例子中,我收集了一些比较大的 .jpg 文件(大约 10MB 大小),要用 Mozilla 出品的 JPEG 图像压缩工具 MozJPEG 来进行处理。该工具会在尝试保持图像质量的同时减少 JPEG 图像文件的大小。这对降低网页加载时间很重要。

下面是一个普通的 find 命令,用来找出当前目录中的所有 .jpg 文件,然后通过 MozJPEG 包中提供的图像压缩工具 (cjpeg) 对其进行处理:

find . -type f -name "*.jpg" -exec cjpeg -outfile LoRes/{} {} ';'

总共耗时 0m44.114s。该命令运行时的 top 看起来是这样的:

你可以看到,虽然有 8 个核可用,但实际只有单个线程在用单个核。

下面用 parallel 来运行相同的命令:

find . -type f -name "*.jpg" | parallel cjpeg -outfile LoRes/{} {}

这次压缩所有图像的时间缩减到了 0m10.814s。从 top 显示中可以很清楚地看出不同:

所有 CPU 核都满负荷运行,有 8 个线程对应使用 8 个 CPU 核。

parallel 与 gzip 连用

如果你需要压缩多个文件而不是一个大文件,那么 parallel 就能用来提高处理速度。如果你需要压缩单个文件而同时又想要利用所有的 CPU 核的话,那么你应该 gzip 的多线程替代品 pigz

首先,我用随机数据创建了 100 个大约 1GB 的文件:

for i in {1..100}; do dd if=/dev/urandom of=file-$i bs=1MB count=10; done

然而我用 find -exec 命令来进行压缩:

find . -type f -name "file*" -exec gzip {} ';'

总共耗时 0m28.028s,而且也是只利用了单核。

换成 parallel 版本:

find . -type f -name "file*" | parallel gzip {}

耗时减少到了 0m5.774s

parallel 是一款非常好用的工具,应该加入到你的系统管理工具包中,在合适的场合它能帮你节省大量的时间。


via: https://bash-prompt.net/guides/parallell-bash/

作者:Elliot Cooper 译者:lujun9972 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

请各位思考以下问题:在你阅读本文的这段时间内,计算机中的操作系统在运行吗?又或者仅仅是 Web 浏览器在运行?又或者它们也许均处于空闲状态,等待着你的指示?

这些问题并不复杂,但它们深入涉及到系统软件工作的本质。为了准确回答这些问题,我们需要透彻理解操作系统的行为模型,包括性能、安全和除错等方面。在该系列文章中,我们将以 Linux 为主举例来帮助你建立操作系统的行为模型,OS X 和 Windows 在必要的时候也会有所涉及。对那些深度探索者,我会在适当的时候给出 Linux 内核源码的链接。

这里有一个基本认知,就是,在任意给定时刻,某个 CPU 上仅有一个任务处于活动状态。大多数情形下这个任务是某个用户程序,例如你的 Web 浏览器或音乐播放器,但它也可能是一个操作系统线程。可以确信的是,它是一个任务,不是两个或更多,也不是零个,对,永远是一个。

这听上去可能会有些问题。比如,你的音乐播放器是否会独占 CPU 而阻止其它任务运行?从而使你不能打开任务管理工具去杀死音乐播放器,甚至让鼠标点击也失效,因为操作系统没有机会去处理这些事件。你可能会愤而喊出,“它究竟在搞什么鬼?”,并引发骚乱。

此时便轮到中断大显身手了。中断就好比,一声巨响或一次拍肩后,神经系统通知大脑去感知外部刺激一般。计算机主板上的芯片组同样会中断 CPU 运行以传递新的外部事件,例如键盘上的某个键被按下、网络数据包的到达、一次硬盘读取的完成,等等。硬件外设、主板上的中断控制器和 CPU 本身,它们共同协作实现了中断机制。

中断对于记录我们最珍视的资源——时间——也至关重要。计算机启动过程中,操作系统内核会设置一个硬件计时器以让其产生周期性计时中断,例如每隔 10 毫秒触发一次。每当计时中断到来,内核便会收到通知以更新系统统计信息和盘点如下事项:当前用户程序是否已运行了足够长时间?是否有某个 TCP 定时器超时了?中断给予了内核一个处理这些问题并采取合适措施的机会。这就好像你给自己设置了整天的周期闹铃并把它们用作检查点:我是否应该去做我正在进行的工作?是否存在更紧急的事项?直到你发现 10 年时间已逝去……

这些内核对 CPU 周期性的劫持被称为 滴答 tick ,也就是说,是中断让你的操作系统滴答了一下。不止如此,中断也被用作处理一些软件事件,如整数溢出和页错误,其中未涉及外部硬件。中断是进入操作系统内核最频繁也是最重要的入口。对于学习电子工程的人而言,这些并无古怪,它们是操作系统赖以运行的机制。

说到这里,让我们再来看一些实际情形。下图示意了 Intel Core i5 系统中的一个网卡中断。图片中的部分元素设置了超链,你可以点击它们以获取更为详细的信息,例如每个设备均被链接到了对应的 Linux 驱动源码。

链接如下:

让我们来仔细研究下。首先,由于系统中存在众多中断源,如果硬件只是通知 CPU “嘿,这里发生了一些事情”然后什么也不做,则不太行得通。这会带来难以忍受的冗长等待。因此,计算机上电时,每个设备都被授予了一根中断线,或者称为 IRQ。这些 IRQ 然后被系统中的中断控制器映射成值介于 0 到 255 之间的中断向量。等到中断到达 CPU,它便具备了一个完好定义的数值,异于硬件的某些其它诡异行为。

相应地,CPU 中还存有一个由内核维护的指针,指向一个包含 255 个函数指针的数组,其中每个函数被用来处理某个特定的中断向量。后文中,我们将继续深入探讨这个数组,它也被称作中断描述符表(IDT)。

每当中断到来,CPU 会用中断向量的值去索引中断描述符表,并执行相应处理函数。这相当于,在当前正在执行任务的上下文中,发生了一个特殊函数调用,从而允许操作系统以较小开销快速对外部事件作出反应。考虑下述场景,Web 服务器在发送数据时,CPU 却间接调用了操作系统函数,这听上去要么很炫酷要么令人惊恐。下图展示了 Vim 编辑器运行过程中一个中断到来的情形。

此处请留意,中断的到来是如何触发 CPU 到 Ring 0 内核模式的切换而未有改变当前活跃的任务。这看上去就像,Vim 编辑器直接面向操作系统内核产生了一次神奇的函数调用,但 Vim 还在那里,它的地址空间原封未动,等待着执行流返回。

这很令人振奋,不是么?不过让我们暂且告一段落吧,我需要合理控制篇幅。我知道还没有回答完这个开放式问题,甚至还实质上翻开了新的问题,但你至少知道了在你读这个句子的同时滴答正在发生。我们将在充实了对操作系统动态行为模型的理解之后再回来寻求问题的答案,对 Web 浏览器情形的理解也会变得清晰。如果你仍有问题,尤其是在这篇文章公诸于众后,请尽管提出。我将会在文章或后续评论中回答它们。下篇文章将于明天在 RSS 和 Twitter 上发布。


via: http://duartes.org/gustavo/blog/post/when-does-your-os-run/

作者:gustavo 译者:Cwndmiao 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

运行在“Ring -3” 的 MINIX

你可能不知道,但是在你的英特尔系统里,除了你的主操作系统之外,还有一个操作系统在运行,这就是 MINIX。

早在今年 5月,EFF 就发布了一篇文章,介绍了自 2008 年以来,这十年间英特尔发布的所有处理器都运行了一个修改版的 MINIX 3,它被称之为“管理引擎(ME)”。这个由计算机科学教授 Andrew Tanenbaum (对,就是那位早期曾经和 Linus Torvalds 论战过的教授)作为一个教育工具开发的类 Unix 操作系统内置于每一款新英特尔处理器内。

MINIX 运行在你的 CPU 的 “Ring -3”(负数 3) 层上,虽然是你的 CPU,但是你无权访问它。你能够实际访问的最低的 “Ring” 是 “Ring 0”,你的操作系统(比如 Linux)内核就运行在这一层,而大多数用户程序则运行在 “Ring 3”(正数 3)上。

这个运行在 “Ring -3” 的 MINIX 包括如下功能:

完整网络堆栈、文件系统、许多驱动程序 (包括 USB、网络等),以及一个 Web 服务器!

没错,Web 服务器。在你的 CPU 里面有一个秘密的 Web 服务器,您是不允许访问的,而且,显然,英特尔并不希望你知道。我们不知道这个 Web 服务器究竟有什么用途,也许是 CPU 厂商会用它来访问一些数据或者进行一些控制。但是这一切,你都不知道。

据称,Google 正在积极从其内部服务器上移除这个管理引擎,显然 Google 对其安全风险感到忧虑。

这个事情有两个有趣或者说疯狂的地方:

首先,由于英特尔 CPU 的流行,所以,世界上最流行的操作系统恐怕不是 Windows,也不是 Linux,而是这个 MINIX——我们都是 MINIX 用户!

其次,由于你根本没权限访问到“Ring -3”,而这个 MINIX 却能够完全访问你的整个系统——这就是一个巨大的安全风险,运行权限极大,但是从不更新。

MINIX 作者表态

在过去几天多家媒体报道了这一消息,以至于惊动了 Andrew 本人。他在个人网站上发表了公开信,强调自己并没有直接参与这个项目,如果这个系统有后门的话,这与他无关(他对此并没有明说只是暗示)。

Andrew Tanenbaum 称,MINIX 3 在 2000 年决定采用 BSD 授权,原因是企业不喜欢 GPL 许可证,认为 GPL 会让他们花费许多时间精力金钱去修改代码,然后免费提供给竞争对手。他说,英特尔的工程团队在几年前接触了他,询问了 MINIX 3 大量的技术问题,要求他对 MINIX 3 进行大量改变,减少内存占用,选择性的关闭不需要的功能。

在短暂的活跃之后双方进入了静默,直到现在媒体报道英特尔处理器都运行了 MINIX 3 他才知道。他对此感到吃惊,但并不在意,因为该操作系统是 BSD 授权,英特尔不需要付钱给他。他只是希望英特尔在部署了 MINIX 3 之后能通知他一下,这只是礼貌问题。

参考:solidotnetworkworld

现有的技术无法对微芯片进行有效的冷却,这正快速成为摩尔定律消亡的第一原因。

随着对数字计算速度的需求,科学家和工程师正努力地将更多的晶体管和支撑电路放在已经很拥挤的硅片上。的确,它非常地复杂,然而,和复杂性相比,热量聚积引起的问题更严重。

洛克希德马丁公司首席研究员 John Ditri 在新闻稿中说到:当前,我们可以放入微芯片的功能是有限的,最主要的原因之一是发热的管理。如果你能管理好发热,你可以用较少的芯片,也就是说较少的材料,那样就可以节约成本,并能减少系统的大小和重量。如果你能管理好发热,用相同数量的芯片将能获得更好的系统性能。

硅对电子流动的阻力产生了热量,在如此小的空间封装如此多的晶体管累积了足以毁坏元器件的热量。一种消除热累积的方法是在芯片层用光子学技术减少电子的流动,然而光子学技术有它的一系列问题。

参见: 2015 年硅光子将引起数据中心的革命

微流冷却技术可能是问题的解决之道

为了寻找其他解决办法,美国国防高级研究计划局 DARPA 发起了一个关于 ICECool 应用 (片内/片间增强冷却技术)的项目。 GSA 的网站 FedBizOpps.gov 报道:ICECool 正在探索革命性的热技术,其将减轻热耗对军用电子系统的限制,同时能显著减小军用电子系统的尺寸,重量和功耗。

微流冷却方法的独特之处在于组合使用片内和(或)片间微流冷却技术和片上热互连技术。

MicroCooling 1 Image: DARPA

DARPA ICECool 应用发布的公告 指出,这种微型片内和(或)片间通道可采用轴向微通道、径向通道和(或)横流通道,采用微孔和歧管结构及局部液体喷射形式来疏散和重新引导微流,从而以最有利的方式来满足指定的散热指标。

通过上面的技术,洛克希德马丁的工程师已经实验性地证明了片上冷却是如何得到显著改善的。洛克希德马丁新闻报道:ICECool 项目的第一阶段发现,当冷却具有多个局部 30kW/cm2 热点,发热为 1kw/cm2 的芯片时热阻减少了 4 倍,进而验证了洛克希德的嵌入式微流冷却方法的有效性。

第二阶段,洛克希德马丁的工程师聚焦于 RF 放大器。通过 ICECool 的技术,团队演示了 RF 的输出功率可以得到 6 倍的增长,而放大器仍然比其常规冷却的更凉。

投产

出于对技术的信心,洛克希德马丁已经在设计和制造实用的微流冷却发射天线。 洛克希德马丁还与 Qorvo 合作,将其热解决方案与 Qorvo 的高性能 GaN 工艺 相集成。

研究论文 DARPA 的片间/片内增强冷却技术(ICECool)流程 的作者认为 ICECool 将使电子系统的热管理模式发生改变。ICECool 应用的执行者将根据应用来定制片内和片间的热管理方法,这个方法需要兼顾应用的材料,制造工艺和工作环境。

如果微流冷却能像科学家和工程师所说的成功的话,似乎摩尔定律会起死回生。

(题图:iStock/agsandrew)


via: http://www.techrepublic.com/article/microfluidic-cooling-may-prevent-the-demise-of-moores-law/

作者:Michael Kassner 译者:messon007 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出