195 lines
10 KiB
HTML
195 lines
10 KiB
HTML
|
<?xml version="1.0" ?>
|
||
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
||
|
<html xmlns="http://www.w3.org/1999/xhtml">
|
||
|
<head>
|
||
|
<title>OPENSSL_ia32cap</title>
|
||
|
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
|
||
|
<link rev="made" href="mailto:root@localhost" />
|
||
|
</head>
|
||
|
|
||
|
<body style="background-color: white">
|
||
|
|
||
|
|
||
|
<!-- INDEX BEGIN -->
|
||
|
<div name="index">
|
||
|
<p><a name="__index__"></a></p>
|
||
|
|
||
|
<ul>
|
||
|
|
||
|
<li><a href="#name">NAME</a></li>
|
||
|
<li><a href="#synopsis">SYNOPSIS</a></li>
|
||
|
<li><a href="#description">DESCRIPTION</a></li>
|
||
|
<li><a href="#notes">NOTES</a></li>
|
||
|
<li><a href="#return_values">RETURN VALUES</a></li>
|
||
|
<li><a href="#copyright">COPYRIGHT</a></li>
|
||
|
</ul>
|
||
|
|
||
|
<hr name="index" />
|
||
|
</div>
|
||
|
<!-- INDEX END -->
|
||
|
|
||
|
<p>
|
||
|
</p>
|
||
|
<hr />
|
||
|
<h1><a name="name">NAME</a></h1>
|
||
|
<p>OPENSSL_ia32cap - the x86[_64] processor capabilities vector</p>
|
||
|
<p>
|
||
|
</p>
|
||
|
<hr />
|
||
|
<h1><a name="synopsis">SYNOPSIS</a></h1>
|
||
|
<pre>
|
||
|
env OPENSSL_ia32cap=... <application></pre>
|
||
|
<p>
|
||
|
</p>
|
||
|
<hr />
|
||
|
<h1><a name="description">DESCRIPTION</a></h1>
|
||
|
<p>OpenSSL supports a range of x86[_64] instruction set extensions. These
|
||
|
extensions are denoted by individual bits in capability vector returned
|
||
|
by processor in EDX:ECX register pair after executing CPUID instruction
|
||
|
with EAX=1 input value (see Intel Application Note #241618). This vector
|
||
|
is copied to memory upon toolkit initialization and used to choose
|
||
|
between different code paths to provide optimal performance across wide
|
||
|
range of processors. For the moment of this writing following bits are
|
||
|
significant:</p>
|
||
|
<dl>
|
||
|
<dt><strong><a name="bit_4_denoting_presence_of_time_stamp_counter" class="item">bit #4 denoting presence of Time-Stamp Counter.</a></strong></dt>
|
||
|
|
||
|
<dt><strong><a name="bit_19_denoting_availability_of_clflush_instruction" class="item">bit #19 denoting availability of CLFLUSH instruction;</a></strong></dt>
|
||
|
|
||
|
<dt><strong><a name="bit_20_reserved_by_intel_is_used_to_choose_among_rc4_code_paths" class="item">bit #20, reserved by Intel, is used to choose among RC4 code paths;</a></strong></dt>
|
||
|
|
||
|
<dt><strong><a name="bit_23_denoting_mmx_support" class="item">bit #23 denoting MMX support;</a></strong></dt>
|
||
|
|
||
|
<dt><strong><a name="bit_24_fxsr_bit_denoting_availability_of_xmm_registers" class="item">bit #24, FXSR bit, denoting availability of XMM registers;</a></strong></dt>
|
||
|
|
||
|
<dt><strong><a name="bit_25_denoting_sse_support" class="item">bit #25 denoting SSE support;</a></strong></dt>
|
||
|
|
||
|
<dt><strong><a name="bit_26_denoting_sse2_support" class="item">bit #26 denoting SSE2 support;</a></strong></dt>
|
||
|
|
||
|
<dt><strong><a name="bit_28_denoting_hyperthreading_which_is_used_to_distinguish_cores_with_shared_cache" class="item">bit #28 denoting Hyperthreading, which is used to distinguish
|
||
|
cores with shared cache;</a></strong></dt>
|
||
|
|
||
|
<dt><strong><a name="bit_30_reserved_by_intel_denotes_specifically_intel_cpus" class="item">bit #30, reserved by Intel, denotes specifically Intel CPUs;</a></strong></dt>
|
||
|
|
||
|
<dt><strong><a name="bit_33_denoting_availability_of_pclmulqdq_instruction" class="item">bit #33 denoting availability of PCLMULQDQ instruction;</a></strong></dt>
|
||
|
|
||
|
<dt><strong><a name="bit_41_denoting_ssse3_supplemental_sse3_support" class="item">bit #41 denoting SSSE3, Supplemental SSE3, support;</a></strong></dt>
|
||
|
|
||
|
<dt><strong><a name="support" class="item">bit #43 denoting AMD XOP support (forced to zero on non-AMD CPUs);</a></strong></dt>
|
||
|
|
||
|
<dt><strong><a name="bit_54_denoting_availability_of_movbe_instruction" class="item">bit #54 denoting availability of MOVBE instruction;</a></strong></dt>
|
||
|
|
||
|
<dt><strong><a name="bit_57_denoting_aes_ni_instruction_set_extension" class="item">bit #57 denoting AES-NI instruction set extension;</a></strong></dt>
|
||
|
|
||
|
<dt><strong><a name="bit_58_xsave_bit_lack_of_which_in_combination_with_movbe_is_used_to_identify_atom_silvermont_core" class="item">bit #58, XSAVE bit, lack of which in combination with MOVBE is used
|
||
|
to identify Atom Silvermont core;</a></strong></dt>
|
||
|
|
||
|
<dt><strong><a name="bit_59_osxsave_bit_denoting_availability_of_ymm_registers" class="item">bit #59, OSXSAVE bit, denoting availability of YMM registers;</a></strong></dt>
|
||
|
|
||
|
<dt><strong><a name="bit_60_denoting_avx_extension" class="item">bit #60 denoting AVX extension;</a></strong></dt>
|
||
|
|
||
|
<dt><strong><a name="bit_62_denoting_availability_of_rdrand_instruction" class="item">bit #62 denoting availability of RDRAND instruction;</a></strong></dt>
|
||
|
|
||
|
</dl>
|
||
|
<p>For example, in 32-bit application context clearing bit #26 at run-time
|
||
|
disables high-performance SSE2 code present in the crypto library, while
|
||
|
clearing bit #24 disables SSE2 code operating on 128-bit XMM register
|
||
|
bank. You might have to do the latter if target OpenSSL application is
|
||
|
executed on SSE2 capable CPU, but under control of OS that does not
|
||
|
enable XMM registers. Historically address of the capability vector copy
|
||
|
was exposed to application through OPENSSL_ia32cap_loc(), but not
|
||
|
anymore. Now the only way to affect the capability detection is to set
|
||
|
<strong>OPENSSL_ia32cap</strong> environment variable prior target application start. To
|
||
|
give a specific example, on Intel P4 processor
|
||
|
<code>env OPENSSL_ia32cap=0x16980010 apps/openssl</code>, or better yet
|
||
|
<code>env OPENSSL_ia32cap=~0x1000000 apps/openssl</code> would achieve the desired
|
||
|
effect. Alternatively you can reconfigure the toolkit with no-sse2
|
||
|
option and recompile.</p>
|
||
|
<p>Less intuitive is clearing bit #28, or ~0x10000000 in the "environment
|
||
|
variable" terms. The truth is that it's not copied from CPUID output
|
||
|
verbatim, but is adjusted to reflect whether or not the data cache is
|
||
|
actually shared between logical cores. This in turn affects the decision
|
||
|
on whether or not expensive countermeasures against cache-timing attacks
|
||
|
are applied, most notably in AES assembler module.</p>
|
||
|
<p>The capability vector is further extended with EBX value returned by
|
||
|
CPUID with EAX=7 and ECX=0 as input. Following bits are significant:</p>
|
||
|
<dl>
|
||
|
<dt><strong><a name="bit_64_3_denoting_availability_of_bmi1_instructions_e_g_andn" class="item">bit #64+3 denoting availability of BMI1 instructions, e.g. ANDN;</a></strong></dt>
|
||
|
|
||
|
<dt><strong><a name="bit_64_5_denoting_availability_of_avx2_instructions" class="item">bit #64+5 denoting availability of AVX2 instructions;</a></strong></dt>
|
||
|
|
||
|
<dt><strong><a name="bit_64_8_denoting_availability_of_bmi2_instructions_e_g_mulx_and_rorx" class="item">bit #64+8 denoting availability of BMI2 instructions, e.g. MULX
|
||
|
and RORX;</a></strong></dt>
|
||
|
|
||
|
<dt><strong><a name="bit_64_16_denoting_availability_of_avx512f_extension" class="item">bit #64+16 denoting availability of AVX512F extension;</a></strong></dt>
|
||
|
|
||
|
<dt><strong><a name="bit_64_18_denoting_availability_of_rdseed_instruction" class="item">bit #64+18 denoting availability of RDSEED instruction;</a></strong></dt>
|
||
|
|
||
|
<dt><strong><a name="bit_64_19_denoting_availability_of_adcx_and_adox_instructions" class="item">bit #64+19 denoting availability of ADCX and ADOX instructions;</a></strong></dt>
|
||
|
|
||
|
<dt><strong><a name="bit_64_21_denoting_availability_of_vpmadd52_lh_uq_instructions_a_k_a_avx512ifma_extension" class="item">bit #64+21 denoting availability of VPMADD52[LH]UQ instructions,
|
||
|
a.k.a. AVX512IFMA extension;</a></strong></dt>
|
||
|
|
||
|
<dt><strong><a name="bit_64_29_denoting_availability_of_sha_extension" class="item">bit #64+29 denoting availability of SHA extension;</a></strong></dt>
|
||
|
|
||
|
<dt><strong><a name="bit_64_30_denoting_availability_of_avx512bw_extension" class="item">bit #64+30 denoting availability of AVX512BW extension;</a></strong></dt>
|
||
|
|
||
|
<dt><strong><a name="bit_64_31_denoting_availability_of_avx512vl_extension" class="item">bit #64+31 denoting availability of AVX512VL extension;</a></strong></dt>
|
||
|
|
||
|
<dt><strong><a name="bit_64_41_denoting_availability_of_vaes_extension" class="item">bit #64+41 denoting availability of VAES extension;</a></strong></dt>
|
||
|
|
||
|
<dt><strong><a name="bit_64_42_denoting_availability_of_vpclmulqdq_extension" class="item">bit #64+42 denoting availability of VPCLMULQDQ extension;</a></strong></dt>
|
||
|
|
||
|
</dl>
|
||
|
<p>To control this extended capability word use <code>:</code> as delimiter when
|
||
|
setting up <strong>OPENSSL_ia32cap</strong> environment variable. For example assigning
|
||
|
<code>:~0x20</code> would disable AVX2 code paths, and <code>:0</code> - all post-AVX
|
||
|
extensions.</p>
|
||
|
<p>It should be noted that whether or not some of the most "fancy"
|
||
|
extension code paths are actually assembled depends on current assembler
|
||
|
version. Base minimum of AES-NI/PCLMULQDQ, SSSE3 and SHA extension code
|
||
|
paths are always assembled. Apart from that, minimum assembler version
|
||
|
requirements are summarized in below table:</p>
|
||
|
<pre>
|
||
|
Extension | GNU as | nasm | llvm
|
||
|
------------+--------+--------+--------
|
||
|
AVX | 2.19 | 2.09 | 3.0
|
||
|
AVX2 | 2.22 | 2.10 | 3.1
|
||
|
ADCX/ADOX | 2.23 | 2.10 | 3.3
|
||
|
AVX512 | 2.25 | 2.11.8 | see NOTES
|
||
|
AVX512IFMA | 2.26 | 2.11.8 | see NOTES
|
||
|
VAES | 2.30 | 2.13.3 |</pre>
|
||
|
<p>
|
||
|
</p>
|
||
|
<hr />
|
||
|
<h1><a name="notes">NOTES</a></h1>
|
||
|
<p>Even though AVX512 support was implemented in llvm 3.6, compilation of
|
||
|
assembly modules apparently requires explicit -march flag. But then
|
||
|
compiler generates processor-specific code, which in turn contradicts
|
||
|
the mere idea of run-time switch execution facilitated by the variable
|
||
|
in question. Till the limitation is lifted, it's possible to work around
|
||
|
the problem by making build procedure use following script:</p>
|
||
|
<pre>
|
||
|
#!/bin/sh
|
||
|
exec clang -no-integrated-as "$@"</pre>
|
||
|
<p>instead of real clang. In which case it doesn't matter which clang
|
||
|
version is used, as it is GNU assembler version that will be checked.</p>
|
||
|
<p>
|
||
|
</p>
|
||
|
<hr />
|
||
|
<h1><a name="return_values">RETURN VALUES</a></h1>
|
||
|
<p>Not available.</p>
|
||
|
<p>
|
||
|
</p>
|
||
|
<hr />
|
||
|
<h1><a name="copyright">COPYRIGHT</a></h1>
|
||
|
<p>Copyright 2004-2018 The OpenSSL Project Authors. All Rights Reserved.</p>
|
||
|
<p>Licensed under the Apache License 2.0 (the "License"). You may not use
|
||
|
this file except in compliance with the License. You can obtain a copy
|
||
|
in the file LICENSE in the source distribution or at
|
||
|
<a href="https://www.openssl.org/source/license.html">https://www.openssl.org/source/license.html</a>.</p>
|
||
|
|
||
|
</body>
|
||
|
|
||
|
</html>
|