Re: Microsoft and memcpy?

On May 18, 11:08 am, rich...@xxxxxxxxxxxxxxx (Richard Tobin) wrote:
In article <gus6sc$sk...@xxxxxxxxxxxxxxxxx>,
Beej Jorgensen  <b...@xxxxxxx> wrote:

As for memcpy_s(), I'm having trouble coming up with likely practical
scenarios where it saves you

The idea is presumably that it just provides an increased chance that
a mistake will be detected.  It won't always work, because sometimes
the passed-in size will be inaccurate, but perhaps it works often
enough to be worthwhile in an operation the size of Microsoft's.

Internally, Microsoft uses "team foundation" which is a version of
Visual Studio which includes a tool called "PRE-fast". This tool is
similar to LINT. It catches any obvious problems with memcpy() with a
post-compile step analysis. I.e., it figures out all the "base
pointer" and offset arithmetic automatically then tries to figure out
if you are out of bounds.

With memcpy_s() all of a sudden half of that work has been thrust into
the programmer's lap to do a run-time check, while hardly any cases
become checked that could not have been checked at compile time. It
also introduces problems if the programmer miscalculates the base
pointer offset arithmetic, or introduces a wrap around problem as I
alluded to in my other post.

Look, the general thinking behind the _s functions is that programmers
are not thinking in terms of the length limits of their buffers,
therefore we are going to force them to. But in the case of memcpy()
that's not true and this new machinery is just getting in the way (and
that's even if you buy into the thinking behind the _s functions).

What bothers me is that these security efforts totally miss the real
problem. (And this is where Richard Heathfield and I clearly
disagree.) Programmers what to use what's *EASIEST* to use, or
equivalently, what accomplishes the most with the least effort. That's
why they use gets(), strtok() etc. (RH at this point would just prefer
to shoot the "bad" programmers, whereas I would prefer to turn them
into good programmers even if inadvertently.) But the C standard
library is not ideal in this regard by any stretch of the
imagination. So there is an obvious opportunity here, to try to
simultaneously solve the ease-of-use *AND* security issues
simultaneously. In fact, I claim, that you actually cannot solve one
without the other. I.e., so long as the easiest way to sort of get
something to do is unsafe or error prone, you will get unsafe and
error-prone solutions.

In the case of array copying, for example, you could make the
following syntax:

a[] = b[];

and all of a sudden, the "memcpy() problems" have just reduced
significantly. Is there some controversy, or ambiguity with the above
syntax? If a and b are not the same type (meaning base type and
length) then obviously the compiler would just emit and error and
stop; so it would help encourage strong typing in order to leverage
this easier syntax. It even gives the compiler the opportunity to
inline different kinds of copying functions depending on which
strategy would work best as determined at *COMPILE* time rather than
run time (which memcpy() is forced to do). Of course we could always
wrap these in structs, but that's cumbersome, and a brief survey will
show that that is not done in general. The point is that developers
*WILL* change their code in order to leverage this easier syntax which
will makes their code safer.

But of course, nobody bothers to propose something like this.
Certainly not Microsoft. Between Micrsoft's memcpy_s() and the "off
the top of my head" proposal above, which do you think would actually
reduce security incidences related to memcpy()?

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/
.

Relevant Pages

  • Re: The IMMEDIATE mess
    ... makes sense in compile state, then you can make it with IMMEDIATE. ... In 35 years I've yet to have a problem with IMMEDIATE. ... So I want to find a way to add the features I want instead of get rid ... If you give Forth programmers power, ...
    (comp.lang.forth)
  • Re: Python, Perl, Lua, Ruby -- anybody??
    ... optional 64-bit support. ... There should be a contest to port certain apps to Perl 4 from Perl 5. ... (Yes, it's apparently true, assembly programmers care more about ... couldn't compile for 0.6.2 or so because he only had an x86-64 box ...
    (comp.os.msdos.djgpp)
  • Re: Python, Perl, Lua, Ruby -- anybody??
    ... everything-else have spoilt programmers into not even trying to ... removing write support for VFAT probably slimmed it ... I guess that's one argument for using Perl instead. ... Perl can byte compile (or compile with GCC via "perlcc" although ...
    (comp.os.msdos.djgpp)
  • Re: Obstacles for Tcl/Tk commercial application development ?
    ... Maybe it helps good programmers be better, ... because in the Tcl example being a dynamic and interpreted language just ... Assymptotically the type system becomes less and less useful until its ... to be changed and, after the change, it will refuse to compile code ...
    (comp.lang.tcl)
  • Re: anti-aliasing
    ... If you have a way of training programmers to never make mistakes, then of course you needn't worry about design methodology, debugging, or any of the other little irritations the rest of us face. ... experienced people read the requirements/design/other documentation/code in detail to find as many problems as possible. ... Spotting the use of memcpy when memmove should be used is easy in a review and the programmer will learn from having had it pointed out and being required to correct it. ... I have never made components for any aircraft, but I have written software for systems in several. ...
    (comp.lang.c)