File secvarctl.spec of Package secvarctl

#
# spec file for package secvarctl
#
# Copyright (c) 2021 SUSE LLC
#
# All modifications and additions to the file contributed by third parties
# remain the property of their copyright owners, unless otherwise agreed
# upon. The license for this file, and modifications and additions to the
# file, is the same license as for the pristine package itself (unless the
# license for the pristine package is not an Open Source License, in which
# case the license is the MIT License). An "Open Source License" is a
# license that conforms to the Open Source Definition (Version 1.9)
# published by the Open Source Initiative.

# Please submit bugfixes or comments via https://bugs.opensuse.org/
#


Name:           secvarctl
Version:        0.3
Release:        0
Summary:        Suite of tools to manipulate and generate Secure Boot variables on POWER
License:        Apache-2.0
URL:            https://github.com/open-power/secvarctl
Source:         https://github.com/open-power/secvarctl/archive/v%{version}.tar.gz#/%{name}-%{version}.tar.gz
BuildRequires:  openssl-devel
ExclusiveArch:  ppc64 ppc64le

%description
The purpose of this tool is to simplify and automate the process of reading and writing secure boot keys.
secvarctl allows the user to communicate, via terminal commands, with the keys efficiently.

Secure Variables are responsible for loading the target OS/hypervisor during Secure Boot. There are currently four secure variables in the Secure Boot process: The Platform Key (PK), Key Exchange Key (KEK), Database Key (db) and Blocklist Key (dbx).The PK serves as the root key, usually supplied by platform owner, if there is no PK then Secure Boot is not enabled. The PK has authority over all other keys. The KEK is usually provided by the OS vendor and has authority over the db and dbx. The db has authority over the kernels and other user specific firmware. The dbx has authority over kernels and specific firmware that are not to be loaded.

Updating of these secure variables requires a specific format for success. If updating the PK, KEK or db, an x509 public key must be contained in an EFI Signature List (ESL). If updating the dbx, the binary that is to be banned must be hashed and placed in an ESL. Then, a PKCS7 structure must be generated by signing the new ESL with the private key of a secure variable that has authority over the variable being updated (Example: if updating the db, the new ESL must be signed by either the KEK or PK). Finally, the new ESL must be appended to the generated PKCS7 and the whole structure is then placed into what is called an Auth file (this adds extra header information, timestamp and content size). When the Auth file is generated, the resulting file is ready to be submited. Once submitted, the update is only applied when the POWER machine is rebooted.

%prep
%setup -q

%build
%make_build OPENSSL=1 DEBUG=1

%install
%make_install OPENSSL=1 DEBUG=1

%files
%license LICENSE
%doc README.md
%{_bindir}/secvarctl
%{_mandir}/man1/secvarctl.1%{?ext_man}

%changelog
Places

File secvarctl.spec of Package secvarctl

Places
