Google 的 Grafeas 为容器的元数据提供了一个从镜像、构建细节到安全漏洞的通用 API。

我们运行的软件从来没有比今天更难获得。它分散在本地部署和云服务之间，由不知到有多少的开源组件构建而成，以快速的时间表交付，因此保证安全和质量变成了一个挑战。

最终的结果是软件难以审计、推断、安全化和管理。困难的不只是知道 VM 或容器是用什么构建的, 而是由谁来添加、删除或更改的。Grafeas 最初由 Google 设计，旨在使这些问题更容易解决。

什么是 Grafeas?

Grafeas 是一个定义软件组件的元数据 API 的开源项目。旨在提供一个统一的元数据模式，允许 VM、容器、JAR 文件和其他软件 工件 artifact 描述自己的运行环境以及管理它们的用户。目标是允许像在给定环境中使用的软件一样的审计，以及对该软件所做的更改的审计，并以一致和可靠的方式进行。

Grafeas提供两种格式的元数据 API —— 备注和事件：

• 备注 note 是有关软件工件的某些方面的细节。可以是已知软件漏洞的描述，有关如何构建软件的详细信息（构建器版本、校验和等），部署历史等。
• 事件 occurrence 是备注的实例，包含了它们创建的地方和方式的细节。例如，已知软件漏洞的详细信息可能会有描述哪个漏洞扫描程序检测到它的情况、何时被检测到的事件信息，以及该漏洞是否被解决。

备注和事件都存储在仓库中。每个备注和事件都使用标识符进行跟踪，该标识符区分它并使其唯一。

Grafeas 规范包括备注类型的几个基本模式。例如，软件包漏洞模式描述了如何存储 CVE 或漏洞描述的备注信息。现在没有接受新模式类型的正式流程，但是这已经在计划创建这样一个流程。

Grafeas 客户端和第三方支持

现在，Grafeas 主要作为规范和参考形式存在，它在 GitHub 上提供。 Go、Python 和 Java 的客户端都可以用 Swagger 生成，所以其他语言的客户端也应该不难写出来。

Google 计划让 Grafeas 广泛使用的主要方式是通过 Kubernetes。 Kubernetes 的一个名为 Kritis 的策略引擎，可以根据 Grafeas 元数据对容器采取措施。

除 Google 之外的几家公司已经宣布计划将 Grafeas 的支持添加到现有产品中。例如，CoreOS 正在考察 Grafeas 如何与 Tectonic 集成，Red Hat 和 IBM 都计划在其容器产品和服务中添加 Grafeas 集成。

via: https://www.infoworld.com/article/3230462/security/what-is-grafeas-better-auditing-for-containers.html

作者：Serdar Yegulalp 译者：geekpi 校对：wxy

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

Linux 内核新增的异构内存管理将解锁加速 GPU 的新途径，并挖掘其它的机器学习硬件的潜能

一项开发了很久的内存管理技术将会给机器学习和其它 GPU 驱动的程序很大幅度的提升，而它也将在接下来的几个版本中进入 Linux 内核。

异构内存管理（HMM）可以允许设备驱动为在其自身内存管理下的进程镜像地址空间。正如红帽的开发者 Jérôme Glisse 所解释的，这让像 GPU 这样的硬件设备可以直接访问进程内存，而不用花费复制带来的额外开销。它还不违反现代操作系统提供的内存保护功能。

一类会从 HMM 中获益最多的应用是基于 GPU 的机器学习。像 OpenCL 和 CUDA 这样的库能够从 HMM 中获得速度的提升。HMM 实现这个的方式和加速基于 GPU 的机器学习相似，就是让数据留在原地，靠近 GPU 的地方，在那里直接操作数据，尽可能少地移动数据。

像这样的加速对于 CUDA（英伟达基于 GPU 的处理库）来说，只会有益于在英伟达 GPU 上的操作，这些 GPU 也是目前加速数据处理的主要硬件。但是，OpenCL 设计用来编写可以针对多种硬件的代码——CPU、GPU、FPGA 等等——随着这些硬件的成熟，HMM 能够提供更加广泛的益处。

要让 Linux 中的 HMM 处于可用状态还有一些阻碍。第一个是内核支持，在很长一段时间里都受到限制。早在 2014年，HMM 最初作为 Linux 内核补丁集提出，红帽和英伟达都是关键开发者。需要做的工作不少，但是开发者认为代码可以提交上去，也许接下来的几个内核版本就能把它包含进去。

第二个阻碍是显卡驱动支持，英伟达一直在自己单独做一些工作。据 Glisse 的说法，AMD 的 GPU 可能也会支持 HMM，所以这种特殊优化不会仅限于英伟达的 GPU。AMD 一直都在尝试提升它的 GPU 市场占有率，有可能会将 GPU 和 CPU 整合到同一模具。但是，软件生态系统依然更青睐英伟达；要使其兑现，还需要更多的像 HMM 这样的中立项目，以及让 OpenCL 提供和 CUDA 相当的性能。

第三个阻碍是硬件支持，因为 HMM 的工作需要一项称作 可重现页面故障 （ replayable page faults ） 的硬件特性。只有英伟达的帕斯卡系列高端 GPU 才支持这项特性。从某些意义上来说这是个好消息，因为这意味着英伟达只需要提供单一硬件的驱动支持就能让 HMM 正常使用，工作量就少了。

一旦 HMM 到位，对于提供 GPU 实例的公有云提供商就会面临压力，他们需要支持最新最好一代的 GPU。这并不是仅仅将老款的开普勒架构显卡换成最新的帕斯卡架构显卡就行了，因为后续的每一代显卡都会更加优秀，像 HMM 这样的支持优化将提供战略优势。

（题图：Thinkstock）

via: http://www.infoworld.com/article/3196884/linux/faster-machine-learning-is-coming-to-the-linux-kernel.html

作者：Serdar Yegulalp 译者：alim0x 校对：wxy

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

最新版本的 OpenBSD 6.0 将关闭潜在的安全漏洞——比如其 Linux 兼容层。

OpenBSD，这个 BSD 家族里面最重要的变种之一将在今年九月份发布新的 6.0 版本。它通常被视作 Linux 的一个替代品，以没有专有软件而闻名，并由于其默认情况下比其它的操作系统更安全，以及对用户安全的高度警惕而广泛受到赞誉。由于其在开发过程中的安全理念，许多软件路由器和防火墙项目都是基于 OpenBSD 而开发的。

在这次 OpenBSD 新版本中安全相关的最大变化是其移除了对 Linux 模拟的支持。在之前的 OpenBSD 版本中，Linux 应用可以通过一个兼容层直接运行在 BSD 中，但是在最新的 OpenBSD 6.0 的发布公告中称，由于“安全改进”而移走了该子系统。

OpenBSD 中有一些软件是以附加的二进制软件包方式提供的，OpenBSD 的维护者们会尽量提供对这些软件的支持，但是他们不会像对待其操作系统一样对这些软件的安全性进行筛选。由于现在很多流行应用的最新版本都可以直接运行在 OpenBSD 中，比如说 Chromium 和 Firefox 浏览器，这意味没有 Linux 兼容层也不要紧。

出于安全考虑，OpenBSD 还抛弃了 systrace 系统安全实施策略工具。之前版本的 OpenBSD 包括它，但是并没有用它来管理任何重要的东西。systrace 被视为不安全已经有段时间了，所以在这次的 OpenBSD 发行版中它也将被抛弃。

作为安全增强的一部分，还移除了“usermount”选项，它允许非特权用户挂载文件系统。OpenBSD 项目负责人 Theo de Raadt 说 usermount “允许任何不当的程序调用 mount/umount 系统调用”，这意味着“在提供该功能的前提下，任何用户都没有办法保持其系统的安全性和可靠性的预期。”

在发布于今年三月份的 OpenBSD 的前一个版本 5.9 中，它提供了一些自己的安全改进。比如以特权用户身份运行程序的 sudo 被替换成 doas，这个新的程序使用了更简化和潜在问题更少的配置机制。这种为了安全而做的改变在 Linux 世界会更难见到，而 OpenBSD 则通过让其代码不断采用新的技术而展示了其在安全方面的努力和进步。

Docker 在 开放容器项目 （ Open Container Project，OCP ） 中的参与度达成圆满，最新构建的 Docker 采用了 Docker 贡献给 OCP 的组件。

新发布的 Docker 1.11 的最大新闻并不是它的功能，而是它使用了在 OCP 支持下的标准化的组件版本。

去年，Docker 贡献了它的 runC 核心给 OCP 作为构建构建容器工具的基础。同样还有 containerd，作为守护进程或者服务端用于控制 runC 的实例。Docker 1.11 现在使用的就是这个捐赠和公开的版本。

Docker 此举挑战了它的容器生态仍主要由 Docker 自身决定这个说法。它并不是为了作秀才将容器规范和运行时细节贡献给 OCP。它希望项目将来的开发越开放和广泛越好。

Docker 1.11 已经用贡献给 OCP 的 runC 和 containerd 进行了重构。runC 如果需要的话可以换成另外一个。

runC 的两位主要提交者来自 Docker，但是来自 Virtuozzo(Parallels fame)、OpenShift、Project Atomic、华为、GE Healthcare、Suse Linux 也都是提交人员里面的常客。

Docker 1.11 中一个更明显的变化是先前 Docker runtime 在 Docker 中是唯一可用的，并且评论家认为这个会限制用户的选择。runC runtime 现在是可替换的；虽然 Docker 在发布时将 runC 作为默认引擎，但是任何兼容的引擎都可以用来替换它。（Docker 同样希望它可以不用杀死并重启现在运行的容器，但是这个作为今后的改进规划。）

Docker 正在将基于 OCP 的开发流程作为内部创建其产品的更好方式。在它发布 1.11 的官方博客中称：“将 Docker 切分成独立的工具意味着更专注的维护者，最终会有更好的软件质量。”

除了修复长期以来存在的问题和确保 Docker 的 runC/containerd 跟上步伐，Docker 还在 Docker 1.11 中加入了一些改进。Docker Engine 现在支持 VLAN 和 IPv6 服务发现，并且会自动在多个相同别名容器间执行 DNS 轮询负载均衡。

via: http://www.infoworld.com/article/3055966/open-source-tools/docker-111-adopts-open-container-project-components.html

作者：Serdar Yegulalp 译者：geekpi 校对：wxy

本文由 LCTT 原创翻译，Linux中国 荣誉推出

本月初，甲骨文公司的桌面虚拟化软件获得了近五年来的第一次重大改版，但是更像是改进而不是革命性的的变化。

VirtualBox，由Sun公司创建，现在由甲骨文管理的开源虚拟化系统，获得了近5年来第一次的主版本更新发布。

从发行说明和测试版本身的表现来看，别期望任何真正革命性的改变。在此版本中，VirtualBox在视觉上和技术上都做了一些改进，但和VMware相比，它的主要优势仍然是相同核心功能的开源实现。

VirtualBox 4.0的最后一个主要版本在2010年12月发布，它采用了新的图形化用户界面，新的虚拟化硬件和重组的项目设计，进行了重大的改版。但项目主要版本的发布步伐缓慢，上一次重要版本(版本4.3)在2013年底才发布。从那时起，一切都被正式称为“维护”发布。

VirtualBox 5.0的第一个测试版增加了编辑菜单，VM窗口的快捷方式图标等功能，如下面所示。

VirtualBox 5.0最大的变化是增加了对硬件辅助虚拟化指令集扩展的支持。AES-NI指令集通常用于加密时的硬件加速，SSE 4.1和SSE 4.2指令集都包括在其中。另外一点是支持Windows和Linux客户机的半虚拟化，一个抽象主机音响设备的新的架构以及支持客户机中的USB 3（xHCI）控制器。

大部分可用性更新都是对 VirtualBox 图形化用户界面的改进。一个大的变化就是支持给单个虚拟主机自定义菜单和工具栏，这样很少或者从不使用的选项就可以彻底删除。另外重要的一点是可以在VirtualBox接口内部对虚拟磁盘进行加密，而不依赖于客户机操作系统自身的磁盘加密功能(假设有的话)。

甲骨文公司提醒由于这是个测试版软件，需要谨慎对待。当然，主界面和客户机系统界面的某个角落打着红黑相间的测试警告标志。但之前VirtualBox发行版(4.3.26)上创建的Windows 10虚拟机启动和运行都没问题，5.0版本中添加的VirtualBox客户机功能--更好的视频支持，双向复制和粘贴，以及其它功能--在安装的时候也没有问题。(从4.3.18版本就改进了对 Windows 10的支持)。

虽然没有明确指出5.0的最终版什么时候会发布，但是甲骨文公司建议用户在非生产环境中下载和使用测试版，并在测试版反馈论坛中提交bug报告。

via: http://www.infoworld.com/article/2905098/virtualization/oracle-virtualbox-5-0-beta-is-finally-here.html

作者：Serdar Yegulalp 译者：ictlyh 校对：wxy

本文由 LCTT 原创翻译，Linux中国 荣誉推出

供图: Shutterstock

有多种技术在竞争成为实现Linux内核热补丁的最优方案。

没人喜欢重启机器，尤其是涉及到一个内核问题的最新补丁程序。

为达到不重启的目的，目前有3个项目在朝这方面努力，将为大家提供内核升级时打热补丁的机制，这样就可以做到完全不重启机器。

Ksplice项目

首先要介绍的项目是Ksplice，它是热补丁技术的创始者，并于2008年建立了与项目同名的公司。Ksplice在替换新内核时，不需要预先修改；只需要一个diff文件，列出内核即将接受的修改即可。Ksplice公司免费提供软件，但技术支持是需要收费的，目前能够支持大部分常用的Linux发行版本。

但在2011年Oracle收购了这家公司后，情况发生了变化。 这项功能被合入到Oracle自己的Linux发行版本中，只对Oralcle自己提供技术更新。 这就导致，其他内核hacker们开始寻找替代Ksplice的方法，以避免缴纳Oracle税。

Kgraft项目

2014年2月，Suse提供了一个很好的解决方案：Kgraft，该内核更新技术以GPLv2/GPLv3混合许可证发布，且Suse不会将其作为一个专有发明封闭起来。Kgraft被提交到Linux内核主线，很有可能被内核主线采用。目前Suse已经把此技术集成到Suse Linux Enterprise Server 12。

Kgraft和Ksplice在工作原理上很相似，都是使用一组diff文件来计算内核中需要修改的部分。但与Ksplice不同的是，Kgraft在做替换时，不需要完全停止内核。 在打补丁时，正在运行的函数可以先使用老版本或新内核中对应的部分，当补丁打完后就可以完全切换新的版本。

Kpatch项目

Red Hat也提出了他们的内核热补丁技术。同样是在2014年初 -- 与Suse在这方面的工作差不多 -- Kpatch的工作原理也和Kgraft相似。

主要的区别点在于，正如Red Hat的Josh Poimboeuf总结的那样，Kpatch并不将内核调用重定向到老版本。相反，它会等待所有函数调用都停止时，再切换到新内核。Red Hat的工程师认为这种方法更为安全，且更容易维护，缺点就是在打补丁的过程中会带来更大的延迟。

和Kgraft一样，Kpatch不仅仅可以在Red Hat的发行版本上使用，同时也被提交到了内核主线，作为一个可能的候选。 坏消息是Red Hat还未将此技术集成到产品中。 它只是被合入到了Red Hat Enterprise Linux 7的技术预览版中。

...也许 Kgraft + Kpatch更合适?

Red Hat的工程师Seth Jennings在2014年11月初，提出了第四种解决方案。将Kgraft和Kpatch结合起来, 补丁包用这两种方式都可以。在新的方法中，Jennings提出，“热补丁核心为其他内核模块提供了一个热补丁的注册接口”， 通过这种方法，打补丁的过程 -- 更准确的说，如何处理运行时内核调用 --可以被更加有序的组织起来。

这项新建议也意味着两个方案都还需要更长的时间，才能被linux内核正式采纳。尽管Suse步子迈得更快，并把Kgraft应用到了最新的enterprise版本中。让我们也关注一下Red Hat和Canonical近期是否会跟进。

via: http://www.infoworld.com/article/2851028/linux/four-ways-linux-is-headed-for-no-downtime-kernel-patching.html

作者：Serdar Yegulalp 译者：coloka 校对：tinyeyeser

本文由 LCTT 原创翻译，Linux中国 荣誉推出