Re: [PATCH V12 09/10] trace, ras: add ARM processor error trace event

2017-03-14 Thread Baicar, Tyler 

Hello Xie XiUQi,


On 3/12/2017 8:31 PM, Xie XiuQi wrote:

Hi Baicar Tyler,

On 2017/3/11 2:23, Baicar, Tyler wrote:

Hello Xie XiuQi,


On 3/9/2017 2:41 AM, Xie XiuQi wrote:

On 2017/3/7 4:45, Tyler Baicar wrote:

Currently there are trace events for the various RAS
errors with the exception of ARM processor type errors.
Add a new trace event for such errors so that the user
will know when they occur. These trace events are
consistent with the ARM processor error section type
defined in UEFI 2.6 spec section N.2.4.4.

Signed-off-by: Tyler Baicar 
Acked-by: Steven Rostedt 
---
   drivers/acpi/apei/ghes.c|  8 +++-
   drivers/firmware/efi/cper.c |  1 +
   drivers/ras/ras.c   |  1 +
   include/ras/ras_event.h | 34 ++
   4 files changed, 43 insertions(+), 1 deletion(-)
diff --git a/include/ras/ras_event.h b/include/ras/ras_event.h
index 5861b6f..b36db48 100644
--- a/include/ras/ras_event.h
+++ b/include/ras/ras_event.h
@@ -162,6 +162,40 @@
   );
 /*
+ * ARM Processor Events Report
+ *
+ * This event is generated when hardware detects an ARM processor error
+ * has occurred. UEFI 2.6 spec section N.2.4.4.
+ */
+TRACE_EVENT(arm_event,
+
+TP_PROTO(const struct cper_sec_proc_arm *proc),
+
+TP_ARGS(proc),
+
+TP_STRUCT__entry(
+__field(u64, mpidr)
+__field(u64, midr)
+__field(u32, running_state)
+__field(u32, psci_state)
+__field(u8, affinity)
+),
+
+TP_fast_assign(
+__entry->affinity = proc->affinity_level;
+__entry->mpidr = proc->mpidr;
+__entry->midr = proc->midr;
+__entry->running_state = proc->running_state;
+__entry->psci_state = proc->psci_state;
+),
+
+TP_printk("affinity level: %d; MPIDR: %016llx; MIDR: %016llx; "
+  "running state: %d; PSCI state: %d",
+  __entry->affinity, __entry->mpidr, __entry->midr,
+  __entry->running_state, __entry->psci_state)
+);
+

I think these fields are not enough, we need also export arm processor error
information (UEFI 2.6 spec section N.2.4.4.1), or at least the error type,
address, etc. So that the userspace (such as rasdaemon tool) could know what
error occurred.

This is something I am planning on adding in later. It is not clear to me how to
actually do this at this point. If you look at the spec, there is not a single
error information structure. There is at least one, but possibly a lot. There is
also an unknown amount of context information structures. In "Table 260. ARM 
Processor
Error Section" there are ERR_INFO_NUM and CONTEXT_INFO_NUM which give the 
number of these
structures. I think there will need to be separate trace events added in for 
each of
these structures because I don't think there is a way to have variable amounts 
of
structures inside of a trace event.

Yes, I agree.

Additional, cper_sec_proc_arm has validation bit, which indicates whether or 
not each of
the fields is valid in this section. How could we show it in this trace event? 
If the filed
is invalid, we would get a wrong value here.

I will add in checks for whether the fields are valid similar to what 
you did for the error info patch.


Thanks,
Tyler

--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: kvm/arm64: use-after-free in kvm_unmap_hva_handler/unmap_stage2_pmds

2017-03-14 Thread Paolo Bonzini 


On 14/03/2017 12:07, Suzuki K Poulose wrote:
> On 10/03/17 13:34, Andrey Konovalov wrote:
>> Hi,
>>
>> I've got the following error report while fuzzing the kernel with
>> syzkaller.
>>
>> On linux-next commit 56b8bad5e066c23e8fa273ef5fba50bd3da2ace8 (Mar 8).
>>
>> Unfortunately I can't reproduce it.
>>
>> ==
>> BUG: KASAN: use-after-free in put_page include/linux/compiler.h:243
>> [inline]
>> BUG: KASAN: use-after-free in unmap_stage2_pmds
>> arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:240 [inline]
>> BUG: KASAN: use-after-free in unmap_stage2_puds
>> arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:269 [inline]
>> BUG: KASAN: use-after-free in unmap_stage2_range+0x884/0x938
>> arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:299
>> Read of size 8 at addr 80004585c000 by task syz-executor/5176
> 
> 
>> [] put_page include/linux/compiler.h:243 [inline]
>> [] unmap_stage2_pmds
>> arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:240 [inline]
>> [] unmap_stage2_puds
>> arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:269 [inline]
>> [] unmap_stage2_range+0x884/0x938
>> arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:299
>> [] kvm_unmap_hva_handler+0x28/0x38
>> arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:1556
>> [] handle_hva_to_gpa+0x140/0x250
>> arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:1547
>> [] kvm_unmap_hva_range+0x60/0x80
>> arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:1579
>> []
>> kvm_mmu_notifier_invalidate_range_start+0x194/0x278
>> arch/arm64/kvm/../../../virt/kvm/kvm_main.c:357
>> [] __mmu_notifier_invalidate_range_start+0x1d0/0x2a0
>> mm/mmu_notifier.c:199
>> [] mmu_notifier_invalidate_range_start
>> include/linux/mmu_notifier.h:282 [inline]
>> [] unmap_vmas+0x12c/0x198 mm/memory.c:1372
>> [] unmap_region+0x128/0x230 mm/mmap.c:2460
>> [] update_hiwater_vm include/linux/mm.h:1483 [inline]
>> [] remove_vma_list mm/mmap.c:2432 [inline]
>> [] do_munmap+0x598/0x9b0 mm/mmap.c:2662
>> [] find_vma_links mm/mmap.c:495 [inline]
>> [] mmap_region+0x138/0xc78 mm/mmap.c:1610
>> [] is_file_hugepages include/linux/hugetlb.h:269
>> [inline]
>> [] do_mmap+0x3cc/0x848 mm/mmap.c:1446
>> [] do_mmap_pgoff include/linux/mm.h:2039 [inline]
>> [] vm_mmap_pgoff+0xec/0x120 mm/util.c:305
>> [] SYSC_mmap_pgoff mm/mmap.c:1475 [inline]
>> [] SyS_mmap_pgoff+0x220/0x420 mm/mmap.c:1458
>> [] sys_mmap+0x58/0x80 arch/arm64/kernel/sys.c:37
>> [] el0_svc_naked+0x24/0x28
>>
> 
> We hold kvm->mmu_lock, while manipulating the stage2 ranges. However, I
> find that
> we don't take the lock, when we do it f rom kvm_free_stage2_pgd(), which
> could
> potentially have caused a problem with an munmap of a memslot ?
> 
> Lightly tested...
> 
> 
> commit fa75684dbf0fe845cf8403517d6e0c2c3344a544
> Author: Suzuki K Poulose 
> Date:   Tue Mar 14 10:26:54 2017 +
> 
> kvm: arm: Fix locking for kvm_free_stage2_pgd
> In kvm_free_stage2_pgd() we don't hold the kvm->mmu_lock while
> calling
> unmap_stage2_range() on the entire memory range for the guest. This
> could
> cause problems with other callers (e.g, munmap on a memslot) trying to
> unmap a range.
> Cc: Marc Zyngier 
> Cc: Christoffer Dall 
> Signed-off-by: Suzuki K Poulose 
> 
> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
> index a07ce3e..7f97063 100644
> --- a/arch/arm/kvm/mmu.c
> +++ b/arch/arm/kvm/mmu.c
> @@ -831,7 +831,10 @@ void kvm_free_stage2_pgd(struct kvm *kvm)
> if (kvm->arch.pgd == NULL)
> return;
>  
> +   spin_lock(>mmu_lock);
> unmap_stage2_range(kvm, 0, KVM_PHYS_SIZE);
> +   spin_unlock(>mmu_lock);
> +
> /* Free the HW pgd, one page at a time */
> free_pages_exact(kvm->arch.pgd, S2_PGD_SIZE);
> kvm->arch.pgd = NULL;

Reviewed-by: Paolo Bonzini 
> 
> 
> 
>> The buggy address belongs to the page:
>> page:7e0001161700 count:0 mapcount:0 mapping:  (null)
>> index:0x0
>> flags: 0xfffc000()
>> raw: 0fffc000   
>> raw: 7e00018c9120 7eea8b60  
>> page dumped because: kasan: bad access detected
>>
>> Memory state around the buggy address:
>>  80004585bf00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>  80004585bf80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>> 80004585c000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>^
>>  80004585c080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>  80004585c100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> ==
>>
> 
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v3 00/25] arm/arm64: KVM: Rework the hyp-stub API

2017-03-14 Thread Marc Zyngier 
On 14/03/17 16:05, Russell King - ARM Linux wrote:
> On Mon, Mar 06, 2017 at 02:24:33PM +, Marc Zyngier wrote:
>> As noticed by RMK in this thread[1], the hyp-stub API on 32bit ARM
>> could do with some TLC (it cannot perform a soft-restart at HYP, and
>> has holes in the hyp-stub support in a number of places). In general,
>> it would be desirable for the 32bit behaviour to align on 64bit, if
>> only to ease maintenance.
> 
> What's the merge plan for this?

If you're happy with it (together with Christoffer, Will and Catalin), I
plat to take it through the kvmarm tree.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v3 00/25] arm/arm64: KVM: Rework the hyp-stub API

2017-03-14 Thread Russell King - ARM Linux 
On Mon, Mar 06, 2017 at 02:24:33PM +, Marc Zyngier wrote:
> As noticed by RMK in this thread[1], the hyp-stub API on 32bit ARM
> could do with some TLC (it cannot perform a soft-restart at HYP, and
> has holes in the hyp-stub support in a number of places). In general,
> it would be desirable for the 32bit behaviour to align on 64bit, if
> only to ease maintenance.

What's the merge plan for this?

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

[PATCH 1/3] kvm: arm/arm64: Take mmap_sem in stage2_unmap_vm

2017-03-14 Thread Suzuki K Poulose 
From: Marc Zyngier 

We don't hold the mmap_sem while searching for the VMAs when
we try to unmap each memslot for a VM. Fix this properly to
avoid unexpected results.

Fixes: commit 957db105c997 ("arm/arm64: KVM: Introduce stage2_unmap_vm")
Cc: sta...@vger.kernel.org # v3.19+
Cc: Christoffer Dall 
Signed-off-by: Marc Zyngier 
Signed-off-by: Suzuki K Poulose 
---
 arch/arm/kvm/mmu.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 962616f..f2e2e0c 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -803,6 +803,7 @@ void stage2_unmap_vm(struct kvm *kvm)
int idx;
 
idx = srcu_read_lock(>srcu);
+   down_read(>mm->mmap_sem);
spin_lock(>mmu_lock);
 
slots = kvm_memslots(kvm);
@@ -810,6 +811,7 @@ void stage2_unmap_vm(struct kvm *kvm)
stage2_unmap_memslot(kvm, memslot);
 
spin_unlock(>mmu_lock);
+   up_read(>mm->mmap_sem);
srcu_read_unlock(>srcu, idx);
 }
 
-- 
2.7.4

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

[PATCH 0/3] kvm: arm/arm64: Fixes for use after free problems

2017-03-14 Thread Suzuki K Poulose 
This series contains potential fixes for problems reported by [0] & [1].

[0] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-March/492944.html
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-March/492943.html


Marc Zyngier (2):
  kvm: arm/arm64: Take mmap_sem in stage2_unmap_vm
  kvm: arm/arm64: Take mmap_sem in kvm_arch_prepare_memory_region

Suzuki K Poulose (1):
  kvm: arm/arm64: Fix locking for kvm_free_stage2_pgd

 arch/arm/kvm/mmu.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

-- 
2.7.4

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

[PATCH 3/3] kvm: arm/arm64: Fix locking for kvm_free_stage2_pgd

2017-03-14 Thread Suzuki K Poulose 
In kvm_free_stage2_pgd() we don't hold the kvm->mmu_lock while calling
unmap_stage2_range() on the entire memory range for the guest. This could
cause problems with other callers (e.g, munmap on a memslot) trying to
unmap a range.

Fixes: commit d5d8184d35c9 ("KVM: ARM: Memory virtualization setup")
Cc: sta...@vger.kernel.org # v3.10+
Cc: Marc Zyngier 
Cc: Christoffer Dall 
Signed-off-by: Suzuki K Poulose 
---
 arch/arm/kvm/mmu.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 13b9c1f..b361f71 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -831,7 +831,10 @@ void kvm_free_stage2_pgd(struct kvm *kvm)
if (kvm->arch.pgd == NULL)
return;
 
+   spin_lock(>mmu_lock);
unmap_stage2_range(kvm, 0, KVM_PHYS_SIZE);
+   spin_unlock(>mmu_lock);
+
/* Free the HW pgd, one page at a time */
free_pages_exact(kvm->arch.pgd, S2_PGD_SIZE);
kvm->arch.pgd = NULL;
-- 
2.7.4

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

[PATCH 2/3] kvm: arm/arm64: Take mmap_sem in kvm_arch_prepare_memory_region

2017-03-14 Thread Suzuki K Poulose 
From: Marc Zyngier 

We don't hold the mmap_sem while searching for VMAs (via find_vma), in
kvm_arch_prepare_memory_region, which can end up in expected failures.

Fixes: commit 8eef91239e57 ("arm/arm64: KVM: map MMIO regions at creation time")
Cc: Ard Biesheuvel 
Cc: Christoffer Dall 
Cc: Eric Auger 
Cc: sta...@vger.kernel.org # v3.18+
Signed-off-by: Marc Zyngier 
[ Handle dirty page logging failure case ]
Signed-off-by: Suzuki K Poulose 
---
 arch/arm/kvm/mmu.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index f2e2e0c..13b9c1f 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -1803,6 +1803,7 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
(KVM_PHYS_SIZE >> PAGE_SHIFT))
return -EFAULT;
 
+   down_read(>mm->mmap_sem);
/*
 * A memory region could potentially cover multiple VMAs, and any holes
 * between them, so iterate over all of them to find out if we can map
@@ -1846,8 +1847,10 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
pa += vm_start - vma->vm_start;
 
/* IO region dirty page logging not allowed */
-   if (memslot->flags & KVM_MEM_LOG_DIRTY_PAGES)
-   return -EINVAL;
+   if (memslot->flags & KVM_MEM_LOG_DIRTY_PAGES) {
+   ret = -EINVAL;
+   goto out;
+   }
 
ret = kvm_phys_addr_ioremap(kvm, gpa, pa,
vm_end - vm_start,
@@ -1859,7 +1862,7 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
} while (hva < reg_end);
 
if (change == KVM_MR_FLAGS_ONLY)
-   return ret;
+   goto out;
 
spin_lock(>mmu_lock);
if (ret)
@@ -1867,6 +1870,8 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
else
stage2_flush_memslot(kvm, memslot);
spin_unlock(>mmu_lock);
+out:
+   up_read(>mm->mmap_sem);
return ret;
 }
 
-- 
2.7.4

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v3 00/25] arm/arm64: KVM: Rework the hyp-stub API

2017-03-14 Thread Nishanth Menon 
On Tue, Mar 14, 2017 at 8:55 AM, Marc Zyngier  wrote:
[...]
>> Tested for kexec booting with the patch series applied on linux-next.
>>
>> kexec is working nicely with HYP and SVC modes. Tested for both modes by
>> using different u-boot for booting in HYP and SVC modes. Kexec works well.
>>
>> Tested on DRA7-EVM, AM57XX-EVM and KEYSTONE-K2E-EVM.
>>
>> Tested-by: Keerthy 
>
> Thanks a lot. I assume this Tested-by applies to the 32bit patches in
> this series?

Yes, the above platform list from Keerthy are all A15 32bit platforms.

---
Regards,
Nishanth Menon
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v3 00/25] arm/arm64: KVM: Rework the hyp-stub API

2017-03-14 Thread Marc Zyngier 

On 14/03/17 13:38, Keerthy wrote:
> 
> 
> On Monday 06 March 2017 07:54 PM, Marc Zyngier wrote:
>> As noticed by RMK in this thread[1], the hyp-stub API on 32bit ARM
>> could do with some TLC (it cannot perform a soft-restart at HYP, and
>> has holes in the hyp-stub support in a number of places). In general,
>> it would be desirable for the 32bit behaviour to align on 64bit, if
>> only to ease maintenance.
>>
>> This series implements the following:
>> - Add HVC_[GS]ET_VECTORS and HVC_SOFT_RESTART to the 32bit code
>> - Add HVC_RESET_VECTORS to both arm and arm64, removing the need for
>>   __hyp_reset_vectors
>> - Implement add the stub entry points in the KVM init code, which
>>   didn't implement any so far
>> - Convert the HYP code to use the init code stubs directly
>> - Some general cleanup as a result of these changes (which includes
>>   killing HVC_GET_VECTORS)
>> - Add some API documentation that covers the above
>>
>> Patches 9 to 11 would be better squashed into 7 and 8, but I've kept
>> separate so that I can take the blame for everything I've broken.
> 
> Tested for kexec booting with the patch series applied on linux-next.
> 
> kexec is working nicely with HYP and SVC modes. Tested for both modes by
> using different u-boot for booting in HYP and SVC modes. Kexec works well.
> 
> Tested on DRA7-EVM, AM57XX-EVM and KEYSTONE-K2E-EVM.
> 
> Tested-by: Keerthy 

Thanks a lot. I assume this Tested-by applies to the 32bit patches in
this series?

Cheers,

M.
-- 
Jazz is not dead. It just smells funny...
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v3 00/25] arm/arm64: KVM: Rework the hyp-stub API

2017-03-14 Thread Keerthy 


On Monday 06 March 2017 07:54 PM, Marc Zyngier wrote:
> As noticed by RMK in this thread[1], the hyp-stub API on 32bit ARM
> could do with some TLC (it cannot perform a soft-restart at HYP, and
> has holes in the hyp-stub support in a number of places). In general,
> it would be desirable for the 32bit behaviour to align on 64bit, if
> only to ease maintenance.
> 
> This series implements the following:
> - Add HVC_[GS]ET_VECTORS and HVC_SOFT_RESTART to the 32bit code
> - Add HVC_RESET_VECTORS to both arm and arm64, removing the need for
>   __hyp_reset_vectors
> - Implement add the stub entry points in the KVM init code, which
>   didn't implement any so far
> - Convert the HYP code to use the init code stubs directly
> - Some general cleanup as a result of these changes (which includes
>   killing HVC_GET_VECTORS)
> - Add some API documentation that covers the above
> 
> Patches 9 to 11 would be better squashed into 7 and 8, but I've kept
> separate so that I can take the blame for everything I've broken.

Tested for kexec booting with the patch series applied on linux-next.

kexec is working nicely with HYP and SVC modes. Tested for both modes by
using different u-boot for booting in HYP and SVC modes. Kexec works well.

Tested on DRA7-EVM, AM57XX-EVM and KEYSTONE-K2E-EVM.

Tested-by: Keerthy 

> 
> This has been tested on arm (Cubietruck, Jetson TK1) and arm64
> (Seattle), both as host and guest.
> 
> [1] 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-December/473472.html
> 
> * From v2:
>   - Kill HVC_GET_VECTORS and the corresponding __hyp_get_vectors
> 
> * From v1:
>   - Fixed some glaring bugs (reported by Ard and James)
>   - Tidy up stub vector export on 32bit (Ard)
>   - Nicer VA/PA conversion on 32bit (Ard)
>   - Updated cpu_v7_reset documentation
>   - Cleaned up HYP reset on PM events
>   - Minor stub documentation update
> 
> Marc Zyngier (23):
>   arm64: hyp-stub: Implement HVC_RESET_VECTORS stub hypercall
>   arm64: KVM: Implement HVC_RESET_VECTORS stub hypercall
>   arm64: KVM: Implement HVC_GET_VECTORS in the init code
>   arm64: KVM: Allow the main HYP code to use the init hyp stub
> implementation
>   arm64: KVM: Convert __cpu_reset_hyp_mode to using __hyp_reset_vectors
>   arm64: KVM: Implement HVC_SOFT_RESTART in the init code
>   ARM: KVM: Convert KVM to use HVC_GET_VECTORS
>   ARM: Update cpu_v7_reset documentation
>   ARM: hyp-stub: Use r1 for the soft-restart address
>   ARM: Expose the VA/IDMAP offset
>   ARM: hyp-stub: Implement HVC_RESET_VECTORS stub hypercall
>   ARM: KVM: Implement HVC_RESET_VECTORS stub hypercall
>   ARM: KVM: Implement HVC_GET_VECTORS in the init code
>   ARM: KVM: Allow the main HYP code to use the init hyp stub
> implementation
>   ARM: KVM: Convert __cpu_reset_hyp_mode to using __hyp_reset_vectors
>   ARM: KVM: Implement HVC_SOFT_RESTART in the init code
>   arm/arm64: KVM: Use __hyp_reset_vectors() directly
>   arm/arm64: KVM: Remove kvm_get_idmap_start
>   arm/arm64: KVM: Use HVC_RESET_VECTORS to reinit HYP mode
>   ARM: decompressor: Remove __hyp_get_vectors usage
>   ARM: hyp-stub/KVM: Kill __hyp_get_vectors
>   arm64: hyp-stub/KVM: Kill __hyp_get_vectors
>   arm/arm64: Add hyp-stub API documentation
> 
> Russell King (2):
>   ARM: hyp-stub: improve ABI
>   ARM: soft-reboot into same mode that we entered the kernel
> 
>  Documentation/virtual/kvm/arm/hyp-abi.txt | 45 
>  arch/arm/boot/compressed/head.S   |  5 +++-
>  arch/arm/include/asm/kvm_asm.h|  2 --
>  arch/arm/include/asm/kvm_host.h   |  6 
>  arch/arm/include/asm/kvm_mmu.h|  1 -
>  arch/arm/include/asm/proc-fns.h   |  4 +--
>  arch/arm/include/asm/virt.h   | 12 +++-
>  arch/arm/kernel/hyp-stub.S| 39 +++-
>  arch/arm/kernel/reboot.c  |  7 +++--
>  arch/arm/kvm/arm.c| 25 ++--
>  arch/arm/kvm/hyp/hyp-entry.S  | 29 ++
>  arch/arm/kvm/init.S   | 49 
> ++-
>  arch/arm/kvm/interrupts.S |  4 ---
>  arch/arm/kvm/mmu.c|  5 
>  arch/arm/mm/mmu.c |  5 
>  arch/arm/mm/proc-v7.S | 15 ++
>  arch/arm64/include/asm/kvm_asm.h  |  1 -
>  arch/arm64/include/asm/kvm_host.h |  7 -
>  arch/arm64/include/asm/kvm_mmu.h  |  1 -
>  arch/arm64/include/asm/virt.h | 17 +++
>  arch/arm64/kernel/hyp-stub.S  | 26 
>  arch/arm64/kvm/hyp-init.S | 45 +---
>  arch/arm64/kvm/hyp.S  |  2 +-
>  arch/arm64/kvm/hyp/hyp-entry.S| 39 
>  24 files changed, 265 insertions(+), 126 deletions(-)
>  create mode 100644 Documentation/virtual/kvm/arm/hyp-abi.txt
>

Re: kvm/arm64: use-after-free in kvm_vm_ioctl/vmacache_update

2017-03-14 Thread Marc Zyngier 
On 14/03/17 11:03, Suzuki K Poulose wrote:
> On 13/03/17 09:58, Marc Zyngier wrote:
>> On 10/03/17 18:37, Suzuki K Poulose wrote:
>>> On 10/03/17 15:50, Andrey Konovalov wrote:
 On Fri, Mar 10, 2017 at 2:38 PM, Andrey Konovalov  
 wrote:
> Hi,
>
> I've got the following error report while fuzzing the kernel with 
> syzkaller.
>
> On linux-next commit 56b8bad5e066c23e8fa273ef5fba50bd3da2ace8 (Mar 8).
>
> Unfortunately I can't reproduce it.
>
> ==
> BUG: KASAN: use-after-free in vmacache_update+0x114/0x118 mm/vmacache.c:63
> Read of size 8 at addr 80003b9a2040 by task syz-executor/26615
>
> CPU: 1 PID: 26615 Comm: syz-executor Not tainted
> 4.11.0-rc1-next-20170308-xc2-dirty #3
> Hardware name: Hardkernel ODROID-C2 (DT)
> Call trace:
> [] dump_backtrace+0x0/0x440 
> arch/arm64/kernel/traps.c:505
> [] show_stack+0x20/0x30 arch/arm64/kernel/traps.c:228
> [] __dump_stack lib/dump_stack.c:16 [inline]
> [] dump_stack+0x110/0x168 lib/dump_stack.c:52
> [] print_address_description+0x60/0x248 
> mm/kasan/report.c:250
> [] kasan_report_error+0xe8/0x250 mm/kasan/report.c:349
> [] kasan_report mm/kasan/report.c:372 [inline]
> [] __asan_report_load8_noabort+0x3c/0x48 
> mm/kasan/report.c:393
> [] vmacache_update+0x114/0x118 mm/vmacache.c:63
> [] find_vma+0xf8/0x150 mm/mmap.c:2124
> [] kvm_arch_prepare_memory_region+0x2ac/0x488
> arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:1817
> [] __kvm_set_memory_region+0x3d8/0x12b8
> arch/arm64/kvm/../../../virt/kvm/kvm_main.c:1026
> [] kvm_set_memory_region+0x38/0x58
> arch/arm64/kvm/../../../virt/kvm/kvm_main.c:1075
> [] kvm_vm_ioctl_set_memory_region
> arch/arm64/kvm/../../../virt/kvm/kvm_main.c:1087 [inline]
> [] kvm_vm_ioctl+0xb94/0x1308
> arch/arm64/kvm/../../../virt/kvm/kvm_main.c:2960
> [] vfs_ioctl fs/ioctl.c:45 [inline]
> [] do_vfs_ioctl+0x128/0xfc0 fs/ioctl.c:685
> [] SYSC_ioctl fs/ioctl.c:700 [inline]
> [] SyS_ioctl+0xa8/0xb8 fs/ioctl.c:691
> [] el0_svc_naked+0x24/0x28
>
> Allocated by task 26657:
>  save_stack_trace_tsk+0x0/0x330 arch/arm64/kernel/stacktrace.c:133
>  save_stack_trace+0x20/0x30 arch/arm64/kernel/stacktrace.c:216
>  save_stack mm/kasan/kasan.c:515 [inline]
>  set_track mm/kasan/kasan.c:527 [inline]
>  kasan_kmalloc+0xd4/0x180 mm/kasan/kasan.c:619
>  kasan_slab_alloc+0x14/0x20 mm/kasan/kasan.c:557
>  slab_post_alloc_hook mm/slab.h:456 [inline]
>  slab_alloc_node mm/slub.c:2718 [inline]
>  slab_alloc mm/slub.c:2726 [inline]
>  kmem_cache_alloc+0x144/0x230 mm/slub.c:2731
>  __split_vma+0x118/0x608 mm/mmap.c:2515
>  do_munmap+0x194/0x9b0 mm/mmap.c:2636
> Freed by task 26657:
>  save_stack_trace_tsk+0x0/0x330 arch/arm64/kernel/stacktrace.c:133
>  save_stack_trace+0x20/0x30 arch/arm64/kernel/stacktrace.c:216
>  save_stack mm/kasan/kasan.c:515 [inline]
>  set_track mm/kasan/kasan.c:527 [inline]
>  kasan_slab_free+0x84/0x198 mm/kasan/kasan.c:592
>  slab_free_hook mm/slub.c:1357 [inline]
>  slab_free_freelist_hook mm/slub.c:1379 [inline]
>  slab_free mm/slub.c:2961 [inline]
>  kmem_cache_free+0x80/0x258 mm/slub.c:2983
>  __vma_adjust+0x6b0/0xf mm/mmap.c:890]  el0_svc_naked+0x24/0x28
>
> The buggy address belongs to the object at 80003b9a2000
>  which belongs to the cache vm_area_struct(647:session-6.scope) of size 
> 184
> The buggy address is located 64 bytes inside of
>  184-byte region [80003b9a2000, 80003b9a20b8)
> The buggy address belongs to the page:
> page:7eee6880 count:1 mapcount:0 mapping:  (null) 
> index:0x0
> flags: 0xfffc100(slab)
> raw: 0fffc100   000180100010
> raw:  000c0001 80005a5cc600 80005ac99980
> page dumped because: kasan: bad access detected
> page->mem_cgroup:80005ac99980
>
> Memory state around the buggy address:
>  80003b9a1f00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>  80003b9a1f80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> 80003b9a2000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>^
>  80003b9a2080: fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc fb
>  80003b9a2100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ==

 Another one that looks related and doesn't have parts of stack traces 
 missing:

 ==
 BUG: KASAN: use-after-free in find_vma+0x140/0x150 mm/mmap.c:2114
 Read of size 8 at addr 800031a03e90 by task

Re: kvm/arm64: use-after-free in kvm_unmap_hva_handler/unmap_stage2_pmds

2017-03-14 Thread Suzuki K Poulose 

On 10/03/17 13:34, Andrey Konovalov wrote:

Hi,

I've got the following error report while fuzzing the kernel with syzkaller.

On linux-next commit 56b8bad5e066c23e8fa273ef5fba50bd3da2ace8 (Mar 8).

Unfortunately I can't reproduce it.

==
BUG: KASAN: use-after-free in put_page include/linux/compiler.h:243 [inline]
BUG: KASAN: use-after-free in unmap_stage2_pmds
arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:240 [inline]
BUG: KASAN: use-after-free in unmap_stage2_puds
arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:269 [inline]
BUG: KASAN: use-after-free in unmap_stage2_range+0x884/0x938
arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:299
Read of size 8 at addr 80004585c000 by task syz-executor/5176




[] put_page include/linux/compiler.h:243 [inline]
[] unmap_stage2_pmds
arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:240 [inline]
[] unmap_stage2_puds
arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:269 [inline]
[] unmap_stage2_range+0x884/0x938
arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:299
[] kvm_unmap_hva_handler+0x28/0x38
arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:1556
[] handle_hva_to_gpa+0x140/0x250
arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:1547
[] kvm_unmap_hva_range+0x60/0x80
arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:1579
[]
kvm_mmu_notifier_invalidate_range_start+0x194/0x278
arch/arm64/kvm/../../../virt/kvm/kvm_main.c:357
[] __mmu_notifier_invalidate_range_start+0x1d0/0x2a0
mm/mmu_notifier.c:199
[] mmu_notifier_invalidate_range_start
include/linux/mmu_notifier.h:282 [inline]
[] unmap_vmas+0x12c/0x198 mm/memory.c:1372
[] unmap_region+0x128/0x230 mm/mmap.c:2460
[] update_hiwater_vm include/linux/mm.h:1483 [inline]
[] remove_vma_list mm/mmap.c:2432 [inline]
[] do_munmap+0x598/0x9b0 mm/mmap.c:2662
[] find_vma_links mm/mmap.c:495 [inline]
[] mmap_region+0x138/0xc78 mm/mmap.c:1610
[] is_file_hugepages include/linux/hugetlb.h:269 [inline]
[] do_mmap+0x3cc/0x848 mm/mmap.c:1446
[] do_mmap_pgoff include/linux/mm.h:2039 [inline]
[] vm_mmap_pgoff+0xec/0x120 mm/util.c:305
[] SYSC_mmap_pgoff mm/mmap.c:1475 [inline]
[] SyS_mmap_pgoff+0x220/0x420 mm/mmap.c:1458
[] sys_mmap+0x58/0x80 arch/arm64/kernel/sys.c:37
[] el0_svc_naked+0x24/0x28



We hold kvm->mmu_lock, while manipulating the stage2 ranges. However, I find 
that
we don't take the lock, when we do it f rom kvm_free_stage2_pgd(), which could
potentially have caused a problem with an munmap of a memslot ?

Lightly tested...


commit fa75684dbf0fe845cf8403517d6e0c2c3344a544
Author: Suzuki K Poulose 
Date:   Tue Mar 14 10:26:54 2017 +

kvm: arm: Fix locking for kvm_free_stage2_pgd

In kvm_free_stage2_pgd() we don't hold the kvm->mmu_lock while calling

unmap_stage2_range() on the entire memory range for the guest. This could
cause problems with other callers (e.g, munmap on a memslot) trying to
unmap a range.

Cc: Marc Zyngier 

Cc: Christoffer Dall 
Signed-off-by: Suzuki K Poulose 

diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index a07ce3e..7f97063 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -831,7 +831,10 @@ void kvm_free_stage2_pgd(struct kvm *kvm)
if (kvm->arch.pgd == NULL)
return;
 
+   spin_lock(>mmu_lock);

unmap_stage2_range(kvm, 0, KVM_PHYS_SIZE);
+   spin_unlock(>mmu_lock);
+
/* Free the HW pgd, one page at a time */
free_pages_exact(kvm->arch.pgd, S2_PGD_SIZE);
kvm->arch.pgd = NULL;





The buggy address belongs to the page:
page:7e0001161700 count:0 mapcount:0 mapping:  (null) index:0x0
flags: 0xfffc000()
raw: 0fffc000   
raw: 7e00018c9120 7eea8b60  
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 80004585bf00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 80004585bf80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

80004585c000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

   ^
 80004585c080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 80004585c100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
==



___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: kvm/arm64: use-after-free in kvm_vm_ioctl/vmacache_update

2017-03-14 Thread Suzuki K Poulose 

On 13/03/17 09:58, Marc Zyngier wrote:

On 10/03/17 18:37, Suzuki K Poulose wrote:

On 10/03/17 15:50, Andrey Konovalov wrote:

On Fri, Mar 10, 2017 at 2:38 PM, Andrey Konovalov  wrote:

Hi,

I've got the following error report while fuzzing the kernel with syzkaller.

On linux-next commit 56b8bad5e066c23e8fa273ef5fba50bd3da2ace8 (Mar 8).

Unfortunately I can't reproduce it.

==
BUG: KASAN: use-after-free in vmacache_update+0x114/0x118 mm/vmacache.c:63
Read of size 8 at addr 80003b9a2040 by task syz-executor/26615

CPU: 1 PID: 26615 Comm: syz-executor Not tainted
4.11.0-rc1-next-20170308-xc2-dirty #3
Hardware name: Hardkernel ODROID-C2 (DT)
Call trace:
[] dump_backtrace+0x0/0x440 arch/arm64/kernel/traps.c:505
[] show_stack+0x20/0x30 arch/arm64/kernel/traps.c:228
[] __dump_stack lib/dump_stack.c:16 [inline]
[] dump_stack+0x110/0x168 lib/dump_stack.c:52
[] print_address_description+0x60/0x248 mm/kasan/report.c:250
[] kasan_report_error+0xe8/0x250 mm/kasan/report.c:349
[] kasan_report mm/kasan/report.c:372 [inline]
[] __asan_report_load8_noabort+0x3c/0x48 mm/kasan/report.c:393
[] vmacache_update+0x114/0x118 mm/vmacache.c:63
[] find_vma+0xf8/0x150 mm/mmap.c:2124
[] kvm_arch_prepare_memory_region+0x2ac/0x488
arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:1817
[] __kvm_set_memory_region+0x3d8/0x12b8
arch/arm64/kvm/../../../virt/kvm/kvm_main.c:1026
[] kvm_set_memory_region+0x38/0x58
arch/arm64/kvm/../../../virt/kvm/kvm_main.c:1075
[] kvm_vm_ioctl_set_memory_region
arch/arm64/kvm/../../../virt/kvm/kvm_main.c:1087 [inline]
[] kvm_vm_ioctl+0xb94/0x1308
arch/arm64/kvm/../../../virt/kvm/kvm_main.c:2960
[] vfs_ioctl fs/ioctl.c:45 [inline]
[] do_vfs_ioctl+0x128/0xfc0 fs/ioctl.c:685
[] SYSC_ioctl fs/ioctl.c:700 [inline]
[] SyS_ioctl+0xa8/0xb8 fs/ioctl.c:691
[] el0_svc_naked+0x24/0x28

Allocated by task 26657:
 save_stack_trace_tsk+0x0/0x330 arch/arm64/kernel/stacktrace.c:133
 save_stack_trace+0x20/0x30 arch/arm64/kernel/stacktrace.c:216
 save_stack mm/kasan/kasan.c:515 [inline]
 set_track mm/kasan/kasan.c:527 [inline]
 kasan_kmalloc+0xd4/0x180 mm/kasan/kasan.c:619
 kasan_slab_alloc+0x14/0x20 mm/kasan/kasan.c:557
 slab_post_alloc_hook mm/slab.h:456 [inline]
 slab_alloc_node mm/slub.c:2718 [inline]
 slab_alloc mm/slub.c:2726 [inline]
 kmem_cache_alloc+0x144/0x230 mm/slub.c:2731
 __split_vma+0x118/0x608 mm/mmap.c:2515
 do_munmap+0x194/0x9b0 mm/mmap.c:2636
Freed by task 26657:
 save_stack_trace_tsk+0x0/0x330 arch/arm64/kernel/stacktrace.c:133
 save_stack_trace+0x20/0x30 arch/arm64/kernel/stacktrace.c:216
 save_stack mm/kasan/kasan.c:515 [inline]
 set_track mm/kasan/kasan.c:527 [inline]
 kasan_slab_free+0x84/0x198 mm/kasan/kasan.c:592
 slab_free_hook mm/slub.c:1357 [inline]
 slab_free_freelist_hook mm/slub.c:1379 [inline]
 slab_free mm/slub.c:2961 [inline]
 kmem_cache_free+0x80/0x258 mm/slub.c:2983
 __vma_adjust+0x6b0/0xf mm/mmap.c:890]  el0_svc_naked+0x24/0x28

The buggy address belongs to the object at 80003b9a2000
 which belongs to the cache vm_area_struct(647:session-6.scope) of size 184
The buggy address is located 64 bytes inside of
 184-byte region [80003b9a2000, 80003b9a20b8)
The buggy address belongs to the page:
page:7eee6880 count:1 mapcount:0 mapping:  (null) index:0x0
flags: 0xfffc100(slab)
raw: 0fffc100   000180100010
raw:  000c0001 80005a5cc600 80005ac99980
page dumped because: kasan: bad access detected
page->mem_cgroup:80005ac99980

Memory state around the buggy address:
 80003b9a1f00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 80003b9a1f80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

80003b9a2000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

   ^
 80003b9a2080: fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc fb
 80003b9a2100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==


Another one that looks related and doesn't have parts of stack traces missing:

==
BUG: KASAN: use-after-free in find_vma+0x140/0x150 mm/mmap.c:2114
Read of size 8 at addr 800031a03e90 by task syz-executor/4360

CPU: 2 PID: 4360 Comm: syz-executor Not tainted
4.11.0-rc1-next-20170308-xc2-dirty #3
Hardware name: Hardkernel ODROID-C2 (DT)
Call trace:
[] dump_backtrace+0x0/0x440 arch/arm64/kernel/traps.c:505
[] show_stack+0x20/0x30 arch/arm64/kernel/traps.c:228
[] __dump_stack lib/dump_stack.c:16 [inline]
[] dump_stack+0x110/0x168 lib/dump_stack.c:52
[] print_address_description+0x60/0x248 mm/kasan/report.c:250
[] kasan_report_error+0xe8/0x250 mm/kasan/report.c:349
[] kasan_report mm/kasan/report.c:372 [inline]
[] __asan_report_load8_noabort+0x3c/0x48 mm/kasan/report.c:393
[] find_vma+0x140/0x150 mm/mmap.c:2114
[]

Re: [PATCH V12 09/10] trace, ras: add ARM processor error trace event

2017-03-14 Thread Xie XiuQi 
Hi Steven,

Thanks for you comments. As your suggestion, I've changed it in v2.

>From c29c14c3b960f55beb4c4b22b7aced64fa7daf9a Mon Sep 17 00:00:00 2001
From: Xie XiuQi 
Date: Mon, 13 Mar 2017 15:46:06 +0800
Subject: [PATCH v2] trace: ras: add ARM processor error information trace event

Add a new trace event for ARM processor error information, so that
the user will know what error occurred. With this information the
user may take appropriate action.

These trace events are consistent with the ARM processor error
information table which defined in UEFI 2.6 spec section N.2.4.4.1.

---
v2: add trace enabled condition as Steven's suggestion.
fix a typo.

Signed-off-by: Xie XiuQi 
---
 drivers/acpi/apei/ghes.c | 10 ++
 include/linux/cper.h |  5 +++
 include/ras/ras_event.h  | 87 
 3 files changed, 102 insertions(+)

diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 251d7e0..bcb8160 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -518,9 +518,19 @@ static void ghes_do_proc(struct ghes *ghes,
else if (!uuid_le_cmp(sec_type, CPER_SEC_PROC_ARM) &&
 trace_arm_event_enabled()) {
struct cper_sec_proc_arm *arm_err;
+   struct cper_arm_err_info *err_info;
+   int i;

arm_err = acpi_hest_generic_data_payload(gdata);
trace_arm_event(arm_err);
+
+   if (trace_arm_proc_err_enabled()) {
+   err_info = (struct cper_arm_err_info *)(arm_err 
+ 1);
+   for (i = 0; i < arm_err->err_info_num; i++) {
+   trace_arm_proc_err(err_info);
+   err_info += 1;
+   }
+   }
} else if (trace_unknown_sec_event_enabled()) {
void *unknown_err = 
acpi_hest_generic_data_payload(gdata);
trace_unknown_sec_event(_type,
diff --git a/include/linux/cper.h b/include/linux/cper.h
index 85450f3..0cae900 100644
--- a/include/linux/cper.h
+++ b/include/linux/cper.h
@@ -270,6 +270,11 @@ enum {
 #define CPER_ARM_INFO_VALID_VIRT_ADDR  0x0008
 #define CPER_ARM_INFO_VALID_PHYSICAL_ADDR  0x0010

+#define CPER_ARM_INFO_TYPE_CACHE   0
+#define CPER_ARM_INFO_TYPE_TLB 1
+#define CPER_ARM_INFO_TYPE_BUS 2
+#define CPER_ARM_INFO_TYPE_UARCH   3
+
 #define CPER_ARM_INFO_FLAGS_FIRST  0x0001
 #define CPER_ARM_INFO_FLAGS_LAST   0x0002
 #define CPER_ARM_INFO_FLAGS_PROPAGATED 0x0004
diff --git a/include/ras/ras_event.h b/include/ras/ras_event.h
index b36db48..0f9f46e 100644
--- a/include/ras/ras_event.h
+++ b/include/ras/ras_event.h
@@ -195,6 +195,93 @@
  __entry->running_state, __entry->psci_state)
 );

+#define ARM_PROC_ERR_TYPE  \
+   EM ( CPER_ARM_INFO_TYPE_CACHE, "cache error" )  \
+   EM ( CPER_ARM_INFO_TYPE_TLB,  "TLB error" ) \
+   EM ( CPER_ARM_INFO_TYPE_BUS, "bus error" )  \
+   EMe ( CPER_ARM_INFO_TYPE_UARCH, "micro-architectural error" )
+
+#define ARM_PROC_ERR_FLAGS \
+   EM ( CPER_ARM_INFO_FLAGS_FIRST, "First error captured" )\
+   EM ( CPER_ARM_INFO_FLAGS_LAST,  "Last error captured" ) \
+   EM ( CPER_ARM_INFO_FLAGS_PROPAGATED, "Propagated" ) \
+   EMe ( CPER_ARM_INFO_FLAGS_OVERFLOW, "Overflow" )
+
+/*
+ * First define the enums in MM_ACTION_RESULT to be exported to userspace
+ * via TRACE_DEFINE_ENUM().
+ */
+#undef EM
+#undef EMe
+#define EM(a, b) TRACE_DEFINE_ENUM(a);
+#define EMe(a, b)  TRACE_DEFINE_ENUM(a);
+
+ARM_PROC_ERR_TYPE
+ARM_PROC_ERR_FLAGS
+
+/*
+ * Now redefine the EM() and EMe() macros to map the enums to the strings
+ * that will be printed in the output.
+ */
+#undef EM
+#undef EMe
+#define EM(a, b)   { a, b },
+#define EMe(a, b)  { a, b }
+
+TRACE_EVENT(arm_proc_err,
+
+   TP_PROTO(const struct cper_arm_err_info *err),
+
+   TP_ARGS(err),
+
+   TP_STRUCT__entry(
+   __field(u8, type)
+   __field(u16, multiple_error)
+   __field(u8, flags)
+   __field(u64, error_info)
+   __field(u64, virt_fault_addr)
+   __field(u64, physical_fault_addr)
+   ),
+
+   TP_fast_assign(
+   __entry->type = err->type;
+
+   if (err->validation_bits & CPER_ARM_INFO_VALID_MULTI_ERR)
+   __entry->multiple_error = err->multiple_error;
+   else
+   __entry->multiple_error = ~0;
+   
+   if (err->validation_bits & CPER_ARM_INFO_VALID_FLAGS)
+   __entry->flags = err->flags;
+   else
+