linux-kernel - Re: [RFC Part2 PATCH v3 16/26] KVM: SVM: Add support for SEV LAUNCH_UPDATE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 13 Sep 2017 14:45:37 -0500
From:   Brijesh Singh <brijesh.singh@....com>
To:     Borislav Petkov <bp@...e.de>
Cc:     brijesh.singh@....com, linux-kernel@...r.kernel.org,
        x86@...nel.org, kvm@...r.kernel.org,
        Thomas Gleixner <tglx@...utronix.de>,
        Joerg Roedel <joro@...tes.org>,
        "Michael S . Tsirkin" <mst@...hat.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        \"Radim Krčmář\" <rkrcmar@...hat.com>,
        Tom Lendacky <thomas.lendacky@....com>
Subject: Re: [RFC Part2 PATCH v3 16/26] KVM: SVM: Add support for SEV
 LAUNCH_UPDATE_DATA command

On 09/13/2017 12:55 PM, Borislav Petkov wrote:
...

>> +
>> +	/* pin the user virtual address */
>> +	pinned = get_user_pages_fast(uaddr, npages, write ? FOLL_WRITE : 0,
>> +					pages);
> 
> Let it stick out.

Will do.

...

>> +	vaddr = params.address;
>> +	size = params.length;
>> +	vaddr_end = vaddr + size;
>> +
>> +	/* lock the user memory */
>> +	inpages = sev_pin_memory(vaddr, size, &npages, 1);
> 
> This way user basically controls how many pages to pin and you need to
> limit that on the upper end.
> 

Actually I don't know what should be sane upper bound in this case --
typically we encrypt the guest BIOS using LAUNCH_UPDATE_DATA command.
I have heard that some user may want to create a pre-encrypted image
(which may contains guest BIOS + kernel + initrd) -- this can be huge.

For SEV guest, we have been needing to pin the memory hence how about if
we limit the number of pages to pin with rlimit ? The rlimit check can
also include the guest RAM pinning.

>> +	if (!inpages) {
>> +		ret = -ENOMEM;
>> +		goto e_free;
>> +	}
>> +
>> +	/*
>> +	 * invalidate the cache to ensure that DRAM has recent content before
> 
> recent content?

Cache access from the PSP are coherent with x86 but not other way around --
I will update the comments to reflect the true meaning.

...

> 
> Yah, let it stick out.
> 

Okay.