<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Hi, in Intel® Integrated Performance Primitives</title>
    <link>https://community.intel.com/t5/Intel-Integrated-Performance/ippsECCPSetStd-crashes/m-p/1077013#M24680</link>
    <description>&lt;P&gt;Hi,&lt;BR /&gt;
	&lt;BR /&gt;
	I think I found the culprit.&lt;BR /&gt;
	On &lt;A href="https://software.intel.com/en-us/node/502779"&gt;https://software.intel.com/en-us/node/502779,&lt;/A&gt; it is stated that AESInit() will return an error if the keylen is different from 16, 24 or 32.&lt;BR /&gt;
	&lt;BR /&gt;
	Unfortunately, I had a selftest that actually tested this (that AES only supports 16, 24 or 32) on our old security-code, where I try to put in a key length of size 40.&lt;BR /&gt;
	This apparently results in an overwrite of internal structures or something somewhere, so that at a certain point later in time, IPP crashes big time (for example when I then call &amp;nbsp;ippsECCPSetStd()).&lt;BR /&gt;
	&lt;BR /&gt;
	Could I recommend a boundery check on incoming parameters in IPP, so that the ippsAesInit() function does NOT try to use data sizes, for which it has not allocated enough memory.&lt;BR /&gt;
	&lt;BR /&gt;
	Putting the 'boundery check' in my own code before calling IPP-AES, saves the day for me (so far at least :-)&lt;/P&gt;

&lt;P&gt;&amp;nbsp;&lt;/P&gt;

&lt;P&gt;- LSB&lt;/P&gt;</description>
    <pubDate>Mon, 11 Apr 2016 09:59:47 GMT</pubDate>
    <dc:creator>Lars_B_Intel</dc:creator>
    <dc:date>2016-04-11T09:59:47Z</dc:date>
    <item>
      <title>ippsECCPSetStd() crashes</title>
      <link>https://community.intel.com/t5/Intel-Integrated-Performance/ippsECCPSetStd-crashes/m-p/1077011#M24678</link>
      <description>&lt;P&gt;Hi,&lt;/P&gt;

&lt;P&gt;I'm trying to use the IPP-ECC functionality (for the first time), and I have a 'weird' issue.&lt;/P&gt;

&lt;P&gt;Doing a very simple example in C on Linux, heavily inspired by &lt;A href="https://software.intel.com/en-us/node/503782"&gt;https://software.intel.com/en-us/node/503782&lt;/A&gt;:&lt;/P&gt;

&lt;P&gt;static IppsECCPState* newStd_256_ECP(void)&lt;BR /&gt;
	{&lt;BR /&gt;
	&amp;nbsp;&amp;nbsp;&amp;nbsp; IppsECCPState *pCtx = NULL;&lt;/P&gt;

&lt;P&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; int ctxSize=0;&lt;BR /&gt;
	&amp;nbsp;&amp;nbsp;&amp;nbsp; if (ippStsNoErr != ippsECCPGetSize(256, &amp;amp;ctxSize))&lt;BR /&gt;
	&amp;nbsp;&amp;nbsp;&amp;nbsp; {&lt;BR /&gt;
	&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; return NULL;&lt;BR /&gt;
	&amp;nbsp;&amp;nbsp;&amp;nbsp; }&lt;/P&gt;

&lt;P&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; pCtx = malloc(ctxSize);&lt;BR /&gt;
	&amp;nbsp;&amp;nbsp;&amp;nbsp; if (NULL == pCtx)&lt;BR /&gt;
	&amp;nbsp;&amp;nbsp;&amp;nbsp; {&lt;BR /&gt;
	&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; return NULL;&lt;BR /&gt;
	&amp;nbsp;&amp;nbsp;&amp;nbsp; }&lt;/P&gt;

&lt;P&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; if (ippStsNoErr != ippsECCPInit(256, pCtx))&lt;BR /&gt;
	&amp;nbsp;&amp;nbsp;&amp;nbsp; {&lt;BR /&gt;
	&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; free(pCtx);&lt;BR /&gt;
	&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; return NULL;&lt;BR /&gt;
	&amp;nbsp;&amp;nbsp;&amp;nbsp; }&lt;BR /&gt;
	/*&lt;BR /&gt;
	&amp;nbsp;&amp;nbsp;&amp;nbsp; if (ippStsNoErr != ippsECCPSetStd(IppECCPStd256r1, pCtx))&lt;BR /&gt;
	&amp;nbsp;&amp;nbsp;&amp;nbsp; {&lt;BR /&gt;
	&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; free(pCtx);&lt;BR /&gt;
	&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; return NULL;&lt;BR /&gt;
	&amp;nbsp;&amp;nbsp;&amp;nbsp; }&lt;BR /&gt;
	*/&lt;BR /&gt;
	&amp;nbsp;&amp;nbsp;&amp;nbsp; return pCtx;&lt;BR /&gt;
	}&lt;/P&gt;

&lt;P&gt;If I comment in the outcommented section (with the call to the ippsECCPSetStd(), but not even calling the overall newStd_256_ECP function at all), it seems as my program hangs, and after some time times out.&lt;/P&gt;

&lt;P&gt;Is this something that has been observed before somehow, and do we have 'a solution' for this&amp;nbsp;?&lt;/P&gt;

&lt;P&gt;- LSB&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Wed, 06 Apr 2016 11:50:54 GMT</pubDate>
      <guid>https://community.intel.com/t5/Intel-Integrated-Performance/ippsECCPSetStd-crashes/m-p/1077011#M24678</guid>
      <dc:creator>Lars_B_Intel</dc:creator>
      <dc:date>2016-04-06T11:50:54Z</dc:date>
    </item>
    <item>
      <title>HI LSB, </title>
      <link>https://community.intel.com/t5/Intel-Integrated-Performance/ippsECCPSetStd-crashes/m-p/1077012#M24679</link>
      <description>&lt;P&gt;HI LSB,&amp;nbsp;&lt;BR /&gt;
	&lt;BR /&gt;
	Can you provide some more information for your problem?&lt;BR /&gt;
	1&amp;gt; IPP version used in your application? &amp;nbsp; &amp;nbsp; 32 bit code or 64 bit code?, &amp;nbsp; how is IPP &amp;nbsp;linked in the application, &amp;nbsp;used in kernel mode, or user mode, etc.&lt;/P&gt;

&lt;P&gt;2&amp;gt; Do you have a standalone code that can help to reproduce this issue?&amp;nbsp;&lt;/P&gt;

&lt;P&gt;3&amp;gt; You mentioned "&lt;SPAN style="font-size: 12px; line-height: 16.3636360168457px;"&gt;&amp;nbsp;not even calling the overall newStd_256_ECP function&amp;nbsp;&lt;/SPAN&gt;&lt;SPAN style="font-size: 12px; line-height: 16.3636360168457px;"&gt;at all), it seems as my program hangs"&lt;BR /&gt;
	Does it mean even the code do not call Intel IPP function, it just links with IPP? &amp;nbsp;the program will hang?&amp;nbsp;&lt;/SPAN&gt;&lt;BR /&gt;
	I can only recall one old issue that only linking with IPP may impact the code:&amp;nbsp;&lt;BR /&gt;
	&lt;A href="https://software.intel.com/en-us/forums/intel-integrated-performance-primitives/topic/542786" target="_blank"&gt;https://software.intel.com/en-us/forums/intel-integrated-performance-primitives/topic/542786&lt;/A&gt;&lt;/P&gt;

&lt;P&gt;Will this impact your code?&amp;nbsp;&lt;BR /&gt;
	&lt;BR /&gt;
	Thanks,&lt;BR /&gt;
	Chao&lt;BR /&gt;
	&amp;nbsp;&lt;/P&gt;

&lt;P&gt;&lt;BR /&gt;
	&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Fri, 08 Apr 2016 03:34:02 GMT</pubDate>
      <guid>https://community.intel.com/t5/Intel-Integrated-Performance/ippsECCPSetStd-crashes/m-p/1077012#M24679</guid>
      <dc:creator>Chao_Y_Intel</dc:creator>
      <dc:date>2016-04-08T03:34:02Z</dc:date>
    </item>
    <item>
      <title>Hi,</title>
      <link>https://community.intel.com/t5/Intel-Integrated-Performance/ippsECCPSetStd-crashes/m-p/1077013#M24680</link>
      <description>&lt;P&gt;Hi,&lt;BR /&gt;
	&lt;BR /&gt;
	I think I found the culprit.&lt;BR /&gt;
	On &lt;A href="https://software.intel.com/en-us/node/502779"&gt;https://software.intel.com/en-us/node/502779,&lt;/A&gt; it is stated that AESInit() will return an error if the keylen is different from 16, 24 or 32.&lt;BR /&gt;
	&lt;BR /&gt;
	Unfortunately, I had a selftest that actually tested this (that AES only supports 16, 24 or 32) on our old security-code, where I try to put in a key length of size 40.&lt;BR /&gt;
	This apparently results in an overwrite of internal structures or something somewhere, so that at a certain point later in time, IPP crashes big time (for example when I then call &amp;nbsp;ippsECCPSetStd()).&lt;BR /&gt;
	&lt;BR /&gt;
	Could I recommend a boundery check on incoming parameters in IPP, so that the ippsAesInit() function does NOT try to use data sizes, for which it has not allocated enough memory.&lt;BR /&gt;
	&lt;BR /&gt;
	Putting the 'boundery check' in my own code before calling IPP-AES, saves the day for me (so far at least :-)&lt;/P&gt;

&lt;P&gt;&amp;nbsp;&lt;/P&gt;

&lt;P&gt;- LSB&lt;/P&gt;</description>
      <pubDate>Mon, 11 Apr 2016 09:59:47 GMT</pubDate>
      <guid>https://community.intel.com/t5/Intel-Integrated-Performance/ippsECCPSetStd-crashes/m-p/1077013#M24680</guid>
      <dc:creator>Lars_B_Intel</dc:creator>
      <dc:date>2016-04-11T09:59:47Z</dc:date>
    </item>
  </channel>
</rss>

