On 07/04/21 00:49, Sean Christopherson wrote:
This series teaches __sev_do_cmd_locked() to gracefully handle vmalloc'd
command buffers by copying _all_ incoming data pointers to an internal
buffer before sending the command to the PSP. The SEV driver and KVM are
then converted to use the stack f
On 07/04/21 19:34, Borislav Petkov wrote:
On Wed, Apr 07, 2021 at 05:05:07PM +, Sean Christopherson wrote:
I used memset() to defer initialization until after the various sanity
checks,
I'd actually vote for that too - I don't like doing stuff which is not
going to be used. I.e., don't cha
On 07/04/21 07:20, Christophe Leroy wrote:
+ struct sev_data_init data;
struct sev_data_init data = {0, 0, 0, 0};
Having to count the number of items is suboptimal. The alternative
could be {} (which however is technically not standard C), {0} (a bit
mysterious, but it works) and memse
On 07/04/21 00:49, Sean Christopherson wrote:
For commands with small input/output buffers, use the local stack to
"allocate" the structures used to communicate with the PSP. Now that
__sev_do_cmd_locked() gracefully handles vmalloc'd buffers, there's no
reason to avoid using the stack, e.g. CO
On 07/04/21 20:00, Tom Lendacky wrote:
For the series:
Acked-by: Tom Lendacky
Shall I take this as a request (or permission, whatever :)) to merge it
through the KVM tree?
Paolo
led while the guest is running and the measurement value is
signed with PEK.
Cc: James Bottomley
Cc: Tom Lendacky
Cc: David Rientjes
Cc: Paolo Bonzini
Cc: Sean Christopherson
Cc: Borislav Petkov
Cc: John Allen
Cc: Herbert Xu
Cc: linux-crypto@vger.kernel.org
Reviewed-by: Tom Lendacky
Acked
es on kvm/queue branch.
>
> Cc: Paolo Bonzini
> Cc: "Radim Krčmář"
> Cc: Borislav Petkov
> Cc: Herbert Xu
> Cc: Gary Hook
> Cc: Tom Lendacky
> Cc: Joerg Roedel
> Cc: linux-crypto@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
>
> Brijesh Sing
On 05/12/2017 02:04, Brijesh Singh wrote:
> This part of Secure Encrypted Virtualization (SEV) patch series focuses on KVM
> changes required to create and manage SEV guests.
>
> SEV is an extension to the AMD-V architecture which supports running encrypted
> virtual machine (VMs) under the contro
fbd8d194f06 (Linux 4.15-rc1)
>
> Complete tree is available at:
> repo: https://github.com/codomania/kvm.git
> branch: sev-v9-p2
>
> TODO:
> * Add SEV guest migration command support
>
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: "H. Peter Anvin"
>
On 28/03/2017 20:39, Borislav Petkov wrote:
>> 2) Since the encryption attributes works on PAGE_SIZE hence add some extra
>> padding to 'struct kvm-steal-time' to make it PAGE_SIZE and then at runtime
>> clear the encryption attribute of the full PAGE. The downside of this was
>> now we need to m
On 16/03/2017 19:41, Brijesh Singh wrote:
>>
>> Please do add it, it doesn't seem very different from what you're doing
>> in LAUNCH_UPDATE_DATA. There's no need for a separate
>> __sev_dbg_decrypt_page function, you can just pin/unpin here and do a
>> per-page loop as in LAUNCH_UPDATE_DATA.
>
On 10/03/2017 23:41, Brijesh Singh wrote:
>> Maybe there's a reason this fires:
>>
>> WARNING: modpost: Found 2 section mismatch(es).
>> To see full details build your kernel with:
>> 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
>>
>> WARNING: vmlinux.o(.text+0x48edc): Section mismatch in reference fro
On 02/03/2017 16:15, Brijesh Singh wrote:
>
> __split_large_page(struct cpa_data *cpa, pte_t *kpte, unsigned long address,
> -struct page *base)
> + pte_t *pbase, unsigned long new_pfn)
> {
> - pte_t *pbase = (pte_t *)page_address(base);
Just one comment and
On 02/03/2017 16:15, Brijesh Singh wrote:
> Some KVM specific MSR's (steal-time, asyncpf, avic_eio) allocates per-CPU
> variable at compile time and share its physical address with hypervisor.
> It presents a challege when SEV is active in guest OS. When SEV is active,
> guest memory is encrypted
On 02/03/2017 16:18, Brijesh Singh wrote:
> + data = (void *) get_zeroed_page(GFP_KERNEL);
The page does not need to be zeroed, does it?
> +
> + if ((len & 15) || (dst_addr & 15)) {
> + /* if destination address and length are not 16-byte
> + * aligned then:
> +
On 02/03/2017 16:18, Brijesh Singh wrote:
> +static int __sev_dbg_decrypt_page(struct kvm *kvm, unsigned long src,
> + void *dst, int *error)
> +{
> + inpages = sev_pin_memory(src, PAGE_SIZE, &npages);
> + if (!inpages) {
> + ret = -ENOMEM;
> + goto err
On 02/03/2017 16:17, Brijesh Singh wrote:
> +static struct page **sev_pin_memory(unsigned long uaddr, unsigned long ulen,
> + unsigned long *n)
> +{
> + struct page **pages;
> + int first, last;
> + unsigned long npages, pinned;
> +
> + /* Get numbe
On 02/03/2017 16:18, Brijesh Singh wrote:
> The SEV memory encryption engine uses a tweak such that two identical
> plaintexts at different location will have a different ciphertexts.
> So swapping or moving ciphertexts of two pages will not result in
> plaintexts being swapped. Relocating (or mi
On 02/03/2017 16:17, Brijesh Singh wrote:
> ASID management:
> - Reserve asid range for SEV guest, SEV asid range is obtained through
>CPUID Fn8000_001f[ECX]. A non-SEV guest can use any asid outside the SEV
>asid range.
How is backwards compatibility handled?
> - SEV guest must have
lable with KVM_CAP_X86_SMM */
> #define KVM_SMI _IO(KVMIO, 0xb7)
> +/* Memory Encryption Commands */
> +#define KVM_MEMORY_ENCRYPT_OP _IOWR(KVMIO, 0xb8, unsigned long)
>
> #define KVM_DEV_ASSIGN_ENABLE_IOMMU (1 << 0)
> #define KVM_DEV_ASSIGN_PCI_2_3 (1 << 1)
>
Reviewed-by: Paolo Bonzini
On 09/03/2017 15:07, Borislav Petkov wrote:
> + /* Check if running under a hypervisor */
> + eax = 0x4000;
> + ecx = 0;
> + native_cpuid(&eax, &ebx, &ecx, &edx);
This is not how you check if running under a hypervisor; you should
check the HYPERVISOR bit, i.e. bit 31 of cpui
On 22/09/2016 20:47, Tom Lendacky wrote:
> > Because the firmware volume is written to high memory in encrypted form,
> > and because the PEI phase runs in 32-bit mode, the firmware code will be
> > encrypted; on the other hand, data that is placed in low memory for the
> > kernel can be unencryp
On 22/09/2016 19:46, Tom Lendacky wrote:
>> > Do you mean, it is encrypted here because we're in the guest kernel?
> Yes, the idea is that the SEV guest will be running encrypted from the
> start, including the BIOS/UEFI, and so all of the EFI related data will
> be encrypted.
Unless this is par
On 22/09/2016 19:07, Borislav Petkov wrote:
>> Which paragraph?
> "Linux relies on BIOS to set this bit if BIOS has determined that the
> reduction in the physical address space as a result of enabling memory
> encryption..."
>
> Basically, you can enable SME in the BIOS and you're all set.
Tha
On 22/09/2016 16:59, Borislav Petkov wrote:
> On Thu, Sep 22, 2016 at 04:45:51PM +0200, Paolo Bonzini wrote:
>> The main difference between the SME and SEV encryption, from the point
>> of view of the kernel, is that real-mode always writes unencrypted in
>> SME and alway
On 22/09/2016 16:35, Borislav Petkov wrote:
>> > @@ -230,6 +230,10 @@ int __init efi_setup_page_tables(unsigned long
>> > pa_memmap, unsigned num_pages)
>> >efi_scratch.efi_pgt = (pgd_t *)__sme_pa(efi_pgd);
>> >pgd = efi_pgd;
>> >
>> > + flags = _PAGE_NX | _PAGE_RW;
>> > + if (sev_ac
On 17/09/2015 18:27, Dominik Dingel wrote:
> + preempt_disable();
> + solo = single_task_running();
> + preempt_enable();
> +
> cur = ktime_get();
> - } while (single_task_running() && ktime_before(cur,
Il 25/09/2012 17:35, David Howells ha scritto:
> Alan Cox wrote:
>
>> > Generate a certificate that is valid from a few minutes before the
>> > wallclock time. It's a certificate policy question not a kernel hackery
>> > one.
> That doesn't seem to be possible with openssl req. What would you re
28 matches
Mail list logo
