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.

After all, we uploaded this series with the intention of receiving
feedback, as the title suggests. We would welcome any suggestions
and feedback regarding this feature. 

Hyman Huang (3):
  crypto: Introduce GM/T 0018-2012 cryptographic driver
  meson.build: Support GM/T 0018-2012 cryptographic standard
  crypto: Allow GM/T 0018-2012 to support SM4 cipher algorithm

 MAINTAINERS                   |   3 +-
 crypto/block-luks.c           |   4 +-
 crypto/cipher-gmt.c           | 263 ++++++++++++++++++++++++++++++++++
 crypto/cipher.c               |   6 +-
 crypto/cipherpriv.h           |   6 +
 crypto/meson.build            |   3 +
 meson.build                   |  30 ++++
 meson_options.txt             |   2 +
 scripts/meson-buildoptions.sh |   3 +
 9 files changed, 315 insertions(+), 5 deletions(-)
 create mode 100644 crypto/cipher-gmt.c

-- 
2.39.3

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
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 :|

On Thu, Feb 29, 2024 at 5:04 PM Daniel P. Berrangé <berrange@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