Added 2 other bugs that will be resolved by this rebase.

Upstream has already generated the sevctl-0.0.2, now it's just doing the rebase.

Build started, https://kojihub.stream.rdu2.redhat.com/koji/taskinfo?taskID=916584 - working thru issues

Build completed: https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=1873007

Note: One mistake that was made was that I forgot to change the release number from 4 to 1.

So, this build indicates that it is sevctl-0.2.0-*4* instead of sevctl-0.2.0-*1*.

I can create an errata and do the `attach build`

sevctl-0.2.0-4.el9 unit test failed, test snp_platform_status ... FAILED on Milan.

Version:
sevctl-0.2.0-4.el9.x86_64
qemu-kvm-6.2.0-3.el9.x86_64


Hi Tyler, could you please help to check if this is a bug?

Steps:
Sevctl unit test:
# rpm2cpio ./sevctl-0.2.0-4.el9.src.rpm | cpio -idmv
# tar xvfz sevctl-0.2.0-vendor.tar.gz
# cd sevctl-0.2.0-vendor/sev/
# cargo test --features=hw_tests,openssl --test api
    Finished test [unoptimized + debuginfo] target(s) in 0.04s
     Running tests/api.rs (target/debug/deps/api-2fd9ed450b0596dc)

running 9 tests
test pdh_generate ... ignored
test pek_cert_import ... ignored
test pek_generate ... ignored
test platform_reset ... ignored
test get_identifier ... ok
test pek_csr ... ok
test platform_status ... ok
test snp_platform_status ... FAILED
test pdh_cert_export ... ok

failures:

---- snp_platform_status stdout ----
thread 'snp_platform_status' panicked at 'called `Result::unwrap()` on an `Err` value: Known(IoError(Os { code: 22, kind: InvalidInput, message: "Invalid argument" }))', tests/api.rs:127:43
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace


failures:
    snp_platform_status

test result: FAILED. 4 passed; 1 failed; 4 ignored; 0 measured; 0 filtered out; finished in 0.01s

error: test failed, to rerun pass '--test api'

Hi!

What platform are you running these tests on? That test should only be passing if SNP is available and configured on the host. If not set-up, this would be expected to fail.

The fact that snp_platform_status is failing leads me to believe that SNP is not configured properly on the system, and this is right to fail. Nonetheless, the test you are running is not a sevctl-specific test, but a test inside of the sev library (which is a dependency of sevctl).

What are the specifics of SNP on the system (build, firmware versions?)

(In reply to Tyler Fanelli from comment #11)
> The fact that snp_platform_status is failing leads me to believe that SNP is
> not configured properly on the system, and this is right to fail.
> Nonetheless, the test you are running is not a sevctl-specific test, but a
> test inside of the sev library (which is a dependency of sevctl).
> 
> What are the specifics of SNP on the system (build, firmware versions?)

I didn't config SNP on the host, since the current kernel/qemu don't support SNP. The firmware is the latest.

Version:
BIOS Information
	Vendor: Dell Inc.
	Version: 2.5.6
	Release Date: 10/06/2021
	Address: 0xF0000
kernel-5.14.0-39.el9.x86_64

I find there is a new sevctl cmd #sevctl ok snp, after execute this cmd, the cargo test still failed. Does this #sevctl ok snp passed means snp_platform_status test should succeed?

$ sevctl ok snp
[ PASS ] - AMD CPU
[ PASS ]   - Microcode support
[ PASS ]   - Secure Memory Encryption (SME)
[ PASS ]   - Secure Encrypted Virtualization (SEV)
[ PASS ]     - Encrypted State (SEV-ES)
[ PASS ]     - Secure Nested Paging (SEV-SNP)
[ PASS ]       - VM Permission Levels
[ PASS ]         - Number of VMPLs: 4
[ PASS ]     - Physical address bit reduction: 51
[ PASS ]     - C-bit location: 51
[ PASS ]     - Number of encrypted guests supported simultaneously: 509
[ PASS ]     - Minimum ASID value for SEV-enabled, SEV-ES disabled guest: 100
[ PASS ]     - SEV enabled in KVM: enabled
[ PASS ]     - Reading /dev/sev: /dev/sev readable
[ PASS ]     - Writing /dev/sev: /dev/sev writable
[ PASS ]   - Page flush MSR
[ PASS ] - KVM supported: API version: 12
[ PASS ] - Memlock resource limit: Soft: 65536 | Hard: 65536
$ cargo test --features=hw_tests,openssl --test api
    Finished test [unoptimized + debuginfo] target(s) in 0.04s
     Running tests/api.rs (target/debug/deps/api-2fd9ed450b0596dc)

running 9 tests
test pdh_generate ... ignored
test pek_cert_import ... ignored
test pek_generate ... ignored
test platform_reset ... ignored
test get_identifier ... ok
test platform_status ... ok
test pek_csr ... ok
test snp_platform_status ... FAILED
test pdh_cert_export ... ok

failures:

---- snp_platform_status stdout ----
thread 'snp_platform_status' panicked at 'called `Result::unwrap()` on an `Err` value: Known(IoError(Os { code: 22, kind: InvalidInput, message: "Invalid argument" }))', tests/api.rs:127:43
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace


failures:
    snp_platform_status

test result: FAILED. 4 passed; 1 failed; 4 ignored; 0 measured; 0 filtered out; finished in 0.01s

error: test failed, to rerun pass '--test api'

Perhaps showing output of a run with `RUST_BACKTRACE=1` as shown in the output may help.

Let's remember that AMD-SNP is still evolving (requires a special kernel build at this point) and the issue could be some sort of mismatch.

Maybe we should just log the details in a separate bug.

(In reply to zixchen from comment #13)
> I find there is a new sevctl cmd #sevctl ok snp, after execute this cmd, the
> cargo test still failed. Does this #sevctl ok snp passed means
> snp_platform_status test should succeed?
> 


Not necessarily, that test indicates that your *processor* is SNP capable. For that snp_platform_status test to pass, SNP would have to be fully enabled in kernel/firmware/etc... On SNP-configured Milan machines I use for testing, I don't get an error here.

Thanks Tyler and John, snp_platform_status failed has been waived in the gating test.

Test new sevctl cmd, no issue found, move to verified.
Verison:
sevctl-0.2.0-4.el9.x86_64
qemu-kvm-6.2.0-3.el9.x86_64
kernel-5.14.0-39.el9.x86_64

Steps and results:
1. sevctl provision
$ sevctl generate  /home/sev.cert /home/sev.key
$ sevctl provision  /home/sev.cert /home/sev.key
$ sevctl verify
PDH EP384 D256 9ea92dae99563355df0b55df11620cbe36e1ef06ea6a4a918691c42ae3924edd
 ⬑ PEK EP384 E256 9cdc60ec2ecd2f5ef5346e0fe9aa142edc3194115b3bd8b8ece6364f681cfebe
   •⬑ OCA EP384 E256 c1fe2c649ec41f4bd25367373636277c30791402870a768bdb7c07430d50546e
    ⬑ CEK EP384 E256 d0b2ef7f505777a732898b7215b5ee666e6dd65599844352ca242878086c4367
       ⬑ ASK R4096 R384 95cba79ba3c77daea79f741bade8156a50b1c59f6d6fda104d16dd264729f5ee8989522f3711fc7c84719921ceb31bc0
         •⬑ ARK R4096 R384 569da618dfe64015c343db6d975e77b72fdeacd16edd02d9d09b889b8f0f1d91ffa5dfbd86f7ac574a1a7883b7a1e737

 • = self signed, ⬑ = signs, •̷ = invalid self sign, ⬑̸ = invalid signs
2. sevctl ok
on Mialn $ sevctl ok
[ PASS ] - AMD CPU
[ PASS ]   - Microcode support
[ PASS ]   - Secure Memory Encryption (SME)
[ PASS ]   - Secure Encrypted Virtualization (SEV)
[ PASS ]     - Encrypted State (SEV-ES)
[ PASS ]     - Secure Nested Paging (SEV-SNP)
[ PASS ]       - VM Permission Levels
[ PASS ]         - Number of VMPLs: 4
[ PASS ]     - Physical address bit reduction: 51
[ PASS ]     - C-bit location: 51
[ PASS ]     - Number of encrypted guests supported simultaneously: 509
[ PASS ]     - Minimum ASID value for SEV-enabled, SEV-ES disabled guest: 100
[ PASS ]     - SEV enabled in KVM: enabled
[ PASS ]     - Reading /dev/sev: /dev/sev readable
[ PASS ]     - Writing /dev/sev: /dev/sev writable
[ PASS ]   - Page flush MSR
[ PASS ] - KVM supported: API version: 12
[ PASS ] - Memlock resource limit: Soft: 65536 | Hard: 65536
on Rome # sevctl ok
[ PASS ] - AMD CPU
[ PASS ]   - Microcode support
[ PASS ]   - Secure Memory Encryption (SME)
[ PASS ]   - Secure Encrypted Virtualization (SEV)
[ PASS ]     - Encrypted State (SEV-ES)
[ FAIL ]     - Secure Nested Paging (SEV-SNP)
[ SKIP ]       - VM Permission Levels
[ SKIP ]         - Number of VMPLs
[ PASS ]     - Physical address bit reduction: 47
[ PASS ]     - C-bit location: 47
[ PASS ]     - Number of encrypted guests supported simultaneously: 509
[ PASS ]     - Minimum ASID value for SEV-enabled, SEV-ES disabled guest: 99
[ PASS ]     - SEV enabled in KVM: enabled
[ PASS ]     - Reading /dev/sev: /dev/sev readable
[ PASS ]     - Writing /dev/sev: /dev/sev writable
[ PASS ]   - Page flush MSR
[ PASS ] - KVM supported: API version: 12
[ PASS ] - Memlock resource limit: Soft: 65536 | Hard: 65536
error: One or more tests in sevctl-ok reported a failure
caused by: invalid data

Moving back to MODIFIED in order to go through the Errata process

Updated the Fixed in Version and changed DTM=24 to avoid the RHEL bot messages since it's expected to work through Errata Tool by Monday.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (new packages: sevctl), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:2431