Bug 191533

Created attachment 354782 [details] Patch

Comment on attachment 354782 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=354782&action=review Looks good. r=me > Source/WebKit/ChangeLog:4 > + https://bugs.webkit.org/show_bug.cgi?id=191533 Please always include a radar for these changes. > Source/WebKit/ChangeLog:14 > + sufficient as the arrived init response will piped in HidConnection::m_inputReports, which is designed in "will BE piped THROUGH HidConnection::m_inputReports..." > Source/WebKit/ChangeLog:15 > + purpose to store any data packets within (initialized, terminated) time interval to prevent data loss in "... which is designed ON purpose to ..." > Source/WebKit/UIProcess/WebAuthentication/fido/CtapHidDriver.cpp:59 > + // HidConnection could hold data from other applications, and thereofore invalidate it before each transaction. It seems like this could be the source of difficult-to-debug issues in the future, though I guess not in WebKit after this change. I wonder how other groups deal with HID connections that contain existing data.

<rdar://problem/46103502>

Comment on attachment 354782 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=354782&action=review Thanks Brent for r+ this change. >> Source/WebKit/ChangeLog:4 >> + https://bugs.webkit.org/show_bug.cgi?id=191533 > > Please always include a radar for these changes. Sure. >> Source/WebKit/ChangeLog:14 >> + sufficient as the arrived init response will piped in HidConnection::m_inputReports, which is designed in > > "will BE piped THROUGH HidConnection::m_inputReports..." Fixed. >> Source/WebKit/ChangeLog:15 >> + purpose to store any data packets within (initialized, terminated) time interval to prevent data loss in > > "... which is designed ON purpose to ..." Fixed. >> Source/WebKit/UIProcess/WebAuthentication/fido/CtapHidDriver.cpp:59 >> + // HidConnection could hold data from other applications, and thereofore invalidate it before each transaction. > > It seems like this could be the source of difficult-to-debug issues in the future, though I guess not in WebKit after this change. I wonder how other groups deal with HID connections that contain existing data. Well, actually the CTAPHID_INIT response is the only one we need to pay attention to as the channel id embedded is the same for every application. Other cmd will use a dedicated channel id which is unique per app. Chromium is kind of merging our CtapHidDriver::Worker and CtapHidDriver together, so they just keep reading the pipe when a wrong nonce arrive.This design is free of the deadlock I describe in the change log however it makes the whole driver has much more complicated states than us. At the meantime, our design is simple, CtapHidDriver::Worker only handles each transaction, it doesn't care the content of each transaction. CtapHidDriver manages all states such as channel allocation. Since the worker doesn't care the content of each transaction, it won't know the nonce of the incoming legitimate response (a completed response with a right channel id) is not the expected one, and therefore terminates the transaction. And there is no ways for CtapHidDriver to ask the worker to open a semi transaction which is read only to exhaust the pipe. Therefore, it issues a new transaction. Since the described dead lock should be a quite rare situation in real world as it requires two apps send init cmd at the same time to trigger. I couldn't image how a legitimate user would do this. Therefore, there is no need to make a huge change to tackle this particular issue.

Created attachment 354972 [details] Patch for landing

Comment on attachment 354972 [details] Patch for landing Clearing flags on attachment: 354972 Committed r238246: <https://trac.webkit.org/changeset/238246>

All reviewed patches have been landed. Closing bug.