SUSE SolidDriver Compliance Definition
Package is Level 1 and Level 2 supported by SUSE technical support
In order for SUSE Technical Support agents to provide any assistance to customers deploying kernel module updates to SUSE Linux Enterprise installations, the packages must compatible with the standard SUSE installation tools (i.e. YaST, zypper, AutoYaST). This basically means that the updates must be delivered in a proper RPM package as the Kernel Module Package standard does.
SUSE Technical Support does not provide support for compilation of kernel modules. Therefore only pre-built binary packages can be considered SolidDriver Compliant.
Package is Level 3 supportable by SUSE together with the driver vendor
When a customer encounters issues with OS/hardware functionality and a third party kernel module update is involved, SUSE must work together with the vendor of the kernel module update to resolve the issue. Because of this interdependency, joint support agreements between SUSE and the third party vendor must be established that ensure quick, reliable, and competent handling of the customer issue. These agreements and partnerships for providing support for mutual customers are potentially the most important aspect of SolidDriver compliance.
Vendor of the package can be reliably identified
In order to provide proper support to a customer that has installed a third party kernel module update, the vendor behind the update needs to be identified. In addition, the customers need to easily validate the supplying vendor of the kernel module update. The SolidDriver recommends using the Vendor tag in the RPM meta data of the kernel module package to identify the vendor organization. The Vendor tag string should reflect the official name of the company or organization.
Kernel module packages built by the SUSE SolidDriver build service for third parties include a package vendor string in the following format:
Vendor: SUSE PLDP: <Third Party Organization>
For example a KMP built by SUSE for ACME Inc. will have the following Vendor tag:
Vendor: SUSE PLDP: ACME Inc.
This indicates that the package was built using the SUSE SolidDriver build services and the vendor of the code in the package is ACME Inc..
Products that the Package is qualified for are clearly identified
Kernel module updates are usually targeted, tested, and qualified for specific releases of SUSE Linux Enterprise products as well as specific models of hardware products or releases of software products. Clear statements to the end user about the products that the update is qualified for must be provided along with the update itself. It shall be understood that the update is not considered supported by SUSE or the third party vendor when used with products not listed in the documentation provided with the update.
Integrity of the Package can be established
A customer has a kernel module package vendor where the vendor tag lists the name of the vendor that the customer expects the package to come from, the kernel package follows the KMP standard, and the contents look reasonable. But all of this can be easily achieved and faked by a malicious fourth party. In addition the non-malicious case of a user re-building a KMP from source (potentially with unsupported changes) while forgetting to update the version, vendor tag, package description etc… very real. So how does a customer validate that the package at hand is The Real Thing?
SolidDriver compliance requires that all packages are digitally signed with a trusted key. The public key shall be available and able to be validated with a reasonably high level of confidence by the end user. The user will be expected to trust this key (either temporarily, or permanently) by importing it into the SUSE package management system before or while installing the signed package.
SolidDriver compliance does not take any steps in validating the integrity or security of the package signing keys used by third parties. This is the task of the third party. SUSE can provide support to third parties in helping to setup and use package signing key in a secure manner.
All five criteria listed above are essential for ensuring to the end user that the kernel module update they will deploy will not impact the supportability or integrity of the systems they depend on.