[LLVMdev] Handling of unsafe functions
richard at metafoo.co.uk
Thu Sep 20 15:08:58 PDT 2012
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
> >> which are marked as a “security vulnerability”. There has been
> >> already done to address some of them for Linux (e.g. snprintf). We are
> >> attempting to solve this issue in a comprehensive fashion across all
> >> platforms. Most of the functions identified are for manipulating
> >> Memcpy is the most commonly used of all these unsecure methods. The
> >> following table lists all these functions are their recommended secure
> >> alternatives.
> > I am strongly opposed to using *_s functions. The issue is that they
> > are no more "secure" than original functions. One can still pass the
> > destination buffer length incorrectly, especially if it is not known
> > at compile time and should be computed.
> > I agree with Sean that we should move the code using C strings to LLVM
> > safe data types.
> I agree.
> > And one more thing: it is interesting that the "unsafe"
> > APFloat::convertToHexString (from your patch) is not used anywhere.
> Zap it! Oh wait, is it used by Clang or something else?
Clang doesn't use it, but LLDB does, with an arbitrary-seeming
256-character buffer. Perhaps we should change it to take an
llvm::SmallVectorImpl<char>, rather than relying on a character buffer
"which must be of sufficient size".
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev