Sign Up
Log In
Log In
or
Sign Up
Places
All Projects
Status Monitor
Collapse sidebar
openSUSE:Leap:15.5:Update
secvarctl
secvarctl.spec
Overview
Repositories
Revisions
Requests
Users
Attributes
Meta
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
Locations
Projects
Search
Status Monitor
Help
OpenBuildService.org
Documentation
API Documentation
Code of Conduct
Contact
Support
@OBShq
Terms
openSUSE Build Service is sponsored by
The Open Build Service is an
openSUSE project
.
Sign Up
Log In
Places
Places
All Projects
Status Monitor