linux-kernel - Re: [PATCH v5 1/1] KVM: trigger uevents when creating or destroying a VM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 19 Jul 2017 18:21:06 +0200
From:   Radim Krčmář <rkrcmar@...hat.com>
To:     Claudio Imbrenda <imbrenda@...ux.vnet.ibm.com>
Cc:     David Hildenbrand <david@...hat.com>, kvm@...r.kernel.org,
        borntraeger@...ibm.com, pbonzini@...hat.com,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 1/1] KVM: trigger uevents when creating or destroying
 a VM

2017-07-17 18:27+0200, Claudio Imbrenda:
> On Mon, 17 Jul 2017 17:53:51 +0200
> David Hildenbrand <david@...hat.com> wrote:
> > > +		tmp = strchrnul(p + 1, '-');> +
> > > *tmp = '\0';
> > > +		add_uevent_var(env, "PID=%s", p);

When we're at it ... PID exists regardless of debugfs, so it would be
nice to provide it unconditionally.
(This interface looks like it was added to discourage the use of debugfs
 directory notifier in simple cases.)

I guess we cannot use task_pid_nr(current) on the KVM_EVENT_DESTROY_VM
path, so saving the PID in struct kvm would be better, IMO (it wastes
memory with larger number of VMs, but the code is harder to break).

> > > +			tmp = dentry_path_raw(kvm->debugfs_dentry,
> > > +					      pathbuf + len,
> > > +					      PATH_MAX - len);
> > > +			if (!IS_ERR(tmp)) {  
> > 
> > Why not
> > 
> > tmp = dentry_path_raw(kvm->debugfs_dentry, pathbuf, PATH_MAX);
> > if (!IS_ERR(tmp)) {
> > 	add_uevent_var(env, "STATS_PATH=s", tmp);
> > }
> > 
> > and avoid len / pvar / memcpy? And keep internal env size checking
> > consistent.
> 
> that would be true, but then we would copy the buffer with the path
> twice, once for dentry_path_raw and once for add_uevent_var.
> 
> the env size is consistent, since that would count the bytes
> effectively present in the buffer, and note that kobject_uevent_env only
> wants a char**, no length, so there are no consistency issues. 
> 
> I agree that your solution looks better (and I had actually considered
> implementing it like that initially), but it can potentially be slower.
> I don't really have any strong preference.
> 
> Paolo: which solution do you like the most? 

I slightly prefer the simpler version as performance of the path is not
that critical.

Please note that the original patch is already in 4.13 (it was ok and my
nitpicking would just make it miss the merge window :]), so the code
improvements need to be a new patch,

thanks.