linux-kernel - Re: [PATCH 08/16] x86: Emergency virtualization disable function

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] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 5 Nov 2008 15:52:35 -0200
From:	Eduardo Habkost <ehabkost@...hat.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Avi Kivity <avi@...hat.com>, Ingo Molnar <mingo@...e.hu>,
	Simon Horman <horms@...ge.net.au>,
	Andrew Morton <akpm@...l.org>, Vivek Goyal <vgoyal@...hat.com>,
	Haren Myneni <hbabu@...ibm.com>,
	Andrey Borzenkov <arvidjaar@...l.ru>, mingo@...hat.com,
	"Rafael J. Wysocki" <rjw@...k.pl>, kexec@...ts.infradead.org,
	kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 08/16] x86: Emergency virtualization disable function

On Wed, Nov 05, 2008 at 09:33:06AM -0800, Eric W. Biederman wrote:
> Eduardo Habkost <ehabkost@...hat.com> writes:
> 
> > +int set_virt_disable_func(void (*fn)(void))
> > +{
> > +	int r = 0;
> > +
> > +	spin_lock(&virt_disable_lock);
> > +	if (!virt_disable_fn)
> > +		rcu_assign_pointer(virt_disable_fn, fn);
> > +	else
> > +		r = -EEXIST;
> > +	spin_unlock(&virt_disable_lock);
> > +
> > +	return r;
> > +}
> > +EXPORT_SYMBOL(set_virt_disable_func);
> 
> EXPORT_SYMBOL_GPL?
> 
> > +EXPORT_SYMBOL(clear_virt_disable_func);
> EXPORT_SYMBOL_GPL?
> 
> We are talking a core internal api that should not even
> be exported if KVM is compiled into the kernel.
> 
> I have had to tell people NO too many times by that
> wanted to shove code on the kexec on panic path that
> had no business there.  I do not want to give
> the least little impression that this is an ok hook
> for the to use.  The very specific name helps in
> that regard thank you for that.  Having the symbol
> exported GPL would help even more.

Agreed. I will change that if nobody else objects.

> 
> Overall I think the code is just barely ok.
> 
> I don't like the fact that to run 2-3 instructions per cpu we are two
> function pointers deep.  It feels like we have an excess of
> abstraction here on the kvm side.
> 
> Is it possible to have the individual kvm modules call
> set_virt_disable_func and clear_virt_disable_func?  Instead
> of going through the x86_kvm_ops?
> 
> It really feels like we have an excess of abstraction here.

We could move the set_virt_disable_func() calls to vmx.c and svm.c (on
hardware_setup/hardware_unsetup). One could argue that it is sort of a
coincidence that we need the code for both vmx and svm.

Avi, what do you think?

-- 
Eduardo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/