|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH V3 1/3] xen/mem_access: Support for memory-content hiding
>>> On 06.07.15 at 17:51, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -269,6 +269,7 @@ struct vcpu *alloc_vcpu_struct(void)
>
> void free_vcpu_struct(struct vcpu *v)
> {
> + xfree(v->arch.vm_event.emul_read_data);
> free_xenheap_page(v);
> }
Please note the function's name - nothing else should be freed here imo.
> @@ -893,6 +915,24 @@ static int hvmemul_cmpxchg(
> unsigned int bytes,
> struct x86_emulate_ctxt *ctxt)
> {
> + struct hvm_emulate_ctxt *hvmemul_ctxt =
> + container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
> +
> + if ( unlikely(hvmemul_ctxt->set_context) )
> + {
> + struct vcpu *curr = current;
> +
> + if ( curr->arch.vm_event.emul_read_data )
> + {
hvmemul_read() returns X86EMUL_UNHANDLEABLE when
!curr->arch.vm_event.emul_read_data. I think this ought to
be consistent.
> + unsigned int safe_bytes = min_t(unsigned int, bytes,
> + curr->arch.vm_event.emul_read_data->size);
> +
> + memset(p_new, 0, bytes);
> + memcpy(p_new, curr->arch.vm_event.emul_read_data->data,
> + safe_bytes);
Here as well as in elsewhere - pretty inefficient to zero the
whole array in order to then possibly overwrite all of it. I'd really
like to see only the excess bytes to be zeroed.
> @@ -935,6 +975,41 @@ static int hvmemul_rep_ins(
> !!(ctxt->regs->eflags & X86_EFLAGS_DF), gpa);
> }
>
> +static int hvmemul_rep_outs_set_context(
> + enum x86_segment src_seg,
> + unsigned long src_offset,
> + uint16_t dst_port,
> + unsigned int bytes_per_rep,
> + unsigned long *reps,
> + struct x86_emulate_ctxt *ctxt)
> +{
> + unsigned int bytes = *reps * bytes_per_rep;
> + struct vcpu *curr = current;
> + unsigned int safe_bytes;
> + char *buf = NULL;
> + int rc;
> +
> + if ( !curr->arch.vm_event.emul_read_data )
> + return X86EMUL_UNHANDLEABLE;
> +
> + buf = xmalloc_bytes(bytes);
> +
> + if ( buf == NULL )
> + return X86EMUL_UNHANDLEABLE;
> +
> + memset(buf, 0, bytes);
If this were to stay (see above), xzalloc_array() above please. And
xmalloc_array() otherwise.
> @@ -1063,7 +1142,20 @@ static int hvmemul_rep_movs(
> */
> rc = hvm_copy_from_guest_phys(buf, sgpa, bytes);
> if ( rc == HVMCOPY_okay )
> + {
> + struct vcpu *curr = current;
> +
> + if ( unlikely(hvmemul_ctxt->set_context) &&
> + curr->arch.vm_event.emul_read_data )
> + {
> + unsigned int safe_bytes = min_t(unsigned int, bytes,
> + curr->arch.vm_event.emul_read_data->size);
> +
> + memcpy(buf, curr->arch.vm_event.emul_read_data->data,
> safe_bytes);
> + }
This again is inconsistent with what you do above: You need to
decide whether excess data (beyond safe_bytes) is safe to read
(like you do here) or should be returned as zeroes (as done above).
> @@ -1599,6 +1711,7 @@ static int _hvm_emulate_one(struct hvm_emulate_ctxt
> *hvmemul_ctxt,
> int hvm_emulate_one(
> struct hvm_emulate_ctxt *hvmemul_ctxt)
> {
> + hvmemul_ctxt->set_context = 0;
I think this would better go into hvm_emulate_prepare().
> @@ -1616,10 +1736,16 @@ void hvm_mem_access_emulate_one(bool_t nowrite,
> unsigned int trapnr,
>
> hvm_emulate_prepare(&ctx, guest_cpu_user_regs());
>
> - if ( nowrite )
> + switch ( kind ) {
Coding style (also elsewhere in the patch).
> + case EMUL_KIND_NOWRITE:
> rc = hvm_emulate_one_no_write(&ctx);
> - else
> + break;
> + case EMUL_KIND_SET_CONTEXT:
> + rc = hvm_emulate_one_set_context(&ctx);
Unless you see future uses for it, please expand the wrapper here.
> @@ -1552,9 +1556,15 @@ bool_t p2m_mem_access_check(paddr_t gpa, unsigned long
> gla,
>
> if ( v->arch.vm_event.emulate_flags )
> {
> - hvm_mem_access_emulate_one((v->arch.vm_event.emulate_flags &
> - MEM_ACCESS_EMULATE_NOWRITE) != 0,
> - TRAP_invalid_op,
> HVM_DELIVER_NO_ERROR_CODE);
> + enum emul_kind kind = EMUL_KIND_NORMAL;
> +
> + if ( v->arch.vm_event.emulate_flags & MEM_ACCESS_SET_EMUL_READ_DATA )
> + kind = EMUL_KIND_SET_CONTEXT;
> + else if ( v->arch.vm_event.emulate_flags &
> MEM_ACCESS_EMULATE_NOWRITE )
Is there code in place rejecting both flags being set at once? I don't
recall having seen any...
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |