linux-kernel - Re: [PATCH RFC 0/3] Drivers: hv: utils: re-implement the kernel/userspace communication layer

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]

Message-ID: <20150227210744.GA11904@potion.brq.redhat.com>
Date:	Fri, 27 Feb 2015 22:07:44 +0100
From:	Radim Krčmář <rkrcmar@...hat.com>
To:	Vitaly Kuznetsov <vkuznets@...hat.com>
Cc:	"K. Y. Srinivasan" <kys@...rosoft.com>,
	devel@...uxdriverproject.org,
	Haiyang Zhang <haiyangz@...rosoft.com>,
	linux-kernel@...r.kernel.org, Dexuan Cui <decui@...rosoft.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-api@...r.kernel.org
Subject: Re: [PATCH RFC 0/3] Drivers: hv: utils: re-implement the
 kernel/userspace communication layer

2015-02-27 17:14+0100, Vitaly Kuznetsov:
> This series converts kvp/vss daemons to use misc char devices instead of
> netlink for userspace/kernel communication and then updates fcopy to be
> consistent with kvp/vss.
> 
> Userspace/kernel communication via netlink has a number of issues:
> - It is hard for userspace to figure out if the kernel part was loaded or not
>   and this fact can change as there is a way to enable/disable the service from
>   host side.

(Hm, this should be just a message to the userspace daemon, but netlink
 probably makes it complicated anyway.)

>              Racy daemon startup is also a problem.

(Is it significantly worse than what we need to protect devices?)

> - When the userspace daemon restarts/dies kernel part doesn't receive a
>   notification.

(True, we could use a other-side-closed callback.)

> - Netlink communication is not stable under heavy load.

(The message order changes?)

> RFC: I'm a bit puzzled on how to split commits 1 and 2 avoiding breakages.

Split the userspace part -- it won't break bisects.

And then, you could refactor drivers first ... the way we communicate
with userspace should have little impact on what the rest does (or how).
At first sight, there are three units, apart from glue,
 1) communication with host
 2) communication with userspace
 3) repacking of data between first two

With an API for userspace communication, the amount of code to replace
netlink could be lower and resulting patches definitely easier to
review.  (And with extra work, both ABIs could even live side-by-side ;)
--
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/