On Thu, Feb 29, 2024 at 5:04 PM Daniel P. Berrangé <berra...@redhat.com> wrote:
> On Sat, Feb 24, 2024 at 10:34:55PM +0800, Hyman Huang wrote: > > This patchset introduce GM/T 0018-2012 as a crypto backend driver, > > which is applied for block encryption. Currently, we support SM4 > > cipher algorithm only. > > > > GM/T 0018-2012 is a cryptographic standard issued by the State > > Cryptography Administration of China. Visit https://hbba.sacinfo.org.cn > > search GM/T 0018-2012 for brief introduction. > > > > The objective of the standard is to develop a uniform application > > interface standard for the service-based cryptography device under > > the public key cryptographic infrastructure application framework, > > and to call the cryptography device through this interface to > > provide basic cryptographic services for the uppler layer. For > > more information about contents of the standard, download the > > specificaiton from: > > "https://github.com/guanzhi/GM-Standards/blob/master/GMT密码行标/ > > GMT 00018-2012 密码设备应用接口规范.pdf" > > > > There are two benefits to doing this, at least. > > * Performance - using a cryptography device for block encryption > > offers an opportunity to enhance the input/output > > performance once the hardware is certified > > * Secrecy - hardware manufacturers may fortify cryptography > > equipment with security features, so increasing the > > secrecy of block encryption. > > > > The precise way that vendors implement the standard APIs for data > > encryption using the cryptographic device is uncoupled from the > > GM/T 0018-2012 specification. Thus, if developers enable this > > functionality with the following conditions met, we could accomplish > > the general implementation: > > > > 1. rename the header file provided by vendor to gmt-0018-2012.h > > and copy it to the /usr/include directory. > > 2. rename the dynamic library provided by vendor to > > gmt_0018_2012.so and copy it to the /usr/lib64 or any directory > > that linker could find before compiling QEMU. > > 3. enable crypto_gmt option when compiling QEMU and make the feature > > availiable. > > > > By offering a development package for GM/T 0018-2012, the above > > provisions could be standardized; unfortunately, the hardware > > manufacturer has not completed this task. So developers who don't > > work with the vendor to obtain the cryptography device and related > > library may not be able to test this functionality because the > > standard implementation depends on the cryptography device supplied > > by the hardware vendor. We are hesitant to contribute to this series > > as a result. > > Hmm, yes, that is a pretty unpleasant approach. > > IMHO there really needs to be a reference implementation that is > pure software. eg a gmt_0018_2012.so + header files that simply > Ok, this is a preferred choice but more work should be done for the pure software implementation, we may try it in space time. Thanks for the comments, Yong > uses an existing crypto library. That way applications can build > and test their support for this, without having to have access > to a specific piece of hardware. Hardware vendors should only > have to provide their library impl, not the headers. > With regards, > Daniel > -- > |: https://berrange.com -o- > https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o- > https://fstop138.berrange.com :| > |: https://entangle-photo.org -o- > https://www.instagram.com/dberrange :| > > -- Best regards
