Linux发行版幽灵漏洞的backport

遇到一个问题，简要记录如下:

base on ubuntu18.06  4.15内核，这版内核不支持一款intel的集成网卡，追踪内核代码的提交历史才发现，这款网卡是从linux-4.20才开始支持的,系统自带的这个Kernel版本不支持。

如果不允许升级内核，面对这种问题，社区的做法是把新内核的特性cherrypick到老版本上，这种操作一般被叫做backport.把相关补丁从4.20打回到4.15.

更新：

最近接触到一个新的问题，下面这段代码会造成无限递归，在执行到的时候死循环出不来。出错。

这段代码是C写的，实现很简单，伪代码表示如下：

int __x86_return_thunk(void)
{
     return 0;
}

函数什么都没有做，仅仅返回一个0就退出了。但实际上，7.2.0之后的gcc不会把__x86_return_thunk这个函数当成一个普通函数，它虽然可以由用户定义，但是编译器再生成指令的时候，可以通过选项 -mfunction-return=thunk-extern 触发编译器将ret执行修改为 jmp __x86_return_thunk 指令实现对这个函数的调用，这一切是无法通过阅读函数是实现观察到的。

口说无凭，程序作证：

#include <stdio.h>

int main(void)
{
        printf("%s line %d.\n", __func__, __LINE__);

        return 0;
}

$ gcc demo.c
$ ls
a.out  demo.c
$ ./a.out
main line 5.
$

如果不加-mfunction-return=thunk-extern选项，会发现编译运行没有问题。但是如果增加这样的选项编译，就会遇到__x86_return_thunk符号找不到的链接错误：

$ gcc  -mfunction-return=thunk-extern demo.c
/tmp/ccYssgHN.o: In function `main':
demo.c:(.text+0x24): undefined reference to `__x86_return_thunk'
collect2: error: ld returned 1 exit status

demo.c非常简单，从源代码看没有未定义的符号依赖，所以这个链接错误一定不是编码本身的问题，而是编译器再连接阶段需要这样的一个符号，而这个符号是编译器识别，由用户去定义的。

但是当我们增加对这个符号的定义:

#include <stdio.h>

int __x86_return_thunk(void)
{
     return 0;
}

int main(void)
{
        printf("%s line %d.\n", __func__, __LINE__);

        return 0;
}

$ gcc  -mfunction-return=thunk-extern demo.c
[br104@localhost demo]$ ls
a.out  demo.c
[br104@localhost demo]$ ./a.out
main line 10.

这次虽然编译过了，运行时却再打印完成后卡死了。

经过分析汇编，才发现原因是__x86_return_thunk函数再末尾又调用了自身，造成了无限递归调用。

源代码中我们是没有这么做的，所以只能是编译器搞的鬼，它再函数末尾又安插了对函数自身的调用。

按照这个逻辑，如果函数体中加入打印，运行时应该无限打印才对。经过验证，确实如此：

#include <stdio.h>

int __x86_return_thunk(void)
{
        printf("%s line %d.\n", __func__, __LINE__);
        return 0;
}

int main(void)
{
        printf("%s line %d.\n", __func__, __LINE__);

        return 0;
}

所以现象和上面的问题是一致的了，我们用一个简单的demo复现到了项目中的问题。

如果按照这个逻辑，编译器会对所有的函数末尾安插对__x86_return_thunk函数的调用，包括__x86_return_thunk自身，所以__x86_return_thunk就不能用c语言实现，应该改成汇编。

$ ls
a.dis  a.out  demo.c  demo.o  demo.S
$ cat demo.c
#include <stdio.h>

int foobar(void)
{
        printf("%s line %d.\n", __func__, __LINE__);
        return 0;
}

int main(void)
{
        printf("%s line %d.\n", __func__, __LINE__);

        foobar();

        return 0;
}
$ cat demo.S
// void __x86_return_thunk(void);
// MUST be impl. with assembly for nest invocation.

.align 64
.globl __x86_return_thunk
.type __x86_return_thunk, @function
__x86_return_thunk:
        ret
.size   __x86_return_thunk, .-__x86_return_thunk

$ gcc -mfunction-return=thunk-extern demo.S demo.c
$ ls
a.dis  a.out  demo.c  demo.o  demo.S
$ ./a.out
main line 11.
foobar line 5.
$

时程序行为终于正常，反汇编如上图，每个C语言写的函数在末尾都会调用__x86_return_thunk，而手搓汇编实现的__x86_return_thunk，仍然保留了汇编指令原来的样子。猜测得到了印证。

在Linux内核中的用法,linux内核从5.16.x才开始支持这个特性。

并在0b53c374b9eff2255a386f1f1cfb9a928e52a5ae得到了增强：

最近内核的配置是顶层Makefile配置编译器选项：

内核架构arch/x86/Makefile增加了CONFIG_RETPOLINE配置:

实际上，这个编译选项的来源颇有渊源，它实际上是由当年发现的一个非常重要的CPU设计BUG引发的，这个BUG就是大名鼎鼎的“幽灵漏洞”，技术性分析可以参考下面这篇文章。

https://zhuanlan.zhihu.com/p/438616789

正式这个BUG如此重要，影响如此广泛，在此补丁加入后，之前已经基于老版本的KERNEL的发行版又backport了这个补丁，比如典型的centos基于3.10内核对这个补丁进行了backport.如果你安装了centos7，使用的是3.10的内核，你很可能会在系统自带的内核源码树里面找到__x86_return_thunk的踪迹。

linux 5.19内核上的对应的__x86_return_thunk实现在文件linux-stable/arch/x86/lib/retpoline.S中,通过编译选项CONFIG_RETPOLINE控制编译：

针对幽灵漏洞的backport在内核开发中一直在进行，如下图，4.14.314版的内核已经集成了BACKPORT，对应到linux-stable仓库中的4.14.314 tag.

x86编译选项

-mcmodel=kernel:

Prevent GCC from generating any FP code by mistake:

结束