linux-kernel - RE: [PATCH 02/10] Drivers: hv: utils: run polling callback always in interrupt context

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 for Android: free password hash cracker in your pocket

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

Message-ID: <SN1PR0301MB16622FC82DC4D34EBB8CB77EA0350@SN1PR0301MB1662.namprd03.prod.outlook.com>
Date:	Thu, 8 Oct 2015 14:55:57 +0000
From:	KY Srinivasan <kys@...rosoft.com>
To:	Vitaly Kuznetsov <vkuznets@...hat.com>,
	Olaf Hering <olaf@...fle.de>
CC:	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devel@...uxdriverproject.org" <devel@...uxdriverproject.org>,
	"apw@...onical.com" <apw@...onical.com>,
	"jasowang@...hat.com" <jasowang@...hat.com>
Subject: RE: [PATCH 02/10] Drivers: hv: utils: run polling callback always in
 interrupt context



> -----Original Message-----
> From: Vitaly Kuznetsov [mailto:vkuznets@...hat.com]
> Sent: Thursday, October 8, 2015 6:53 AM
> To: Olaf Hering <olaf@...fle.de>
> Cc: KY Srinivasan <kys@...rosoft.com>; gregkh@...uxfoundation.org; linux-
> kernel@...r.kernel.org; devel@...uxdriverproject.org; apw@...onical.com;
> jasowang@...hat.com
> Subject: Re: [PATCH 02/10] Drivers: hv: utils: run polling callback always in
> interrupt context
> 
> Olaf Hering <olaf@...fle.de> writes:
> 
> > On Thu, Oct 08, Vitaly Kuznetsov wrote:
> >
> >> > @@ -295,9 +288,6 @@ static int fcopy_on_msg(void *msg, int len)
> >> >  	if (fcopy_transaction.state == HVUTIL_DEVICE_INIT)
> >> >  		return fcopy_handle_handshake(*val);
> >> >
> >> > -	if (fcopy_transaction.state != HVUTIL_USERSPACE_REQ)
> >> > -		return -EINVAL;
> >> > -
> >>
> >> This particular change seems unrelated and I'm unsure it's safe to
> >> remove this check. It is meant to protect against daemon screwing the
> >> protocol and writing to the device when it wasn't requested for an
> >> action. It is correct to propagate -EINVAL in this case. Or am I missing
> >> something and the check is redundant now?
> >
> > What can happen if there is an odd write request?
> 
> I think we don't want to propagate misbehaving daemon's data to the
> host -- let's cut it here. E.g. imagine there is no communication going
> on and daemon starts writing something to the device. In case we remove
> the check we'll be doing fcopy_respond_to_host() for each daemon's write
> flooding the host.
> 
> > If there is a timeout
> > scheduled some return value will be sent to the host. Then the state is
> > set to RESET and eventually vmbus_recvpacket will receive something.
> > That something will be processed and passed to the daemon.
> >
> > If there was no timeout scheduled the write will just return.
> 
> yes, but after doing fcopy_respond_to_host(). I'd suggest we leave the
> check in place, better safe than sorry.

Agreed; Olaf, if it is ok with you, I can fix it up and send.

Regards,

K. Y
> 
> --
>   Vitaly
--
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/