<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"\@SimSun-ExtB";
        panose-1:2 1 6 9 6 1 1 1 1 1;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
        {mso-style-priority:99;
        mso-style-link:"Plain Text Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";}
span.EmailStyle17
        {mso-style-type:personal;
        font-family:"Calibri","sans-serif";
        color:windowtext;}
span.PlainTextChar
        {mso-style-name:"Plain Text Char";
        mso-style-priority:99;
        mso-style-link:"Plain Text";
        font-family:"Calibri","sans-serif";}
.MsoChpDefault
        {mso-style-type:export-only;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoPlainText">Hello,<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">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 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 strings. Memcpy is the most commonly used of all these unsecure methods. The following table lists all these functions are their recommended
 secure alternatives.  <o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Recommended alternatives:<o:p></o:p></p>
<p class="MsoPlainText">Functions    Windows        Unix/Mac OS <o:p></o:p></p>
<p class="MsoPlainText">Memcpy     memcpy_s      -<o:p></o:p></p>
<p class="MsoPlainText">Sprint          sprintf_s         snprintf<o:p></o:p></p>
<p class="MsoPlainText">Sscanf         scanf_s            -<o:p></o:p></p>
<p class="MsoPlainText">_alloca        _malloca         -<o:p></o:p></p>
<p class="MsoPlainText">Strcat          strcat_s          strlcat<o:p></o:p></p>
<p class="MsoPlainText">Strcpy         strcpy_s          strlcpy<o:p></o:p></p>
<p class="MsoPlainText">Strtok         strtok_s           -<o:p></o:p></p>
<p class="MsoPlainText">                                                                                                               
<o:p></o:p></p>
<p class="MsoPlainText">The proposal is to add secure versions of these functions. These functions will be implemented in LLVM Support module and be used by all other LLVM modules. The interface of these methods will be platform independent 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.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">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 refactoring. The attached patch helps illustrate how an instance of memcpy would be modified.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Is this proposal of interest to the LLVM community? Can you also comment if the approach specified is good to address this issue?<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">References:<o:p></o:p></p>
<p class="MsoPlainText">[1] http://msdn.microsoft.com/en-us/library/ms235384(v=vs.80).aspx<o:p></o:p></p>
<p class="MsoPlainText">[2] https://developer.apple.com/library/mac/#documentation/Security/Conceptual/SecureCodingGuide/Articles/BufferOverflows.html<o:p></o:p></p>
</div>
</body>
</html>