Re: [Xen-devel] [PATCH v3] vm_event: Implement ARM SMC events

[Tamas K Lengyel <tamas.lengyel@xxxxxxxxxxxx>]

>> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
>> index 39a05fd..cf58fd5 100644
>> --- a/xen/arch/arm/traps.c
>> +++ b/xen/arch/arm/traps.c
>> @@ -41,6 +41,7 @@
>>  #include <asm/mmio.h>
>>  #include <asm/cpufeature.h>
>>  #include <asm/flushtlb.h>
>> +#include <asm/monitor.h>
>>
>>  #include "decode.h"
>>  #include "vtimer.h"
>> @@ -2527,6 +2528,16 @@ bad_data_abort:
>>      inject_dabt_exception(regs, info.gva, hsr.len);
>>  }
>>
>> +static void do_trap_smc(struct cpu_user_regs *regs, const union hsr hsr)
>> +{
>> +    int rc = 0;
>
>
> Missing blank line.
>
>> +    if ( current->domain->arch.monitor.privileged_call_enabled )
>> +        rc = monitor_smc();
>> +
>> +    if ( rc != 1 )
>> +        inject_undef_exception(regs, hsr);
>
>
> It would be worth mentioning somewhere that you expect the monitor app
> skipping the instruction.
>

Not necessarily. If it's an SMC the guest issues by itself then yes,
it can be safely turned effectively into a NOP by incrementing PC. But
there are other things the monitor application can do as well. For
example, during malware analysis if we want to remain stealthy we
would still want to inject an undefined instruction exception, or even
destroy the guest altogether, otherwise the NOP-d SMC would reveal the
presence of the monitor application. For SMC's that the monitor
application itself injects, just incrementing the PC would not be
enough either as we overwrote an instruction that should be executed
to continue normal execution. That problem can also be solved, and
also not by incrementing the PC.

Tamas

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