The soname is equal to current minus age. In version 2.31.0 current is 2 and age is set to 0. In version 2.31.1 current is 2 and age is set to 1. This means the soname goes backwards from 2 to 1. The full library version changes from 2.0.31 to 1.1.31 The soname should not go backwards, so this soname change looks like a mistake that should be reverted. The current, revision, age for a library should change in one of three ways: 1) increase current by one, reset revision and age to 0. 2) increase current by one, reset revision to 0 and increase age by 1. 3) increase revision by 1, retain the values of current and age. 1) is for non-backward compatible changes to the library (changes or removals to the old ABI). Soname changes and applications using the library must be recompiled. 2) is for when there are ABI additions to the library, but no ABI changes or removals. Application compiled against the old version of the library don't need to be recompiled, and the soname (current minus age) does not change. 3) is for minor updates with no ABI additions, changes or removals. The major, minor, patch version of the software project should not be used as current, revision, age for the library. Especially true for using the patch version as age, because that means the soname goes backwards for patch releases as happened here. Signed-off-by: Mattias Ellert <mattias.ellert@physics.uu.se>
Intel(R) Intelligent Storage Acceleration Library
ISA-L is a collection of optimized low-level functions targeting storage applications. ISA-L includes:
- Erasure codes - Fast block Reed-Solomon type erasure codes for any encode/decode matrix in GF(2^8).
- CRC - Fast implementations of cyclic redundancy check. Six different
polynomials supported.
- iscsi32, ieee32, t10dif, ecma64, iso64, jones64, rocksoft64.
- Raid - calculate and operate on XOR and P+Q parity found in common RAID implementations.
- Compression - Fast deflate-compatible data compression.
- De-compression - Fast inflate-compatible data compression.
- igzip - A command line application like gzip, accelerated with ISA-L.
Also see:
- ISA-L for updates.
- For crypto functions see isa-l_crypto on github.
- The github wiki including a list of distros/ports offering binary packages as well as a list of language bindings.
- Contributing.
- Security Policy.
- Docs on units, tests, or build details.
Building ISA-L
Prerequisites
- Make: GNU 'make' or 'nmake' (Windows).
- Optional: Building with autotools requires autoconf/automake/libtool packages.
- Optional: Manual generation requires help2man package.
x86_64:
- Assembler: nasm. Version 2.15 or later suggested (other versions of nasm and yasm may build but with limited function support).
- Compiler: gcc, clang, icc or VC compiler.
aarch64:
- Assembler: gas v2.24 or later.
- Compiler: gcc v4.7 or later.
other:
- Compiler: Portable base functions are available that build with most C compilers.
Autotools
To build and install the library with autotools it is usually sufficient to run:
./autogen.sh
./configure
make
sudo make install
Makefile
To use a standard makefile run:
make -f Makefile.unx
Windows
On Windows use nmake to build dll and static lib:
nmake -f Makefile.nmake
or see details on setting up environment here.
Other make targets
Other targets include:
make check
: create and run testsmake tests
: create additional unit testsmake perfs
: create included performance testsmake ex
: build examplesmake other
: build other utilities such as compression file testsmake doc
: build API manual
DLL Injection Attack
Problem
The Windows OS has an insecure predefined search order and set of defaults when trying to locate a resource. If the resource location is not specified by the software, an attacker need only place a malicious version in one of the locations Windows will search, and it will be loaded instead. Although this weakness can occur with any resource, it is especially common with DLL files.
Solutions
Applications using libisal DLL library may need to apply one of the solutions to prevent from DLL injection attack.
Two solutions are available:
- Using a Fully Qualified Path is the most secure way to load a DLL
- Signature verification of the DLL
Resources and Solution Details
- Security remarks section of LoadLibraryEx documentation by Microsoft: https://docs.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-loadlibraryexa#security-remarks
- Microsoft Dynamic Link Library Security article: https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-security
- Hijack Execution Flow: DLL Search Order Hijacking: https://attack.mitre.org/techniques/T1574/001
- Hijack Execution Flow: DLL Side-Loading: https://attack.mitre.org/techniques/T1574/002