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

Date:	Thu, 09 Oct 2014 12:56:34 +0200
From:	Michal Nazarewicz <mina86@...a86.com>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Felipe Balbi <balbi@...com>,
	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, andrzej.p@...sung.com
Subject: Re: [PATCH] usb: gadget: f_fs: add "zombie" mode

>> On Tue, Oct 07 2014, Alan Stern <stern@...land.harvard.edu> wrote:
>>> If you want to allow for the possibility of orderly shutdown (and maybe 
>>> even possible restart) of a userspace handler, the function library 
>>> should first tell the kernel explicitly to disconnect.

> On Tue, 7 Oct 2014, Michal Nazarewicz wrote:
>> I'm wondering if it would be possible to support user-space daemon
>> restarts with O_APPEND flag.  This is probably looking too far to the
>> future though.

On Wed, Oct 08 2014, Alan Stern <stern@...land.harvard.edu> wrote:
> Actually, we shouldn't need to consider the case where the descriptors
> change.  That _always_ requires a disconnect, and the user can cause
> a disconnect simply by killing the daemon and starting it again.  No
> separate restart capability is needed.

Correct.  This may be going a bit off-topic, but I was thinking of
a possible feature that would allow the daemon to indicate to kernel it
is ready to pick up the pieces after its previous instance crashed.
This would require the zombie mode to be implemented.

* Currently, once the daemon finishes or crashes, USB disconnect
  happens.

* In zombie mode, I could imagine the following scenarios:
  - daemon crashes, but the gadget still works, no disconnect happens;
  - daemon opens ep0 with O_APPEND, no disconnect happens;
  - daemon sends *the same* descriptors as before;
  - kernel recreates all the ep# files and let the daemon continue
    handling USB requests with host possibly never noticing.

Opening ep0 w/o O_APPEND or sending different descriptors would cause
a disconnect.  With the above, user-space would be able to force gadget
to disconnect by killing the daemon and then doing
    printf '' >/dev/functionfs/ep0
  
So I guess my point is that with zombie mode, user space could tell the
kernel to not-disconnect (rather than having an explicit disconnect
request) if it was written in a way that supports crash recovery.

This is a wishful thinking at this stage I guess, but perhaps it's worth
considering when deciding how the zombie interface should look like.
For example, I have some concerns if it should be enabled by an fs mount
option.

-- 
Best regards,                                         _     _
.o. | Liege of Serenely Enlightened Majesty of      o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz    (o o)
ooo +--<mpn@...gle.com>--<xmpp:mina86@...ber.org>--ooO--(_)--Ooo--
--
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/