memcpy_s这类安全函数使用介绍(来自安全 C 库: Safe C Library )

你若向前

已于 2023-12-24 17:47:17 修改

阅读量2.3w

点赞数 8

分类专栏： C/C++ 文章标签： c++ c语言

于 2022-03-31 10:57:44 首次发布

本文链接：https://blog.csdn.net/StoryZX/article/details/123866245

版权

C/C++ 专栏收录该内容

12 篇文章 0 订阅

订阅专栏

本文主要对带有 _s 的这类安全函数(如 memcpy_s)进行简单介绍，以及如何在自己的 Linux 开发环境中使用这些函数。

文章目录

1. 引入这类安全函数

最近在写程序时，涉及内存拷贝的问题，比如我这里有三个字符类型数组 a、b、c，可以理解为三个缓冲区，其中 a 和 b 中的内容需要根据 c 中的内容进行构建，a 取其中的前半段，b 取其中的后半段，需要取的长度已知。
显然，这里可以使用内存拷贝函数 memcpy。你知道从 c 缓冲区的那个地方开始，到哪里结束应该给 a 缓冲区和 b 缓冲区，使用 memcpy 进行定长拷贝，这种做法很便捷。但是，我却被同事告知这种做法不是很安全，应当使用 memcpy_s 函数来进行定长(内存)拷贝。那我心里就产生了一个疑问：为什么这些函数更加安全，标准库却没有引入呢？
随即，我发现不仅仅有 memcpy_s，还有很多类似的函数，如：strncpy_s、memmove_s、memset_s、snprintf_s、strcpy_s 等等，有这么一类函数的存在，他们被称之为 C 的安全库函数，但是却不在标准库中，标准库中的这些函数，都是不带有 _s 的。

2. 安全类函数介绍

2.1 这类函数的背景

这类所谓的安全函数最初是由微软( Microsoft )为 Windows 平台实现的，其官方名字为 Safe C Library，见其官网，这里有这些函数的详细介绍，以及函数实现的文件依赖图( Include dependency graph )。但是有很多组织机构是反对将这些纳入 C 标准库中的，尽管最终微软说服 C 标准委员会( C standard committee) 将这些函数加入附录 K 中，但是这些函数仍然不是标准库的一部分。这些安全函数从 C11 标准才开始支持，但似乎也仅限于 MSVC （微软的 VC 运行库）。以上，大概就能够解释为什么官方手册中给的示例程序在自己的 Linux 开发机中无法编译、运行，即便引入了 srting.h 头函数，即便你在程序中定义了文档中所说必须的宏，也还是会显示找不到 memcpy_s 函数的定义。如果你真的去查找了一遍，就会发现，string.h 文件中根本没有对应的这些函数。
至此，你可以理解为，这一类所谓更安全的函数，是微软的 VC 运行库中的函数，对于其他平台，默认并不支持，当今强制推广这些安全函数的只有 Windows 平台。（啊这，微软写的，自己不得给自己捧场。）

2.2 源码对比分析

这里源码对比分析仅限于 memcpy 与 memcpy_s。
搞清楚了它的背景，来谈一下相比于标准库的这些函数，这些函数有什么改进的地方。
我们来拿 memcpy 函数与 memcpy_s 函数举例。先来看看 memcpy 函数的源码实现：

/* libgcc/memcpy.c */
#include <stddef.h>
void *
memcpy (void *dest, const void *src, size_t len)
{
  char *d = dest;
  const char *s = src;
  while (len--)
    *d++ = *s++;
  return dest;
}

这里的源码来自 libgcc/memcpy.c, 不同地方的源码实现可能稍有差异(目前我见过三个版本，大同小异吧)，总体而言，memcpy 函数实现较为简单，并不会对指针是否合法、缓冲区长度是否满足拷贝的需要进行检查。再来看一下 memcpy_s 函数。memcpy_s 函数的实现如下：

#ifdef FOR_DOXYGEN
#include "safe_mem_lib.h"
#else
#include "safeclib_private.h"
#include "mem/mem_primitives_lib.h"
#endif

#if defined(TEST_MSVCRT) && defined(HAVE_MEMCPY_S)
#else
#ifdef FOR_DOXYGEN //这个宏是否定义决定是否实现这个函数
errno_t memcpy_s(void *restrict dest, rsize_t dmax,
                 const void *restrict src, rsize_t slen)
#else
EXPORT errno_t _memcpy_s_chk(void *restrict dest, rsize_t dmax,
                             const void *restrict src, rsize_t slen,
                             const size_t destbos, const size_t srcbos)
#endif
{
    uint8_t *dp;
    const uint8_t *sp;

    /* MSVC 在最开始就进行检查，这里也这么做 */
    if (unlikely(slen == 0)) { /* 从 C11 开始，允许slen = 0，即拷贝的长度可以是0，此时函数什么都不做 */
        return EOK;
    }

    dp = (uint8_t *)dest;
    sp = (uint8_t *)src;
	/* 这里会检查指针是否指向 NULL、目的缓冲区是否为空 */
    CHK_DEST_MEM_NULL("memcpy_s")
    CHK_DMAX_MEM_ZERO("memcpy_s")
    if (destbos == BOS_UNKNOWN) {
        CHK_DMAX_MEM_MAX("memcpy_s", RSIZE_MAX_MEM)
        BND_CHK_PTR_BOUNDS(dest, dmax);
        BND_CHK_PTR_BOUNDS(dest, slen);
    } else {
        CHK_DEST_MEM_OVR("memcpy_s", destbos)
        /* Note: unlike to memset_s, we don't set dmax to destbos */
    }

    CHK_SRC_MEM_NULL_CLEAR("memcpy_s", src)
    CHK_SLEN_MEM_MAX_NOSPC_CLEAR("memcpy_s", slen, RSIZE_MAX_MEM)

    if (srcbos == BOS_UNKNOWN) {
        BND_CHK_PTR_BOUNDS(src, slen);
    } else if (unlikely(slen > srcbos)) {
        invoke_safe_mem_constraint_handler("memcpy_s: slen exceeds src",
                                           (void *)src, EOVERFLOW);
        return (RCNEGATE(EOVERFLOW));
    }

    /* 不允许重叠，但是允许源缓冲区和目的缓冲区的指针相同，即两个缓冲区的起始位置可以是一个地方，相当于什么都不做 */
    if (unlikely(CHK_OVRLP_BUTSAME(dp, dmax, sp, slen))) {
        mem_prim_set(dp, dmax, 0);
        MEMORY_BARRIER;
        invoke_safe_mem_constraint_handler("memcpy_s: overlap undefined", dest,
                                           ESOVRLP);
        return RCNEGATE(ESOVRLP);
    }

    /*
     * 这里真正执行拷贝
     */
    mem_prim_move(dp, sp, slen);

    return RCNEGATE(EOK);
}
#ifdef __KERNEL__
EXPORT_SYMBOL(_memcpy_s_chk);
#endif
#endif

这里的源码来自 Safe C Library。不难看出，memcpy_s 函数在执行时，会先对两个缓冲区的大小，以及各自指针指向的位置是否合法、是否会产生重叠等进行检查，相对于 memcpy 函数， memcpy_s 函数可以帮助我们做一些检查，帮助我们发现程序中写出的错误。

2.3 安全性分析

memcpy_s 的检查功能在程序发布之前，可以说还是挺好的，编译程序时，一定程度上能帮助我们发现程序中的错误之处，这样我们可以及时对程序进行修正。我们自己没有发现的错误，可以让程序帮我们检查出来，自然要省一些事。但是最终程序能够正常运行而不出错，还是需要我们自己传入合法的指针、合法的长度。注意，这类’安全’函数的功能只是多做一些检查，而不是自己处理这些不合法的情况。这就意味着，它是用来辅助开发者写出问题尽可能少的代码。那如果说开发者已经借助各种工具、提示，写出问题尽可能少，工作也正常的程序，那这个时候，为了安全而进行的校验，反而显得有些多余。比如，初学者考驾照时都需要一个教练，教练会教你如何正确行驶，当你学会驾驶汽车之后，你的副驾位置就不需要一直有教练在了。
出于性能考虑，对于较大型的软件，可能使用这类函数(如内存拷贝)的地方很多，如果每个地方都需要使用到这些’安全’函数，反而会降低程序的执行效率，因为你要花费很多时间在各种校验上，在开发者尽可能去规避掉各种不合法情况之后，这些校验大部分都是不必要的。还需要注意的是，我前边说的是一定程度上，也就是说，这类函数的一些检查，并不一定能检查出所有的问题，仍然可能会有比较隐蔽的错误发生。这些大概能解释为什么会有很多反对将这些函数纳入 C 标准库吧。

3. 如何在自己的 Linux 开发环境使用类函数

吐槽归吐槽，你可能会鄙弃这些函数，但出于某种原因，你可能身不由己，还是需要去用这些东西。既然了解了，就顺便讲一下其他平台的使用这类函数的方法吧。

3.1 获取源码

网上可能能够直接获取到源码的地方不多，或者说，往往不知道他源码的名字叫什么，我们也不知道怎么去搜索。还有就是，一部分人在获取源码途径之后，将其变为一种收费的方式传播资源，这也一定程度增大了获取源码的难度。以下给出开源源码地址。
如前边所说，这类函数对应的库名称为 Safe C Library，相关介绍请看官网。其源码地址为：GitHub 、对应代码同步至 Gitee 。在 GitHub 可能还会看到一些名称类似的，源码部分可能也有很多重复的地方，可能是早期 fork 的版本，后续维护较少。建议使用上述推荐的两个代码地址。

3.2 编译和安装

编译、安装都需要在 root 用户下进行。之后需要执行的命令分别如下所示：

# 这里已经是在 root 用户下，如果不是，则需要使用 sudo 执行
./build-aux/autogen.sh
./configure         # 如果想自己指定安装位置，可以使用 --prefix=/path/to/install，通常默认安装位置在/usr/local目录下
make
make install

过程中如果出现 Libtool library used but ‘LIBTOOL’ is undefined，则可能是没有安装 libtool 工具。

当你看到 autoreconf: command not found这样的错误消息时，这通常意味着你的系统上没有安装 autoreconf 工具或者它没有被添加到你的系统路径中。autoreconf 是一个 GNU 工具，它用于更新和重新生成 configure 脚本和其他相关的自动工具文件，通常在编译源代码时用于配置和构建过程。为了解决这个问题，你可以按照以下步骤操作：

对于 Ubuntu/Debian 系统：

sudo apt-get update
sudo apt-get install autoconf automake libtool

对于 CentOS/RHEL 系统：

sudo yum install autoconf automake libtool

3.3 使用 Safe C Library

到这里，已经是安装完成的状态了，这时候，我们可以尝试使用 memcpy_s 函数了。首先需要引入头文件 “safe_mem_lib.h” 。

#include <safe_mem_lib.h>

使用了这个头文件，那么在编译程序时，你就需要告诉程序这个头文件的位置在哪里。比如我这里是默认安装的，即在执行 ./configure 时没有指定 –prefix 参数，它的默认安装路径在 /usr/local，对应的头文件位置就是 /usr/local/include/safeclib，由于使用到了 Safe C Library，编译时还需要指定链接的库，比如，这里在 /usr/local/lib 目录下有库文件 libsafec.a，我们要链接这个库，就要使用 -lsafec 参数(即 -l 参数，其内容为 safec )。那么，对于程序 test_memcpy_s.c，其完整的编译命令如下：

gcc test_memcpy_s.c -o test -I/usr/local/include/safeclib -I/usr/local/lib -lsafec

到这里，编译、链接程序生成可执行文件应该是没问题了，但是在运行可执行文件的过程中，可能会出现找不到动态库的问题，如下所示：

./test    # 运行程序，得到如下结果，显示找不到libsafec.so.3
./test_c: error while loading shared libraries: libsafec.so.3: cannot open shared object file: No such file or directory

# 使用 ldd 查看程序所依赖的库的情况，执行结果如下
ldd test
	linux-vdso.so.1 (0x0000ffffa0444000)
	libsafec.so.3 => not found      # 这里显示找不到这个库文件
	libc.so.6 => /lib64/libc.so.6 (0x0000ffffa0248000)
	/lib/ld-linux-aarch64.so.1 (0x0000ffffa0407000)

但是，进入安装目录，发现这个库应该是存在的，只是程序找不到而已，如下所示：

cd /usr/local/lib
ls
 libsafec.a  libsafec.la  libsafec.so  libsafec.so.3  libsafec.so.3.0.7  pkgconfig

对应解决办法如下：

# 首先打开 ld.so.conf 文件，并在文件中添加相应库所在的目录路径，即将 /usr/local/lib 添加到文件中，独占一行即可。注意需要 sudo 权限
sudo vim /etc/ld.so.conf

# 添加之后执行如下命令，注意也需要 sudo 权限
sudo ldconfig

# 之后检查程序是否能够找到相关的库，发现已经可以找到了
ldd test                                                                                                                                           
	linux-vdso.so.1 (0x0000ffff9ccde000)
	libsafec.so.3 => /usr/local/lib/libsafec.so.3 (0x0000ffff9cc3c000)
	libc.so.6 => /lib64/libc.so.6 (0x0000ffff9ca7d000)
	/lib/ld-linux-aarch64.so.1 (0x0000ffff9cca1000)

这里已经没有 not found 了，程序可以正常执行了。

4. 总结

这里简单的对 Safe C Library 进行了简单介绍，对于这一类含有 _s 的函数，我这里只是对比分析了其中一个，其余相关函数逻辑上大抵类似，但这样也许会以偏概全，还是希望开发者在实践中产生自己的理解。
每个人的开发环境，使用过程可能都会有差异，以上是在我环境中的部署情况以及遇到的问题，欢迎交流探讨。