Please Join me in welcoming memcpy() to the SDL Rogues Gallery

Please Join me in welcoming memcpy() to the SDL Rogues Gallery | Microsoft Share Point

Fri, 15 May 2009 01:30:21 GMT

PingBack from http://microsoft-sharepoint.simplynetdev.com/please-join-me-in-welcoming-memcpy-to-the-sdl-rogues-gallery/

re: Please Join me in welcoming memcpy() to the SDL Rogues Gallery

jmtd — Fri, 15 May 2009 11:20:14 GMT

Linus is not the one who would make a decision on memcpy: it would be the maintainers of the GNU C library ("glibc"). They might well add a memcpy_s macro (undoubtably there is already a secure memcpy function in GNU libc, but with a different name) but they would almost certainly not remove or forbid access to the C standard memcpy.

Microsoft Bans memcpy()

US ISV Developer Evangelism Team — Fri, 15 May 2009 18:54:28 GMT

For those writing in C, you will be interested in a posting on The Security Development Lifecycle blog

Ada?

nelsonchandler — Fri, 15 May 2009 20:40:22 GMT

Are we ever going to see Microsoft Ada? It can do everything C does, but in a much safer way.

re: Please Join me in welcoming memcpy() to the SDL Rogues Gallery

t-scotmc — Sat, 16 May 2009 01:53:07 GMT

Questionably useful. If you're using C but can afford pointless checks, then you're using the wrong language. (Well, I think that C is the wrong language on anything with a filesystem, but that's a separate issue.)

Sure, this sounds good, but I'm not convinced memcpy_s will really help. It's only checking consistency between 2 of the arguments, which means that all 4 can still be wrong. Not something I'd call "secure". (At very least I'd want checks that src+srcsize <= dst || dst+dstsize <= src, but what you really to check need is that the memory ranges are valid subranges of allocated arrays, which you can't without either ruining performance or breaking code.)

I wonder whether Larry, Steve and Linus will actually notice a difference in the quality of Steve (Ballmer)'s products...

re: Please Join me in welcoming memcpy() to the SDL Rogues Gallery

A.M. — Sat, 16 May 2009 18:46:32 GMT

Functions like memcpy_s don't make code more secure and are poorly written and will degrade performance of your code as much as 3 times. What will be your next step - deprecate pointers?

This is just a publicity stunt. Microsoft has to stop letting marketing people write code.

re: Please Join me in welcoming memcpy() to the SDL Rogues Gallery

sdl — Mon, 18 May 2009 04:16:45 GMT

A.M.

absolutely no-one from mktg touched the content of this article. this is a technical article, describing some real changes we're making to our dev processes. you should take a look at http://www.microsoft.com/sdl to see it's not mktg.

False sense of security!

twonine — Tue, 19 May 2009 14:45:44 GMT

I do not believe this approach – that of requiring source and target buffer lengths to be supplied as function arguments – solves the problem! It simply introduces another opportunity for error.

This approach only works if the lengths supplied are correct, and I think it is easy for a programmer to get this wrong while having a false sense of security.

re: Please Join me in welcoming memcpy() to the SDL Rogues Gallery

asnowfall — Wed, 27 May 2009 21:45:39 GMT

I have always used something like this...

#define BUFF_SIZE 32

char dst[BUFF_SIZE], src[BUFF_SIZE];

memcpy(dst,src,BUFF_SIZE);

First thing that I do is to assign the buffer length to a variable, and use it for both source and destination while calling malloc(), memcpy(), etc.... I follow similar descipline while using strxxx() and it has worked fine. I have tried using strxxx_S() versions found it to be redundent.

Word like "poison" is uncalled for because problem is with programmer, and as you say, a poor programmer could drive even memcpy_s() to ditch :-).