On Tue, Apr 12, 2016 at 11:05 AM, Corneliu ZUZU <cz...@bitdefender.com> wrote:
> On 4/12/2016 7:24 PM, Julien Grall wrote: > >> Hello, >> >> On 12/04/2016 16:01, Tamas K Lengyel wrote: >> >>> >>> On Apr 12, 2016 01:51, "Corneliu ZUZU" <cz...@bitdefender.com >>> <mailto:cz...@bitdefender.com>> wrote: >>> > >>> > On 4/11/2016 10:47 PM, Tamas K Lengyel wrote: >>> >> >>> >> From: Tamas K Lengyel <tkleng...@sec.in.tum.de >>> <mailto:tkleng...@sec.in.tum.de>> >>> >> >>> >> The ARM SMC instructions are already configured to trap to Xen by >>> default. In >>> >> this patch we allow a user-space process in a privileged domain to >>> receive >>> >> notification of when such event happens through the vm_event >>> subsystem. >>> >> >>> >> This patch will likely needs to be broken up into several smaller >>> patches. >>> >> Right now what this patch adds (and could be broken into smaller >>> patches >>> >> accordingly): >>> >> - Implement monitor_op domctl handler for SOFTWARE_BREAKPOINTs >>> on ARM >>> >> - Implement vm_event register fill/set routines for ARM. This >>> required >>> >> removing the function from common as the function prototype >>> now >>> >> differs on the two archs. >>> >> - Sending notification as SOFTWARE_BREAKPOINT vm_event from the >>> SMC trap >>> >> handlers. >>> >> - Extend the xen-access test tool to receive SMC notification >>> and step >>> >> the PC manually in the reply. >>> >> >>> >> I'm sending it as an RFC to gather feedback on what has been >>> overlooked in this >>> >> revision. This patch has been tested on a Cubietruck board and works >>> fine, >>> >> but would probably not work on 64-bit boards. >>> > >>> > >>> > Hi Tamas, >>> > >>> > If I may, I'm still unable to work at the moment, being ill, but I'm >>> checking the xen-devel lists from time to time. >>> > Your patch caught my attention, reminding me of the conversation we >>> had some time ago on this matter. >>> > The only real reason I don't see SMC (secure-monitor-call) as being >>> an ideal candidate for this is that, according to the ARM manuals, SMC >>> should directly cause undefined exception if executed from user-mode >>> (EL0), instead of a hypervisor trap - isn't that the case on the machine >>> you tested this on or is this really only for the EL1 of domains? >>> >> >> This paragraph is part of Corneliu's answer but it gives the impression >> you wrote it. Can you configure your e-mail client to quote properly? >> >> >>> That's correct, it can only be issued by the kernel. So as long as you >>> want to monitor the kernel it can be used just fine. I can also envision >>> trampoline-like traps (syscalls injected into EL0 to trigger SMC) but >>> that's beyond the scope I intend this for now. >>> >> > Then indeed SMC is the -easiest- way to go, @ least until user-mode > breakpoints are implemented. > > >>> > >>> > Also: >>> > - SMC, by definition, is a call to the secure side, it doesn't relate >>> to debugging directly (it's a syscall to the 'secure' side). There is a >>> viable INT3 equivalent on ARM, that being the BKPT/BRK instruction, >>> using that instead would require a bit more effort (but would, >>> conceptually, be more correct) and might be less performant, I suppose >>> that's why you didn't go for that? >>> >> >> BKPT/BRK could be used by the guest for debugging. You would need to >> differentiate a breakpoint inserted by Xen or by a debugger in the guest. >> > > Isn't that also the case for X86's INT3? I guess differentiation is done > based on the bkpt address/privilege level? On ARM that could also > (partially) be done by looking @ the immediate value of the BKPT/BRK > instruction. Another thing I realized might be troublesome with NOT using > BKPT/BRK would be that on ARMv7 BKPT is always unconditional, even in IT > blocks. IDK if that applies to SMC, but if it doesn't you'd have to check > for that as well to make sure the breakpoint is actually executed. > > >> >>> I would have to double check but AFAIK those instructions can't be >>> configured to trap to the hypervisor directly. So while SMC was not >>> intended to be a breakpoint, conceptually it's the closest thing we have >>> an on ARM to the INT3 instruction when configured to trap to the VMM. >>> >> >> > Please see AArch32 HDCR.TDE and AArch64 MDCR_EL2.TDE bits. Since > activating this bit would imply additional (in this context -unwanted-) > traps, the performance hit of having this bit set might be significant. > Right, actually I believe KVM already implemented this, I was just under the impression it was only for aarch64. As for performance overhead I'm not that worried about it, rather I need to make sure the presence of the monitoring can remain stealthy. I know on KVM for example this type of trapping renders the guest to be unable to use singlestepping, which would easily reveal the presence of the external monitor (see https://lists.cs.columbia.edu/pipermail/kvmarm/2015-May/014589.html). So this will need to be looked at carefully. > > Whilst any access to SMC currently results to inject an undefined >> exception, it may not be the case in the future. There have been discussion >> to allow guest issuing SMC call (see [1]). >> > I don't see a problem with that, as long as it's configurable whether SMC calls are trapped or pass-through. > >> I think the safest instruction would be HVC #imm. Xen is only using a >> small number of immediate. You could allocate a specific value for software >> debugging. >> >> > IMHO that would also be better conceptually, although it would still > suffer from the limitation of not being available from user-space (and > potentially from the above IT block issue). > Sure, HVC would also be a possibility but I do see use-cases for trapping SMC calls and forwarding them to a guest instead of the TZ. For example, if malware tries to exploit TZ vulnerabilities, it would be a lot easier to contain and monitor such exploits if the TZ is virtualized rather then just crashing the guest or forwarding the calls to a real TZ. So trapping SMC would allow us to use the real TZ for other purposes and maintain a barrier between malicious guests and the TZ. So what I will do instead of issuing a software_breakpoint vm_event for SMCs, I'll introduce a new type, say VM_EVENT_REASON_PRIVILEGED_CALL, that can be used to forward both hypercalls and SMCs to a monitoring guest. This would also allow us to use the software_breakpoint type for the actual software breakpoint events in the future. Tamas
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
