Skip go content

AMD SEV

Architecture referenceFeex

AMD Secure Encrypted Virtualization, SEV, dey encrypt virtual-machine memory under platform threat model wey dem define. SEV, SEV-ES and SEV-SNP dey give different capability dem, so person no must treat dem like say dem be di same ting.

Wetin you need know

AMD Secure Encrypted Virtualization, SEV, dey encrypt virtual-machine memory under platform threat model wey dem define. SEV, SEV-ES and SEV-SNP dey give different capability dem, so person no must treat dem like say dem be di same ting.

How e dey work

SEV dey join guest memory encryption with key management wey belong to each VM. SEV-ES dey add protection for guest register state during exit dem, while SEV-SNP dey add stronger mechanism for guest memory integrity and ownership. Firmware, hypervisor, guest support and attestation dey take part for di full confidential-VM setup.

Where e dey useful

Cloud setup fit request confidential-VM type wey get clear support, and check di attestation evidence before e release secret dem. Di application still need secure I/O, peer dem wey dem authenticate, and policy for di platform measurement dem wey e dey accept.

How to check support and enablement

Check di AMD memory-encryption CPUID information and di exact SEV type, den check firmware, host/guest support and attestation through di provider documented interface. Check current AMD security guide for di generation and firmware wey you deploy.

Capability, enablement and enforcement na different ting dem wey person must check separately. Processor fit support protection while di OS, application or virtual-machine policy no turn am on. Database support field no be attestation say running system dey secure.

Wetin di feature no dey guarantee

Common SEV field no dey prove SEV-SNP, current firmware mitigation status or specific attestation service. Encryption alone no be di same as integrity protection, and memory encryption no dey secure every device or network path.

Compatibility and performance inside real life

Keep di OS, firmware and affected runtime current. If protection show compatibility problem, make you use vendor diagnostics and supported update dem first. Broad protection toggle fit affect oda application dem wey no concern am, so e suppose follow clear deployment and recovery policy.

Practical verification checklist

  1. Record di exact processor or platform model plus di application, OS and runtime version dem wey dey involve. Make you keep di exact word dem wey di error or requirement use.
  2. Check di manufacturer reference for dat exact model, den inspect di real capability and enabled state inside di environment where di program dey run.
  3. Compare every single requirement of di binary or backend wey you choose. Name wey resemble am, alias, or broad technology label no reach.
  4. Confirm say di application select di implementation wey dem intend. Use di diagnostics wey dem document and supported fallback if requirement dem no complete.
  5. Make only one supported change at a time, den run di same workload again. Keep di original configuration and recovery way ready.

If dem list di feature but software no fit use am

Start from di exact component wey dey fail. Hardware database dey describe capability wey dem record; di operating system or hypervisor fit show different real environment. If illegal-instruction error happen, you still need to check di exact instruction wey cause di fault and di binary build, because corrupt file or anoda instruction wey no dey supported fit give di same kind problem.

Install di application, driver or runtime version wey get support for dat exact platform, and use di vendor documented baseline or fallback build if e need am. Software update no fit create instruction wey di processor no get. Firmware and security-policy change dem suppose follow di system manufacturer procedure and recovery plan, no be just any common optimization advice.

Sources and scope of dis explanation

AMD Secure Encrypted Virtualization developer resources · AMD64 Architecture Programmer's Manual, Volume 2: System Programming

Dis reference dem establish architectural behavior and software requirement dem. Dem no dey independently verify every feature value for any linked hardware model page. For model support, use dat page manufacturer evidence and check di active system configuration. Dis article no supply benchmark, certification or independent review date.

Sources and verification

Editorial ownership: Feex. No independent review date dey recorded. How we dey do research.

Dis article make sense to you?

Yes or no dey enough. Choose reason if you want, or add short note.

Dis article make sense to you?