Re: [PATCH 3/4] x86/kvm: Resolve shadow warnings in macro expansion
Il 25/07/2014 19:18, Rustad, Mark D ha scritto:
On Jul 25, 2014, at 7:06 AM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 25/07/2014 15:27, Jeff Kirsher ha scritto:
From: Mark Rustad mark.d.rus...@intel.com
Resolve shadow warnings that appear in W=2 builds. In this case,
a macro declared an inner local variable with the same name as an
outer one. This can be a serious hazard in the event that the outer
variable is ever passed as a parameter, as the inner variable will
be referenced instead of what was intended. This macro doesn't have
any parameters - at this time - but prepend an _ to all of the
macro-declared variables as is the custom, to resolve the warnings
and eliminate any future hazard.
Signed-off-by: Mark Rustad mark.d.rus...@intel.com
Signed-off-by: Jeff Kirsher jeffrey.t.kirs...@intel.com
---
arch/x86/kvm/mmutrace.h | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/x86/kvm/mmutrace.h b/arch/x86/kvm/mmutrace.h
index 9d2e0ff..2d8d00c 100644
--- a/arch/x86/kvm/mmutrace.h
+++ b/arch/x86/kvm/mmutrace.h
@@ -22,26 +22,26 @@
__entry-unsync = sp-unsync;
#define KVM_MMU_PAGE_PRINTK() ({\
- const char *ret = p-buffer + p-len; \
- static const char *access_str[] = { \
+ const char *_ret = p-buffer + p-len; \
+ static const char *_access_str[] = {\
---, --x, w--, w-x, -u-, -ux, wu-, wux \
}; \
- union kvm_mmu_page_role role; \
+ union kvm_mmu_page_role _role; \
\
- role.word = __entry-role; \
+ _role.word = __entry-role; \
\
trace_seq_printf(p, sp gen %lx gfn %llx %u%s q%u%s %s%s \
%snxe root %u %s%c, __entry-mmu_valid_gen, \
-__entry-gfn, role.level, \
-role.cr4_pae ? pae : ,\
-role.quadrant, \
-role.direct ? direct : , \
-access_str[role.access], \
-role.invalid ? invalid : ,\
-role.nxe ? : !, \
+__entry-gfn, _role.level, \
+_role.cr4_pae ? pae : , \
+_role.quadrant,\
+_role.direct ? direct : , \
+_access_str[_role.access], \
+_role.invalid ? invalid : , \
+_role.nxe ? : !, \
__entry-root_count, \
__entry-unsync ? unsync : sync, 0); \
- ret;\
+ _ret; \
})
#define kvm_mmu_trace_pferr_flags \
I think this unnecessarily uglifies the code, so I am not applying it.
Gleb, what do you think?
Would you consider a version that only changes ret to _ret?
That would be more acceptable, or even better I guess you could stash
away p-len and return p-buffer + saved_len.
The thing is that it makes no sense for the caller's ret to alias any
of the other local variables of the macro. So the code gets uglier but
the only one to benefit is the compiler.
Paolo
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 6/6] kvm, mem-hotplug: Reload L1's apic access page if it is migrated when L2 is running.
On 2014-07-23 21:42, Tang Chen wrote: This patch only handle L1 and L2 vm share one apic access page situation. When L1 vm is running, if the shared apic access page is migrated, mmu_notifier will request all vcpus to exit to L0, and reload apic access page physical address for all the vcpus' vmcs (which is done by patch 5/6). And when it enters L2 vm, L2's vmcs will be updated in prepare_vmcs02() called by nested_vm_run(). So we need to do nothing. When L2 vm is running, if the shared apic access page is migrated, mmu_notifier will request all vcpus to exit to L0, and reload apic access page physical address for all L2 vmcs. And this patch requests apic access page reload in L2-L1 vmexit. Shouldn't this patch come before we allow apic access page migration? Jan signature.asc Description: OpenPGP digital signature
Re: Verifying Execution Integrity in Untrusted hypervisors
On Sat, Jul 26, 2014 at 2:06 AM, Paolo Bonzini pbonz...@redhat.com wrote: Thanks a lot Paolo. Is there a way to atleast detect that the hypervisor has done something malicious and the client will be able to refer to some kind of logs to prove it? If you want a theoretical, perfect solution, no. I wouldn't be surprised if this is equivalent to the halting problem. If you want a practical solution, you have to define a threat model. What kind of attacks are you worried about? Which parts of the environment can you control? Can you place something trusted between the vulnerable VM and its clients? And so on. Paolo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Here are some bits I read before: https://www.cs.purdue.edu/homes/bb/cs590/papers/secure_vm.pdf. It`s all about timing measurement after all, if you`ll be able to measure them or derive methods from, say, cache correlation attacks to avoid possibility of continuous hijack due to knowledge of amount of computation/timings which will not be possible with constant Eve measurements. you can complete task at a half. Complete execution without continuous checking against locally placed trusted blackbox equivalent (hardware token, trusted execution replaying or so) is hardly possible by my understanding. Anyway, any of imaginable cases relies on a finite amount of computing power available to a single thread, so I can hardly say that real-world implementation *is secure*, though we can define high probability of it. I believe that the homomorphic encryption can do its way for at least some kind of services by next decade, due to tendency of total cloudization, and this is definitely better than sticks-and-mud approach with timings. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
