xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@arm.com>
To: Tamas K Lengyel <tamas@tklengyel.com>
Cc: Xen-devel <xen-devel@lists.xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Steve Capper <Steve.Capper@arm.com>
Subject: Re: [PATCH v5 5/9] monitor: ARM SMC events
Date: Fri, 3 Jun 2016 15:43:06 +0100	[thread overview]
Message-ID: <5751977A.6080907@arm.com> (raw)
In-Reply-To: <CABfawhk6P05HwGtL0GOg-V5By5PoBKgUxBP3N+AB48s31cUBeg@mail.gmail.com>

Hello Tamas,

On 03/06/16 14:40, Tamas K Lengyel wrote:
>
> On Jun 3, 2016 03:49, "Julien Grall" <julien.grall@arm.com
> <mailto:julien.grall@arm.com>> wrote:
>  >
>  > Hello Tamas,
>  >
>  >
>  > On 02/06/16 23:52, Tamas K Lengyel wrote:
>  >>
>  >> diff --git a/xen/include/public/vm_event.h
> b/xen/include/public/vm_event.h
>  >> index 9270d52..797608Burrington0 100644
>  >> --- a/xen/include/public/vm_event.h
>  >> +++ b/xen/include/public/vm_event.h
>  >> @@ -119,6 +119,8 @@
>  >>   #define VM_EVENT_REASON_SINGLESTEP              7
>  >>   /* An event has been requested via HVMOP_guest_request_vm_event. */
>  >>   #define VM_EVENT_REASON_GUEST_REQUEST           8
>  >> +/* Privileged call executed (e.g. SMC) */
>  >> +#define VM_EVENT_REASON_PRIVILEGED_CALL         9
>  >>
>  >>   /* Supported values for the vm_event_write_ctrlreg index. */
>  >>   #define VM_EVENT_X86_CR0    0
>  >> @@ -212,6 +214,13 @@ struct vm_event_mov_to_msr {
>  >>       uint64_t value;
>  >>   };
>  >>
>  >> +#define VM_EVENT_PRIVCALL_SMC   0
>  >> +
>  >> +struct vm_event_privcall {
>  >> +    uint32_t type;
>  >> +    uint32_t vector; /* ESR_EL2.ISS for SMC calls */
>  >
>  >
>  > How do you expect the introspection app to deal with it? As explained `
> in a previous mail [1], the ISS encoding is different between ARMv7
> 32-bit and ARMv8 32-bit. The former is unknown (see B3-1431 in ARM DDI
> 0406C.c) whilst the latter contains fields related to the condition (see
> D7-1897 in ARM DDI 0406C.c).
>  >
>  > This is because on ARMv8, the conditional SMC issued in AArch32 state
> may trap even if the condition has failed.
>  >
>  > So the app would have to know whether the hypervisor is running on an
> ARMv7 or ARMv8 platform. But I am not aware of an easy way to
> differentiate it from the registers.
>
> The app can certainly run other checks to determine what the CPU version
> is, not being exclusively reliant on vm_event and running in a
> privileged domain.

Manufacturers are allowed to build their custom ARM processor based on 
the ARM ARM. The number of CPU version to check will likely be huge and 
you will not be future proof.
`
>
>  >
>  > Furthermore, I think the vm_event app should only received SMCs whose
> condition has succeeded, because they will be actual SMC. The others
> should just be ignored.
>  >
>  > IHMO, the vm_event should only contain the immediate. The rest only
> matters for the hypervisor.
>
> Absolutely not! The primary usecase I have for SMC trapping is kernel
> execution monitoring by manually writing it into arbitrary kernel code
> locations and hiding them from the guest with mem_access. If some SMCs
> may silently get swallowed by the hypervisor the whole thing becomes
> unreliable.

Please read what I wrote, on ARMv8, a conditional SMC issued in AArch32 
state *may* trap even if the condition has failed. I.e an implementer 
can design its CPU to not trap them (see D1-1506 on ARM DDI 0487A.i).

On ARMv7, only unconditional SMC and conditional SMC *which pass the 
condition test* will be trapped. The others will be ignored.

So even if the hypervisor send an event for each SMC trapped, you may 
not receive all the SMCs. This is already unreliable by the architecture.

If you want something reliable, you will have to inject unconditional 
SMC or HVC which are always unconditional.

If you want to also trap all the SMCs written by a guest, then you will 
have to live with the fact that some may be ignored. Although, I don't 
think that an introspection app should care about instructions that 
would be treated as a nop (for instance because the condition check has 
failed).

Hence my suggestion to check in the hypervisor whether the condition has 
failed and provide processor-agnostic information (the ISS is different 
between ARMv7, ARMv8 and AArch32 and AArch64).

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

  reply	other threads:[~2016-06-03 14:43 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-02 22:52 [PATCH v5 1/9] vm_event: clear up return value of vm_event_monitor_traps Tamas K Lengyel
2016-06-02 22:52 ` [PATCH v5 2/9] monitor: Rename vm_event_monitor_get_capabilities Tamas K Lengyel
2016-06-17 19:07   ` Tamas K Lengyel
2016-06-21  9:20   ` Julien Grall
2016-06-02 22:52 ` [PATCH v5 3/9] monitor: Rename vm_event_monitor_guest_request Tamas K Lengyel
2016-06-17 19:10   ` Tamas K Lengyel
2016-06-21  9:18   ` Julien Grall
2016-06-02 22:52 ` [PATCH v5 4/9] monitor: Rename hvm/event to hvm/monitor Tamas K Lengyel
2016-06-02 22:52 ` [PATCH v5 5/9] monitor: ARM SMC events Tamas K Lengyel
2016-06-03  9:49   ` Julien Grall
2016-06-03 13:40     ` Tamas K Lengyel
2016-06-03 14:43       ` Julien Grall [this message]
2016-06-03 15:03         ` Tamas K Lengyel
2016-06-03 15:06           ` Julien Grall
2016-06-03 15:42             ` Tamas K Lengyel
2016-06-03 15:27         ` Tamas K Lengyel
2016-06-03 15:34           ` Tamas K Lengyel
2016-06-04  9:03             ` Edgar E. Iglesias
2016-06-04 17:40               ` Tamas K Lengyel
2016-06-06 10:07                 ` Julien Grall
     [not found]                   ` <CABfawh=tOsUP1dQi9oAZM+iy3rMmCKDW=VByT-L-xYdAMBiMKw@mail.gmail.com>
     [not found]                     ` <CABfawhkSXqky9WWp8NyKEUrH_ZzSJToxAncTeSYeKBg1q63rwg@mail.gmail.com>
2016-06-06 15:24                       ` Tamas K Lengyel
2016-06-06 15:54                         ` Julien Grall
2016-06-06 15:56                           ` Tamas K Lengyel
2016-06-06 16:14                             ` Tamas K Lengyel
2016-06-06 16:38                               ` Julien Grall
2016-06-06 17:28                                 ` Tamas K Lengyel
2016-06-07  7:13                                 ` Jan Beulich
2016-06-07 10:30                                   ` Stefano Stabellini
2016-06-07 16:06                                     ` Tamas K Lengyel
2016-06-02 22:52 ` [PATCH v5 6/9] arm/vm_event: get/set registers Tamas K Lengyel
2016-06-03 10:34   ` Jan Beulich
2016-06-03 19:27     ` Tamas K Lengyel
2016-06-02 22:52 ` [PATCH v5 7/9] tools/libxc: add xc_monitor_privileged_call Tamas K Lengyel
2016-06-02 22:52 ` [PATCH v5 8/9] x86/vm_event: Add HVM debug exception vm_events Tamas K Lengyel
2016-06-03 10:49   ` Jan Beulich
2016-06-03 13:29     ` Tamas K Lengyel
2016-06-03 14:23       ` Jan Beulich
2016-06-03 14:34         ` Tamas K Lengyel
2016-06-03 14:45           ` Jan Beulich
2016-06-03 14:51             ` Tamas K Lengyel
2016-06-02 22:52 ` [PATCH v5 9/9] tools/xen-access: add test-case for ARM SMC Tamas K Lengyel
2016-06-03  7:08 ` [PATCH v5 1/9] vm_event: clear up return value of vm_event_monitor_traps Razvan Cojocaru
2016-06-03 15:54 ` Jan Beulich
2016-06-03 16:03   ` Tamas K Lengyel
2016-06-17 19:09 ` Tamas K Lengyel
2016-06-24 10:58   ` Tian, Kevin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5751977A.6080907@arm.com \
    --to=julien.grall@arm.com \
    --cc=Steve.Capper@arm.com \
    --cc=sstabellini@kernel.org \
    --cc=tamas@tklengyel.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).