On Wed, 24 Mar 2021 at 19:37, Ahmad Fatoum wrote:
>
> Hello Sumit,
>
> On 24.03.21 11:47, Sumit Garg wrote:
> > On Wed, 24 Mar 2021 at 14:56, Ahmad Fatoum wrote:
> >>
> >> Hello Mimi,
> >>
> >> On 23.03.21 19:07, Mimi Zohar wrote:
> >>> On Tue, 2021-03-23 at 17:35 +0100, Ahmad Fatoum wrote:
> >>>
Thinks, there is a similar patch to yours that was send in advance:
https://www.spinics.net/lists/linux-crypto/msg54238.html
On 2021/3/24 22:42, 'Wei Yongjun wrote:
From: Wei Yongjun
GCC reports build error as following:
x86_64-linux-gnu-ld: drivers/crypto/hisilicon/hpre/hpre_crypto.o: in fun
On Wed, 2021-03-24 at 16:49 -0400, Mimi Zohar wrote:
> On Wed, 2021-03-24 at 09:14 -0700, James Bottomley wrote:
> > On Tue, 2021-03-23 at 14:07 -0400, Mimi Zohar wrote:
> > > On Tue, 2021-03-23 at 17:35 +0100, Ahmad Fatoum wrote:
> > > > Hello Horia,
> > > >
> > > > On 21.03.21 21:48, Horia Geant
On Wed, 2021-03-24 at 09:14 -0700, James Bottomley wrote:
> On Tue, 2021-03-23 at 14:07 -0400, Mimi Zohar wrote:
> > On Tue, 2021-03-23 at 17:35 +0100, Ahmad Fatoum wrote:
> > > Hello Horia,
> > >
> > > On 21.03.21 21:48, Horia Geantă wrote:
> > > > On 3/16/2021 7:02 PM, Ahmad Fatoum wrote:
> > >
On 3/24/21 12:47 PM, Andy Lutomirski wrote:
> On Wed, Mar 24, 2021 at 10:04 AM Brijesh Singh wrote:
>> If hardware detects an RMP violation, it will raise a page-fault exception
>> with the RMP bit set. To help the debug, dump the RMP entry of the faulting
>> address.
>>
>> Cc: Thomas Gleixner
> diff --git a/arch/x86/include/asm/trap_pf.h b/arch/x86/include/asm/trap_pf.h
> index 10b1de500ab1..107f9d947e8d 100644
> --- a/arch/x86/include/asm/trap_pf.h
> +++ b/arch/x86/include/asm/trap_pf.h
> @@ -12,6 +12,7 @@
> * bit 4 ==1: fault was an instruction
> f
On Wed, Mar 24, 2021 at 10:04 AM Brijesh Singh wrote:
>
> If hardware detects an RMP violation, it will raise a page-fault exception
> with the RMP bit set. To help the debug, dump the RMP entry of the faulting
> address.
>
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
> Cc: Joe
Follow the recommendation from APM2 section 15.36.10 and 15.36.11 to
resolve the RMP violation encountered during the NPT table walk.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: Joerg Roedel
Cc: "H. Peter Anvin"
Cc: Tony Luck
Cc: Dave Hansen
Cc: "Peter Zijlstra (Intel)"
Cc:
SEV-SNP VMs can ask the hypervisor to change the page state in the RMP
table to be private or shared using the Page State Change NAE event
as defined in the GHCB specification section 4.1.6.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: Joerg Roedel
Cc: "H. Peter Anvin"
Cc: Tony
The SEV-SNP VMs may call the page state change VMGEXIT to add the GPA
as private or shared in the RMP table. The page state change VMGEXIT
will contain the RMP page level to be used in the RMP entry. If the
page level between the TDP and RMP does not match then, it will result
in nested-page-fault
SEV-SNP VMs can ask the hypervisor to change the page state in the RMP
table to be private or shared using the Page State Change MSR protocol
as defined in the GHCB specification section 2.5.1.
Before changing the page state in the RMP entry, we lookup the page in
the TDP to make sure that there i
When SEV-SNP is enabled globally, the hardware places restrictions on all
memory accesses based on the RMP entry, whether the hyperviso or a VM,
performs the accesses. When hardware encounters an RMP access violation
during a guest access, it will cause a #VMEXIT(NPF).
See APM2 section 16.36.10 fo
While resolving the RMP page fault, we may run into cases where the page
level between the RMP entry and TDP does not match and the 2M RMP entry
must be split into 4K RMP entries. Or a 2M TDP page need to be broken
into multiple of 4K pages.
To keep the RMP and TDP page level in sync, we will zap
SEV-SNP guests are required to perform a GHCB GPA registration (see
section 2.5.2 in GHCB specification). Before using a GHCB GPA for a vCPU
the first time, a guest must register the vCPU GHCB GPA. If hypervisor
can work with the guest requested GPA then it must respond back with the
same GPA other
When running an SEV-SNP VM, the sPA used to index the RMP entry is
obtained through the TDP translation (gva->gpa->spa). The TDP page
level is checked against the page level programmed in the RMP entry.
If the page level does not match, then it will cause a nested page
fault with the RMP bit set to
The page-fault error code is a 64-bit value, but the trace prints only
the lower 32-bits. Some of the SEV-SNP RMP fault error codes are
available in the upper 32-bits.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: Joerg Roedel
Cc: "H. Peter Anvin"
Cc: Tony Luck
Cc: Dave Hansen
Introduce a helper to directly fault-in a TDP page without going
through the full page fault path. This allows SEV-SNP to build
the netsted-page-table while handling the page state change VMGEXIT.
A guest may issue a page state change VMGEXIT before accessing the
page. Creating a fault-in, we can
The guest pages of the SEV-SNP VM maybe added as a private page in the
RMP entry (assigned bit is set). While terminating the guest we must
unassign those pages so that pages are transitioned to the hypervisor
state before they can be freed.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petko
The KVM_SEV_SNP_LAUNCH_FINISH finalize the cryptographic digest and stores
it as the measurement of the guest at launch.
While finalizing the launch flow, it also issues the LAUNCH_UPDATE command
to encrypt the VMSA pages.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: Joerg Roede
The KVM_SEV_SNP_LAUNCH_UPDATE command can be used to insert data into the
guest's memory. The data is encrypted with the cryptographic context
created with the KVM_SEV_SNP_LAUNCH_START.
In addition to the inserting data, it can insert a two special pages
into the guests memory: the secrets page an
KVM_SEV_SNP_LAUNCH_START begins the launch process for an SEV-SNP guest.
The command initializes a cryptographic digest context used to construct the
measurement of the guest. If the guest is expected to be migrated, the
command also binds a migration agent (MA) to the guest.
For more information
When SEV-SNP is globally enabled on a system, the VMRUN instruction
performs additional security checks on AVIC backing, VMSA, and VMCB page.
On a successful VMRUN, these pages are marked "in-use" by the
hardware in the RMP entry, and any attempt to modify the RMP entry for
these pages will result
The hypervisor uses the SEV_FEATURES field (offset 3B0h) in the Save State
Area to control the SEV-SNP guest features such as SNPActive, vTOM,
ReflectVC etc. An SEV-SNP guest can read the SEV_FEATURES fields through
the SEV_STATUS MSR.
See APM2 Table 15-34 and B-4 for more details.
Cc: Thomas Gle
The KVM_SNP_INIT command is used by the hypervisor to initialize the
SEV-SNP platform context. In a typical workflow, this command should be the
first command issued. When creating SEV-SNP guest, the VMM must use this
command instead of the KVM_SEV_INIT or KVM_SEV_ES_INIT.
Cc: Thomas Gleixner
Cc:
The next generation of SEV is called SEV-SNP (Secure Nested Paging).
SEV-SNP builds upon existing SEV and SEV-ES functionality while adding new
hardware based security protection. SEV-SNP adds strong memory encryption
integrity protection to help prevent malicious hypervisor-based attacks
such as
Provide the APIs for the hypervisor to manage an SEV-SNP guest. The
commands for SEV-SNP is defined in the SEV-SNP firmware specification.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: Joerg Roedel
Cc: "H. Peter Anvin"
Cc: Tony Luck
Cc: Dave Hansen
Cc: "Peter Zijlstra (Intel)"
The behavior of the SEV-legacy commands is altered when the SNP firmware
is in the INIT state. When SNP is in INIT state, all the SEV-legacy
commands that cause the firmware to write to memory must be in the
firmware state before issuing the command..
See SEV-SNP spec section 5.3.7 for more detail
AMD introduced the next generation of SEV called SEV-SNP (Secure Nested
Paging). SEV-SNP builds upon existing SEV and SEV-ES functionality
while adding new hardware security protection.
Define the commands and structures used to communicate with the AMD-SP
when creating and managing the SEV-SNP gu
When the kernel is getting ready to kexec, it calls the device_shutdown() to
allow drivers to cleanup before the kexec. If SEV firmware is initialized
then shut it down before kexec'ing the new kernel.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: Joerg Roedel
Cc: "H. Peter Anvin
Before SNP VMs can be launched, the platform must be appropriately
configured and initialized. Platform initialization is accomplished via
the SNP_INIT command.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: Joerg Roedel
Cc: "H. Peter Anvin"
Cc: Tony Luck
Cc: Dave Hansen
Cc: "P
If hardware detects an RMP violation, it will raise a page-fault exception
with the RMP bit set. To help the debug, dump the RMP entry of the faulting
address.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: Joerg Roedel
Cc: "H. Peter Anvin"
Cc: Tony Luck
Cc: Dave Hansen
Cc: "Pe
When SEV-SNP is enabled globally in the system, a write from the hypervisor
can raise an RMP violation. We can resolve the RMP violation by splitting
the virtual address to a lower page level.
e.g
- guest made a page shared in the RMP entry so that the hypervisor
can write to it.
- the hyperviso
The RMPUPDATE instruction writes a new RMP entry in the RMP Table. The
hypervisor will use the instruction to add pages to the RMP table. See
APM3 for details on the instruction operations.
The PSMASH instruction expands a 2MB RMP entry into a corresponding set of
contiguous 4KB-Page RMP entries.
The integrity guarantee of SEV-SNP is enforced through the RMP table.
The RMP is used in conjuntion with standard x86 and IOMMU page
tables to enforce memory restrictions and page access rights. The
RMP is indexed by system physical address, and is checked at the end
of CPU and IOMMU table walks. T
Bit 31 in the page fault-error bit will be set when processor encounters
an RMP violation.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: Joerg Roedel
Cc: "H. Peter Anvin"
Cc: Tony Luck
Cc: Dave Hansen
Cc: "Peter Zijlstra (Intel)"
Cc: Paolo Bonzini
Cc: Tom Lendacky
Cc: David
This part of the Secure Encrypted Paging (SEV-SNP) series focuses on the
changes required in a host OS for SEV-SNP support. The series builds upon
SEV-SNP Part-1 https://marc.info/?l=kvm&m=161660430125343&w=2 .
This series provides the basic building blocks to support booting the SEV-SNP
VMs, it d
The lookup_page_in_rmptable() can be used by the host to read the RMP
entry for a given page. The RMP entry format is documented in PPR
section 2.1.5.2.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: Joerg Roedel
Cc: "H. Peter Anvin"
Cc: Tony Luck
Cc: Dave Hansen
Cc: "Peter Zij
The memory integrity guarantees of SEV-SNP are enforced through a new
structure called the Reverse Map Table (RMP). The RMP is a single data
structure shared across the system that contains one entry for every 4K
page of DRAM that may be used by SEV-SNP VMs. The goal of RMP is to
track the owner of
On Tue, 2021-03-23 at 14:07 -0400, Mimi Zohar wrote:
> On Tue, 2021-03-23 at 17:35 +0100, Ahmad Fatoum wrote:
> > Hello Horia,
> >
> > On 21.03.21 21:48, Horia Geantă wrote:
> > > On 3/16/2021 7:02 PM, Ahmad Fatoum wrote:
> > > [...]
> > > > +struct trusted_key_ops caam_trusted_key_ops = {
> > > >
From: Wei Yongjun
GCC reports build error as following:
x86_64-linux-gnu-ld: drivers/crypto/hisilicon/hpre/hpre_crypto.o: in function
`hpre_ecdh_set_secret':
hpre_crypto.c:(.text+0x269c): undefined reference to `crypto_ecdh_decode_key'
Fix it by selecting CRYPTO_ECDH.
Reported-by: Hulk Robot
Hello Sumit,
On 24.03.21 11:47, Sumit Garg wrote:
> On Wed, 24 Mar 2021 at 14:56, Ahmad Fatoum wrote:
>>
>> Hello Mimi,
>>
>> On 23.03.21 19:07, Mimi Zohar wrote:
>>> On Tue, 2021-03-23 at 17:35 +0100, Ahmad Fatoum wrote:
On 21.03.21 21:48, Horia Geantă wrote:
> caam has random number ge
The kernel module signature supports the option to use the SM3 secure
hash (OSCCA GM/T 0004-2012 SM3). SM2 and SM3 always appear in pairs.
The former is used for signing and the latter is used for hash
calculation.
To sign a kernel module, first, prepare a configuration file
openssl.cnf with the f
The kernel module signature supports the option to use the SM3 secure
hash (OSCCA GM/T 0004-2012 SM3). SM2 and SM3 always appear in pairs.
The former is used for signing and the latter is used for hash
calculation.
To sign a kernel module, first, prepare openssl 3.0.0 alpha6 and a
configuration fi
Support parsing the message signature of the SM2 and SM3 algorithm
combination. This group of algorithms has been well supported. One
of the main users is module signature verification.
Signed-off-by: Tianjia Zhang
---
crypto/asymmetric_keys/pkcs7_parser.c | 7 +++
1 file changed, 7 insertio
On Wed, 24 Mar 2021 at 14:56, Ahmad Fatoum wrote:
>
> Hello Mimi,
>
> On 23.03.21 19:07, Mimi Zohar wrote:
> > On Tue, 2021-03-23 at 17:35 +0100, Ahmad Fatoum wrote:
> >> On 21.03.21 21:48, Horia Geantă wrote:
> >>> caam has random number generation capabilities, so it's worth using that
> >>> by
Hi,
On 3/24/21 6:14 AM, Ard Biesheuvel wrote:
On Tue, 23 Mar 2021 at 09:36, Tianjia Zhang
wrote:
The kernel module signature supports the option to use the SM3
secure hash (OSCCA GM/T 0004-2012 SM3).
Signed-off-by: Tianjia Zhang
A secure hash is not the same as a signature. Looking at the
Hi,
On 3/24/21 12:43 AM, Randy Dunlap wrote:
On 3/23/21 1:35 AM, Tianjia Zhang wrote:
The kernel module signature supports the option to use the SM3
secure hash (OSCCA GM/T 0004-2012 SM3).
Signed-off-by: Tianjia Zhang
---
Documentation/admin-guide/module-signing.rst | 5 +++--
crypto/asymm
Hello Mimi,
On 23.03.21 19:07, Mimi Zohar wrote:
> On Tue, 2021-03-23 at 17:35 +0100, Ahmad Fatoum wrote:
>> On 21.03.21 21:48, Horia Geantă wrote:
>>> caam has random number generation capabilities, so it's worth using that
>>> by implementing .get_random.
>>
>> If the CAAM HWRNG is already seedi
48 matches
Mail list logo
