> -----Original Message----- > From: Paolo Bonzini [mailto:pbonzini@xxxxxxxxxx] > Sent: Friday, 22 December 2017 18:09 > To: Adalber Lazăr <alazar@xxxxxxxxxxxxxxx>; kvm@xxxxxxxxxxxxxxx > Cc: linux-mm@xxxxxxxxx; Radim Krčmář <rkrcmar@xxxxxxxxxx>; Xiao > Guangrong <guangrong.xiao@xxxxxxxxxxxxxxx>; Mihai Donțu > <mdontu@xxxxxxxxxxxxxxx>; Nicusor CITU <ncitu@xxxxxxxxxxxxxxx>; > Mircea CIRJALIU-MELIU <mcirjaliu@xxxxxxxxxxxxxxx>; Marian Cristian > ROTARIU <mrotariu@xxxxxxxxxxxxxxx> > Subject: Re: [RFC PATCH v4 08/18] kvm: add the VM introspection subsystem > > On 18/12/2017 20:06, Adalber Lazăr wrote: > > + print_hex_dump_debug("kvmi: new token ", DUMP_PREFIX_NONE, > > + 32, 1, token, sizeof(struct > kvmi_map_mem_token), > > + false); > > + > > + tep = kmalloc(sizeof(struct token_entry), GFP_KERNEL); > > + if (tep == NULL) > > + return -ENOMEM; > > + > > + INIT_LIST_HEAD(&tep->token_list); > > + memcpy(&tep->token, token, sizeof(struct > kvmi_map_mem_token)); > > + tep->kvm = kvm; > > + > > + spin_lock(&token_lock); > > + list_add_tail(&tep->token_list, &token_list); > > + spin_unlock(&token_lock); > > + > > + return 0; > > This allows unlimited allocations on the host from the introspector > guest. You must only allow a fixed number of unconsumed tokens (e.g. 64). > A few commits ago Adalbert Lazar suggested only one token for every VM (I guess introspected VM). Original text here: /* TODO: Should we limit the number of these tokens? * Have only one for every VM? */ I suggest using the token as an authentication key with finite life-time (similar to a banking token). The introspector (process/thread) can request a new token as soon as the old one expires. The introspected machine shouldn't be associated with the token in this case. > Thanks, > > Paolo > > ________________________ > This email was scanned by Bitdefender ��.n������g��� �a��� �&ޖ)���)��h���&������梷���� �Ǟ�m������)������^�����������v���O��zf������
