Microsoft SDL 和 memcpy 弃用
你们中的一些人可能知道，Microsoft 从其安全开发生命周期中禁止了 memcpy()，并用 memcpy_s() 取而代之。
void *memcpy(void *dest, const void *src, size_t n);
/* simplified signature */
errno_t memcpy_s(void *dst, size_t dstsize, const void *src, size_t n);
因此，如果您的代码曾经是：
if (in_len > dst_len) {
/* error */
}
memcpy(dst, src, in_len);
它会变成：
if (memcpy_s(dst, dst_len, src, src_len)) {
/* error */
}
或者，经过截断，
memcpy(dst, src, min(in_len, dst_len));
vs
(void)memcpy_s(dst, dst_len, src, src_len);
问题：额外的长度参数如何使代码更安全？ 要使用 memcpy()，我应该已经知道所有四个参数，并传递适当的长度作为第三个参数。 是什么阻止我犯同样的错误：错误计算目标缓冲区大小并传递错误的 dst_size 值？ 我不明白为什么它与 memcpy() 有何不同以及为什么它被弃用。 有没有我看不到的常见用例？ 我在这里缺少什么？
As some of you may know, Microsoft banned memcpy() from their Security Development Lifecycle, replacing it with memcpy_s().
void *memcpy(void *dest, const void *src, size_t n);
/* simplified signature */
errno_t memcpy_s(void *dst, size_t dstsize, const void *src, size_t n);
So if your code used to be:
if (in_len > dst_len) {
/* error */
}
memcpy(dst, src, in_len);
it becomes:
if (memcpy_s(dst, dst_len, src, src_len)) {
/* error */
}
Or, with truncation,
memcpy(dst, src, min(in_len, dst_len));
vs
(void)memcpy_s(dst, dst_len, src, src_len);
The question: how does an extra length parameter make code any more secure? To use memcpy(), I should already have all four parameters known and pass appropriate length as a third argument. What's stopping me from making the same mistake of miscalculating destination buffer size and passing the wrong valus of dst_size? I can't see why it's any different from memcpy() and why it's being deprecated. Is there any common use case that I can't see? What am I missing here?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
在“安全”版本中也没有什么可以阻止您输入错误的参数。 微软似乎认为你总是会使用类似的东西：
并检查错误。
但这只能帮助那些不知道自己在使用该语言做什么的人。 在我看来，那群人要么不应该使用该语言，要么他们应该学习它如何正常工作。
从长远来看，这种拐杖对他们没有任何好处，因为他们的代码不可移植。
现在可能是微软做了一些分析，发现有很多问题是由于人们误用
memcpy()而引起的，他们认为这可以解决它。 但是，如果是这样的话，我怀疑更好的解决方案是教育开发人员，而不是强迫他们使用标准编译器中不可用的非标准功能。Nothing stops you from getting the parameters wrong in the "secure" version either. Microsoft seems to think that you'll always use something like:
and check the error.
But this only helps people who don't know what they're doing with the language. In my opinion, that group of people either shouldn't be using the language or they should learn how it works properly.
This sort of crutch doesn't do them any favors in the long run since their code won't be portable.
Now it may be that Microsoft did some analysis and found that there were a lot of problems caused by people misusing
memcpy()and they thought this would fix it. But, if that were the case, I suspect a better solution would be to educate the developers rather than forcing them to use non-standard features which will be unavailable in standard compilers.重复的信息总是糟糕的设计——它只会让你有更多的机会出错。 Microsoft 在 API 设计方面有着令人震惊的记录，并且过去仅靠其卓越的文档才得以挽救。 令人欣慰的是，他们无法删除原始的 memcpy() 函数 - 它是 ANSI C 的一部分。
Duplication of information is always bad design - it just gives you more chances to get something wrong. Microsoft have an appaling record when it comes to API design, and have been saved in the past only by the excellence of their documentation. The comforting thing is that they cannot remove the original memcpy() function - it is part of ANSI C.
你是完全正确的。 如果您跟踪两个缓冲区的长度，则可以安全使用 memcpy。 如果你不这样做，memcpy_s 也救不了你。
You're absolutely correct. If you are keeping track of both buffers' lengths, memcpy is safe to use. If you're not, memcpy_s won't save you.
你没有错过任何东西，我认为你链接到的文章中的这个片段几乎涵盖了它：
You're not missing anything, I think this snippet from the article you linked to pretty much covers it:
根据微软的说法，这将使编写代码质量检查变得更容易 - 您可以检查以确保程序员不会将相同的值传递给两个大小参数（许多人可能仍然会出于懒惰而这样做）。 另一件事（实际上与代码安全性并不真正相关）是，您可以使用此方法稍微清理一下代码，因为代码中需要执行的检查较少 -
memcpy_s函数将检查您认为目标缓冲区中有足够的空间，从而消除了您的一项检查。最重要的是，
memcpy_s返回一个错误代码，指示整个复制是否成功，但对于memcpy则无法确定这一点。 这是 Microsoft 认为使memcpy_s比memcpy更安全的原因。According to Microsoft, this will make it a bit easier to write code quality checks for - you can check to be sure that the programmer does not pass the same value to both size parameters (which many people would probably still do out of laziness). The other thing (not actually really related to code security) is that you can clean up your code a bit using this method, because there are less checks to do in your code - the
memcpy_sfunction will check for you that there is enough space in the destination buffer, eliminating one of your checks.Most important of all,
memcpy_sreturns an error code indicating whether the whole copy succeeded, but withmemcpythere is no way to be sure of this. This is what Microsoft feels makesmemcpy_ssafer thanmemcpy.C 类汇编适合那些知道自己在做什么的人，我记得直接从 K&R 读过类似的东西
C like assembly is for people that know what they are doing, I remember to read something like that direcly from K&R
有时我真的很怀疑，世界上已经没有多少真正的程序员能够看到机器的本质并喜欢四处移动比特了。 我知道有点偏离主题，但我想确切地知道发生了什么，并且绝对不希望任何蹩脚的垃圾收集器在后台拼命地试图整理草率的程序员混乱的堆。 我的意思是，将对 free() 的调用与对 malloc()/strdup() 的调用相匹配有多难，确保已分配足够的缓冲区空间以便知道可以安全地调用 memcpy() 有多难？ 答案：不是很，但是 99.9% 的程序员真的不关心他们在做什么，因为他们只是为了钱，而不是编写一段漂亮优雅的代码的热情。
结束咆哮。
I actually dispare sometimes, there really arn't many of us real programmers left in the world any more who see the machine for what it is and love shifting bits around. A bit off topic I know, but I like to know exactly what's going on and definatly don't want any lame ass garbage collector going around the the background desperatly trying to sort out sloppy programmers messy heaps. I mean, how hard is it to match calls to free() with calls to malloc()/strdup(), how hard is it to make sure you have allocated enough buffer space in order to know you can call memcpy() saefly? Answer: Not very, but 99.9% of programmers really don't care what they are doing because they're just in it for the money, not the passion of writing a beutifully elligant piece of code.
End Rant.