search for: memcpy_secure

...one think about the value passed for destination size. Very likely most of the 1691 uses of memcpy in Clang/LLVM are correct but with such a high number of uses there are likely a few that are not. I'm willing to plow through all the calls to check the parameters while making the change to the memcpy_secure version from the proposal. Thanks, Javier From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Richard Smith Sent: Thursday, September 20, 2012 3:09 PM To: Chris Lattner Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Handling of unsafe functions On Thu, Se...

...the value passed for destination size. Very > likely most of the 1691 uses of memcpy in Clang/LLVM are correct but with > such a high number of uses there are likely a few that are not. I’m willing > to plow through all the calls to check the parameters while making the > change to the memcpy_secure version from the proposal. My inclination is that it will be redundant. For example, consider this usage, grabbed randomly from the source code: char *Buf = static_cast<char *>(Allocate(Directory.size())); memcpy(Buf, Directory.data(), Directory.size()); it's not that clear...

...ion buffer size is redundant information. I think we also agree that there are cases where the correct use of memcpy is not clear cut and the 4-parameter version adds value. I've modified the original proposal to strike the middle of the road. Instead of only providing a 4-parameter version of memcpy_secure now a 3-parameter version also exists. The latter maps to memcpy or memcpy_s depending on what's available as determined by the CMake scripts. The 4-parameter version replaces those calls to memcpy where safe use can't be determined. All other calls will be replaced to the 3-parameter versi...

...mentation will be platform specific (like > the Mutex class in Support module). In cases where the platform does not > support the functionality natively, we are writing an implementation of > these functions. For example, in the case of memcpy the secure function > will look like llvm::memcpy_secure. > > Some secure functions require additional data that needs to be passed > (like buffer sizes). That information has to be added in all places of > invocation. In some cases, this requires an extra size_t argument to be > passed through. Hence, this change would not just be a one t...

...nt while their implementation will be platform specific (like the Mutex class in Support module). In cases where the platform does not support the functionality natively, we are writing an implementation of these functions. For example, in the case of memcpy the secure function will look like llvm::memcpy_secure. Some secure functions require additional data that needs to be passed (like buffer sizes). That information has to be added in all places of invocation. In some cases, this requires an extra size_t argument to be passed through. Hence, this change would not just be a one to one function refacto...

On 09/21/2012 05:52 AM, Martinez, Javier E wrote: > The proposal comments have largely centered on the string functions. Do > people feel the same way about memcpy_s? What about those of you > building LLVM on Windows with Visual Studio? Is memcmp_s (or a variant thereof) a win in practice? It covers the case pretty well where you try to copy a dynamically sized buffer to the start

...mentation will be platform specific (like the Mutex class in > Support module). In cases where the platform does not support the > functionality natively, we are writing an implementation of these functions. > For example, in the case of memcpy the secure function will look like > llvm::memcpy_secure. > > > > Some secure functions require additional data that needs to be passed (like > buffer sizes). That information has to be added in all places of invocation. > In some cases, this requires an extra size_t argument to be passed through. > Hence, this change would not just...

...tation will be platform > specific (like the Mutex class in Support module). In cases where the > platform does not support the functionality natively, we are writing an implementation of these functions. > For example, in the case of memcpy the secure function will look like > llvm::memcpy_secure. > > > > Some secure functions require additional data that needs to be passed > (like buffer sizes). That information has to be added in all places of invocation. > In some cases, this requires an extra size_t argument to be passed through. > Hence, this change would not just...

On Thu, Sep 20, 2012 at 10:13 AM, Chris Lattner <clattner at apple.com> wrote: > > On Sep 20, 2012, at 3:01 AM, Dmitri Gribenko <gribozavr at gmail.com> wrote: > > > On Wed, Sep 19, 2012 at 3:00 AM, Martinez, Javier E > > <javier.e.martinez at intel.com> wrote: > >> We have identified functions in LLVM sources using a static code > analyzer >

On Sep 20, 2012, at 3:01 AM, Dmitri Gribenko <gribozavr at gmail.com> wrote: > On Wed, Sep 19, 2012 at 3:00 AM, Martinez, Javier E > <javier.e.martinez at intel.com> wrote: >> We have identified functions in LLVM sources using a static code analyzer >> which are marked as a “security vulnerability”[1][2]. There has been work >> already done to address some of