linux-kernel - Re: [PATCH] usb: gadget: f

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: <Pine.LNX.4.44L0.1410071310550.1504-100000@iolanthe.rowland.org>
Date:	Tue, 7 Oct 2014 13:15:32 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Felipe Balbi <balbi@...com>
cc:	Krzysztof Opasiak <k.opasiak@...sung.com>,
	'Robert Baldyga' <r.baldyga@...sung.com>,
	<gregkh@...uxfoundation.org>, <linux-usb@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <mina86@...a86.com>,
	<andrzej.p@...sung.com>
Subject: Re: [PATCH] usb: gadget: f_fs: add "zombie" mode

On Tue, 7 Oct 2014, Felipe Balbi wrote:

> > Please believe me that I totally agree with you, but I also see Robert's
> > point. Let's take ADB as example. Before ADB has been ported to
> > FunctionFS it communicated with kernel using dev node provided by ADB
> > function driver. With that infrastructure death of daemon didn't cause
> > gadget unbind because kernel driver of that function was just stalling
> > the endpoints. This allows user to use all other functions of this
> 
> I really mixed feelings about that. It's really counter-intuitive to
> allow a non-working function to be exposed to the host.

...

> > Here also I agree. Zombie mode should "mock" the function until first
> > next enumeration or unbind. It should not be possible to bind gadget
> > with function in zombie mode to UDC. Zombie mode should "pretend" only
> > as long as gadget is bound and enumerated.
> 
> Not really. We shouldn't even coonect to host until adbd is running.
> Now, when adbd crashes we fix adbd. If it gets killed due to OOM we
> can't even say "ok, we'll buffer USB requests until adbd is restarted"
> because, well, we're running out of memory.
> 
> So, OOM we can't fix. Soon enough, another daemon (mtpd, ptpd, whatever)
> will be killed and another function will be left unusable.
> 
> As for adbd/mtpd/ptpd crashes, those need to fixed and kernel should not
> have to deal with them in any way.

It seems to me that we should imitate what an ordinary USB device would
do.  If part of the firmware crashes, generally you would expect none
of the endpoints associated with that function to work.  Either they
refuse to accept output from the host or they stall everything.  But
endpoints associated with other parts of the firmware might very well
continue to work okay.

Don't buffer requests.  Either allow the internal FIFOs to fill up or
else reject everything.  Any reasonable host will start getting timeout
expirations and will realize that something is wrong.

Alan Stern

--
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/