#syz dup: KASAN: slab-out-of-bounds Read in handle_vmptrld
On 08/11/19 20:14, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 847120f8 Merge branch 'for-linus' of
> git://git.kernel.org/..
> git tree: upstream
> console output:
On 22/02/19 11:48, lantianyu1...@gmail.com wrote:
> From: Lan Tianyu
>
> The max flush rep count of HvFlushGuestPhysicalAddressList hypercall
> is equal with how many entries of union hv_gpa_page_range can be populated
> into the input parameter page. The origin code lacks parenthesis around
>
On 22/02/19 16:06, lantianyu1...@gmail.com wrote:
> From: Lan Tianyu
>
> This patchset is to introduce hv ept tlb range list flush function
> support in the KVM MMU component. Flushing ept tlbs of several address
> range can be done via single hypercall and new list flush function is
> used in
On 02/02/19 02:38, lantianyu1...@gmail.com wrote:
> From: Lan Tianyu
>
> This patchset is to introduce hv ept tlb range list flush function
> support in the KVM MMU component. Flushing ept tlbs of several address
> range can be done via single hypercall and new list flush function is
> used in
On 06/12/18 14:21, lantianyu1...@gmail.com wrote:
> static inline int hyperv_flush_guest_mapping(u64 as) { return -1; }
> +static inline int hyperv_flush_guest_mapping_range(u64 as,
> + hyperv_fill_flush_list_func fill_func, void *data);
> +{
> + return -1;
This part for
On 06/12/18 14:21, lantianyu1...@gmail.com wrote:
> From: Lan Tianyu
>
> For nested memory virtualization, Hyper-v doesn't set write-protect
> L1 hypervisor EPT page directory and page table node to track changes
> while it relies on guest to tell it changes via HvFlushGuestAddressLlist
>
On 13/10/2018 16:53, lantianyu1...@gmail.com wrote:
> From: Lan Tianyu
>
> For nested memory virtualization, Hyper-v doesn't set write-protect
> L1 hypervisor EPT page directory and page table node to track changes
> while it relies on guest to tell it changes via HvFlushGuestAddressLlist
>
On 14/10/2018 10:16, Thomas Gleixner wrote:
>>> +static inline bool kvm_available_flush_tlb_with_range(void)
>>> +{
>>> + return kvm_x86_ops->tlb_remote_flush_with_range;
>>> +}
>> Seems that kvm_available_flush_tlb_with_range() is not used in this patch…
> What's wrong with that?
>
> It
On 13/10/2018 16:53, lantianyu1...@gmail.com wrote:
> @@ -1781,6 +1781,11 @@ static int kvm_set_pte_rmapp(struct kvm *kvm, struct
> kvm_rmap_head *rmap_head,
> }
> }
>
> + if (need_flush && kvm_available_flush_tlb_with_range()) {
> +
On 13/10/2018 16:54, lantianyu1...@gmail.com wrote:
> while (mmu_unsync_walk(parent, )) {
> bool protected = false;
> + LIST_HEAD(flush_list);
>
> - for_each_sp(pages, sp, parents, i)
> + for_each_sp(pages, sp, parents, i) {
>
On 13/10/2018 16:54, lantianyu1...@gmail.com wrote:
>
> +static int fill_flush_list(union hv_gpa_page_range gpa_list[],
> + int offset, u64 start_gfn, u64 pages)
Pass the entire struct hv_guest_mapping_flush_list to this function,
it's simpler and it hides the gpa_list argument from
On 13/10/2018 16:54, lantianyu1...@gmail.com wrote:
> From: Lan Tianyu
>
> PV EPT tlb flush function will accept a list of flush ranges and
> use struct kvm_mmu_page as the list entry.
>
> Signed-off-by: Lan Tianyu
> ---
> arch/x86/include/asm/kvm_host.h | 1 +
> 1 file changed, 1
On 13/10/2018 16:53, lantianyu1...@gmail.com wrote:
> + bool flush = false;
> int i;
>
> spin_lock(>mmu_lock);
> @@ -5654,18 +5655,27 @@ void kvm_zap_gfn_range(struct kvm *kvm, gfn_t
> gfn_start, gfn_t gfn_end)
> slots = __kvm_memslots(kvm, i);
>
On 04/10/2018 09:54, Vitaly Kuznetsov wrote:
> - Check if pure TSC can be used on SkyLake+ systems (where TSC scaling
> is supported).
Not if you want to migrate to pre-Skylake systems.
> - Check if non-masterclock mode is still needed. E.g. HyperV's TSC page
> clocksource is a single page for
On 27/09/2018 05:48, Tianyu Lan wrote:
> +
> + if (range && kvm_x86_ops->tlb_remote_flush_with_range) {
> + /*
> + * Read tlbs_dirty before flushing tlbs in order
> + * to track dirty tlbs during flushing.
> + */
> + long
On 27/09/2018 05:49, Tianyu Lan wrote:
> This patch is to flush tlb directly in the kvm_handle_hva_range()
> when range flush is available.
>
> Signed-off-by: Lan Tianyu
> ---
> arch/x86/kvm/mmu.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/x86/kvm/mmu.c
On 07/09/2018 07:45, Tianyu Lan wrote:
> kvm_commit_zap_page() has been renamed to kvm_mmu_commit_zap_page()
> This patch is to fix the commit.
>
> Signed-off-by: Lan Tianyu
> ---
> arch/x86/kvm/mmu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/kvm/mmu.c
On 20/07/2018 05:58, KY Srinivasan wrote:
>
>
>> -Original Message-
>> From: Tianyu Lan
>> Sent: Thursday, July 19, 2018 1:40 AM
>> Cc: Tianyu Lan ; de...@linuxdriverproject.org;
>> Haiyang Zhang ; h...@zytor.com;
>> k...@vger.kernel.org; KY Srinivasan ; linux-
>> ker...@vger.kernel.org;
On 19/07/2018 10:39, Tianyu Lan wrote:
> Hyper-V provides a para-virtualization hypercall
> HvFlushGuestPhysicalAddressSpace
> to flush nested VM address space mapping in l1 hypervisor and it's to reduce
> overhead
> of flushing ept tlb among vcpus. The tradition way is to send IPIs to all
>
On 09/07/2018 11:02, Tianyu Lan wrote:
> + /*
> + * Call kvm_arch_hv_tlb_remote first and go back old way when
> + * return failure.
> + */
> + if (!kvm_arch_hv_flush_remote_tlb(kvm))
> + return;
> +
> /*
>* Read tlbs_dirty before setting
On 09/07/2018 11:02, Tianyu Lan wrote:
> +static void check_ept_pointer(struct kvm_vcpu *vcpu, u64 eptp)
> +{
> + struct kvm *kvm = vcpu->kvm;
> + u64 tmp_eptp = INVALID_PAGE;
> + int i;
> +
> + if (!kvm_x86_ops->tlb_remote_flush)
> + return;
> +
> +
On 09/07/2018 11:02, Tianyu Lan wrote:
> +
> + /*
> + * Call kvm_arch_hv_tlb_remote first and go back old way when
> + * return failure.
> + */
Please call it "kvm_arch_flush_remote_tlbs", since Hyper-V should not be
mentioned in the generic code.
Paolo
On 21/12/2017 13:50, Vitaly Kuznetsov wrote:
> I'm back with (somewhat frustrating) results (E5-2603):
v4 (that would be Broadwell)?
> 1) Windows on Hyper-V (no nesting): 1350 cycles
>
> 2) Windows on Hyper-V on Hyper-V: 8600
>
> 3) Windows on KVM (no nesting): 1150 cycles
>
> 4) Windows on
On 19/12/2017 18:40, Jim Mattson wrote:
> I'm not sure that's really the right way to go, since any guest that
> has already read the IA32_VMX_BASIC MSR has a right to expect the VMCS
> revision to remain unchanged.
Hmm, not just that, "the VMCS revision identifier is never written by
the
On 18/12/2017 18:17, Vitaly Kuznetsov wrote:
> The original author of these patches does no longer work at Red Hat, I
> agreed to take this over and send upstream. Here is his original
> description:
>
> "Makes KVM implement the enlightened VMCS feature per Hyper-V TLFS 5.0b.
> I've measured
On 19/12/2017 13:25, Vitaly Kuznetsov wrote:
>
>> At this point in time, I don't think you can just blithely change the
>> virtual VMCS layout and revision number. Existing VMs using the old
>> layout and revision number must continue to work on versions of kvm
>> past this point. You could tie
Patch 6. :)
> when TSC frequency changes, we use a special feature from Hyper-V to do
> the job.
Patches 5-7 are
Acked-by: Paolo Bonzini <pbonz...@redhat.com>
I would appreciate if the Hyper-V folks can provide a topic branch to be
merged in both HV and KVM trees.
Thanks,
Paolo
>
On 01/12/2017 18:29, Stephen Hemminger wrote:
>> +static inline u64 hv_read_tsc_page_tsc(const struct ms_hyperv_tsc_page
>> *tsc_pg,
>> + u64 *cur_tsc)
>> +{
>> +*cur_tsc = rdtsc();
>> +
>> +return cur_tsc;
> Why do return and setting by reference. Looks
On 01/12/2017 14:13, Vitaly Kuznetsov wrote:
> Currently, KVM passes PVCLOCK_TSC_STABLE_BIT to its guests when running in
> so called 'masterclock' mode and this is only possible when the clocksource
> on the host is TSC. When running nested on Hyper-V we're using a different
> clocksource in L1
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
On 17/03/2017 12:33, Borislav Petkov wrote:
> On Fri, Mar 17, 2017 at 12:03:31PM +0100, Paolo Bonzini wrote:
>
>> If it is possible to do it in a fairly hypervisor-independent manner,
>> I'm all for it. That is, only by looking at AMD-specified CPUID leaves
>> an
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 17/03/2017 11:56, Borislav Petkov wrote:
>> Theoretically or practically?
> In the sense, it needs to be tried first to see how ugly it can get.
>
>> It only looks at the E820 map, doesn't it? Why does it have to do
>> anything with percpu memory areas?
> That's irrelevant. What we want to
On 17/03/2017 11:17, Borislav Petkov wrote:
>
>> I also don't really like the patch as is (plus it fails modpost), but
>> IMO reusing __change_page_attr and __split_large_page is the right thing
>> to do.
>
> Right, so teaching pageattr.c about memblock could theoretically come
> around and
On 16/03/2017 19:28, Borislav Petkov wrote:
> So how hard would it be if the hypervisor allocated that memory for the
> guest instead? It would allocate it decrypted and guest would need to
> access it decrypted too. All in preparation for SEV-ES which will need a
> block of unencrypted memory
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
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
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, );
> + if (!inpages) {
> + ret = -ENOMEM;
> + goto err_1;
>
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
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
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
/* Available 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 <
On 09/03/2017 15:07, Borislav Petkov wrote:
> + /* Check if running under a hypervisor */
> + eax = 0x4000;
> + ecx = 0;
> + native_cpuid(, , , );
This is not how you check if running under a hypervisor; you should
check the HYPERVISOR bit, i.e. bit 31 of cpuid(1).ecx. This
On 09/01/2017 09:40, h...@zytor.com wrote:
> On January 9, 2017 12:32:23 AM PST, Roman Kagan <rka...@virtuozzo.com> wrote:
>> On Mon, Jan 02, 2017 at 09:19:57AM +0100, Paolo Bonzini wrote:
>>> On 28/12/2016 18:09, Roman Kagan wrote:
>>>> Am I correct assuming
On 02/01/2017 20:39, Stephen Hemminger wrote:
>>>
>>> I would like to minimize what we include in the uapi header; especially
>>> when MSFT has made no guarantees
>>> with regards how they may be evolved. I will also work on getting some
>>> clarity on both stability and
>>> under what
On 28/12/2016 18:09, Roman Kagan wrote:
> Am I correct assuming that QEMU is currently the only user of
> arch/x86/include/uapi/asm/hyperv.h?
>
> Then I think we're fine withdrawing it from uapi as a whole and letting
> QEMU pull it in through its header-harvesting scripts (as does now
>
On 21/12/2016 14:23, Roman Kagan wrote:
> On Wed, Dec 21, 2016 at 01:00:44PM +0100, Olaf Hering wrote:
>> On Tue, Dec 20, Roman Kagan wrote:
>>
>> Reverting commit 22356585712d ("staging: hv: use sync_bitops when
>> interacting with the hypervisor") is save because ...
>>
>>> -
On 21/12/2016 18:50, Stephen Hemminger wrote:
> The other problem with the hyperv headers is they were initially done with
> only the Linux driver usage in mind. This made perfect sense at the time,
> the problem is that they mix internal state with protocol definitions.
Yes, and this was
On 21/12/2016 16:43, Christoph Hellwig wrote:
> On Wed, Dec 21, 2016 at 04:39:18PM +0100, Paolo Bonzini wrote:
>> That said, there are precedents in using UAPI this way for PV
>> interfaces. See for example include/uapi/linux/virtio*.h and
>> arch/x86/include/uapi/asm/kvm
On 21/12/2016 15:26, Christoph Hellwig wrote:
> On Wed, Dec 21, 2016 at 03:59:20PM +0300, Roman Kagan wrote:
>> That's fine by me.
>>
>> I guess the series should then start with a complete move
>> arch/x86/include/uapi/asm/hyperv.h ->
>> arch/x86/include/asm/hyperv_proto.h, and the remaining
On 31/10/2016 14:48, Lorenzo Stoakes wrote:
> On Mon, Oct 31, 2016 at 12:45:36PM +0100, Paolo Bonzini wrote:
>>
>>
>> On 31/10/2016 11:02, Lorenzo Stoakes wrote:
>>> - *
>>> - * get_user_pages should be phased out in favor of
>>> - * get_user_pages
On 31/10/2016 11:02, Lorenzo Stoakes wrote:
> - *
> - * get_user_pages should be phased out in favor of
> - * get_user_pages_locked|unlocked or get_user_pages_fast. Nothing
> - * should use get_user_pages because it cannot pass
> - * FAULT_FLAG_ALLOW_RETRY to handle_mm_fault.
This comment
> > If I understanding correctly then you are recommending that instead of
> > exporting various functions from PSP drv we should expose one function
> > for the all the guest command handling (something like this).
> >
> > My understanding is that a user could exhaust the ASIDs for encrypted
> >
> I am not sure if I fully understand this feedback. Let me summaries what
> we have right now.
>
> At highest level SEV key management commands are divided into two sections:
>
> - platform management : commands used during platform provisioning. PSP
> drv provides ioctl's for these commands.
On 23/08/2016 01:23, Brijesh Singh wrote:
> TODO:
> - send qemu/seabios RFC's on respective mailing list
> - integrate the psp driver with CCP driver (they share the PCI id's)
> - add SEV guest migration command support
> - add SEV snapshotting command support
> - determine how to do ioremap of
On 23/08/2016 01:28, Brijesh Singh wrote:
> +
> + /* Iterate through each vcpus and set SEV KVM_SEV_FEATURE bit in
> + * KVM_CPUID_FEATURE to indicate that SEV is enabled on this vcpu
> + */
> + kvm_for_each_vcpu(i, vcpu, kvm)
> + svm_cpuid_update(vcpu);
> +
Do you
On 23/08/2016 01:28, Brijesh Singh wrote:
> +static int sev_launch_start(struct kvm *kvm,
> + struct kvm_sev_launch_start __user *arg,
> + int *psp_ret)
> +{
> + int ret, asid;
> + struct kvm_sev_launch_start params;
> + struct
On 23/08/2016 01:28, Brijesh Singh wrote:
> The ioctl will be used by qemu to issue the Secure Encrypted
> Virtualization (SEV) guest commands to transition a guest into
> into SEV-enabled mode.
>
> a typical usage:
>
> struct kvm_sev_launch_start start;
> struct kvm_sev_issue_cmd data;
>
>
On 23/08/2016 01:28, Brijesh Singh wrote:
> The patch adds initial support required for Secure Encrypted
> Virtualization (SEV) guest management API's.
>
> ASID management:
> - Reserve asid range for SEV guest, SEV asid range is obtained
>through CPUID Fn8000_001f[ECX]. A non-SEV guest can
l.tlb_ctl = TLB_CONTROL_FLUSH_ALL_ASID;
> }
>
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"
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
On 22/09/2016 20:37, Borislav Petkov wrote:
>> > Unless this is part of some spec, it's easier if things are the same in
>> > SME and SEV.
> Yeah, I was pondering over how sprinkling sev_active checks might not be
> so clean.
>
> I'm wondering if we could make the EFI regions presented to the
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
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.
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
ctually do what the specification suggests.
This roughy matches what Windows looks for, though Windows actually
ignores HYPERV_CPUID_VENDOR_AND_MAX_FUNCTIONS completely.
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
---
arch/x86/kernel/cpu/mshyperv.c | 14 ++
1 file changed, 6
68 matches
Mail list logo
