From: Cord Amfmgm <dmamfmgm@gmail.com>
To: "Philippe Mathieu-Daudé" <philmd@linaro.org>
Cc: Michael Tokarev <mjt@tls.msk.ru>,
qemu-devel@nongnu.org, Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: hw/usb/hcd-ohci: Fix #1510, #303: pid not IN or OUT
Date: Wed, 8 May 2024 19:32:05 -0500 [thread overview]
Message-ID: <CACBuX0Qoz3cd7FjWGop9+qx3XU78TUxxjDkLMT8QQOZOJrmLhg@mail.gmail.com> (raw)
In-Reply-To: <CACBuX0QepgcGW=X9gYZzY9_9voZT1L+vstfqn_9FQmvpG0-sXQ@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 7321 bytes --]
On Wed, May 8, 2024 at 10:28 AM Cord Amfmgm <dmamfmgm@gmail.com> wrote:
>
>
> On Wed, May 8, 2024 at 4:53 AM Philippe Mathieu-Daudé <philmd@linaro.org>
> wrote:
>
>> On 7/5/24 22:20, Cord Amfmgm wrote:
>> >
>> >
>> > On Wed, Apr 24, 2024 at 3:43 PM Cord Amfmgm <dmamfmgm@gmail.com
>> > <mailto:dmamfmgm@gmail.com>> wrote:
>> >
>> > On Thu, Apr 18, 2024 at 10:43 AM Michael Tokarev <mjt@tls.msk.ru
>> > <mailto:mjt@tls.msk.ru>> wrote:
>> >
>> > 06.02.2024 10:13, Cord Amfmgm wrote:
>> > > This changes the ohci validation to not assert if invalid
>> > > data is fed to the ohci controller. The poc suggested in
>> > > https://bugs.launchpad.net/qemu/+bug/1907042
>> > <https://bugs.launchpad.net/qemu/+bug/1907042>
>> > > and then migrated to bug #303 does the following to
>> > > feed it a SETUP pid and EndPt of 1:
>> > >
>> > > uint32_t MaxPacket = 64;
>> > > uint32_t TDFormat = 0;
>> > > uint32_t Skip = 0;
>> > > uint32_t Speed = 0;
>> > > uint32_t Direction = 0; /* #define
>> > OHCI_TD_DIR_SETUP 0 */
>> > > uint32_t EndPt = 1;
>> > > uint32_t FuncAddress = 0;
>> > > ed->attr = (MaxPacket << 16) | (TDFormat << 15) |
>> > (Skip << 14)
>> > > | (Speed << 13) | (Direction << 11) |
>> > (EndPt << 7)
>> > > | FuncAddress;
>> > > ed->tailp = /*TDQTailPntr= */ 0;
>> > > ed->headp = ((/*TDQHeadPntr= */ &td[0]) &
>> 0xfffffff0)
>> > > | (/* ToggleCarry= */ 0 << 1);
>> > > ed->next_ed = (/* NextED= */ 0 & 0xfffffff0)
>> > >
>> > > qemu-fuzz also caught the same issue in #1510. They are
>> > > both fixed by this patch.
>> > >
>> > > The if (td.cbp > td.be <http://td.be>) logic in
>> > ohci_service_td() causes an
>> > > ohci_die(). My understanding of the OHCI spec 4.3.1.2
>> > > Table 4-2 allows td.cbp to be one byte more than td.be
>> > <http://td.be> to
>> > > signal the buffer has zero length. The new check in qemu
>> > > appears to have been added since qemu-4.2. This patch
>> > > includes both fixes since they are located very close
>> > > together.
>> > >
>> > > Signed-off-by: David Hubbard <dmamfmgm@gmail.com
>> > <mailto:dmamfmgm@gmail.com>>
>> >
>> > Wonder if this got lost somehow. Or is it not needed?
>> >
>> > Thanks,
>> >
>> > /mjt
>> >
>> >
>> > Friendly ping! Gerd, can you chime in with how you would like to
>> > approach this? I still need this patch to unblock my qemu workflow -
>> > custom OS development.
>> >
>> >
>> > Can I please ask for an update on this? I'm attempting to figure out if
>> > this patch has been rejected and I need to resubmit / rework it at HEAD?
>> >
>> >
>> > > diff --git a/hw/usb/hcd-ohci.c b/hw/usb/hcd-ohci.c
>> > > index d73b53f33c..a53808126f 100644
>> > > --- a/hw/usb/hcd-ohci.c
>> > > +++ b/hw/usb/hcd-ohci.c
>> > > @@ -927,6 +927,11 @@ static int ohci_service_td(OHCIState
>> *ohci,
>> > > struct ohci_ed *ed)
>> > > case OHCI_TD_DIR_SETUP:
>> > > str = "setup";
>> > > pid = USB_TOKEN_SETUP;
>> > > + if (OHCI_BM(ed->flags, ED_EN) > 0) { /* setup only
>> > allowed to ep 0 */
>> > > + trace_usb_ohci_td_bad_pid(str, ed->flags,
>> td.flags);
>> > > + ohci_die(ohci);
>> > > + return 1;
>> > > + }
>> > > break;
>>
>> I made a comment on April 18 but it is not showing on the list...
>>
>> https://lore.kernel.org/qemu-devel/593072d7-614b-4197-9c9a-12bb70c31d31@linaro.org/
>>
>> It was:
>>
>> > Please split in 2 different patches.
>>
>> Even if closely related, it simplifies the workflow to have
>> single fix in single commit; for example if one is invalid,
>> we can revert it and not the other.
>>
>
> Sure, I can submit 2 separate patches. I'm unfamiliar with how to get
> those to show up in this patch request, I assume it's not too bad if I
> submit that as a separate patch request?
>
> On Wed, May 8, 2024 at 3:45 AM Thomas Huth <thuth@redhat.com> wrote:
>
>> Your Signed-off-by line does not match the From: line ... could you please
>> fix this? (see
>>
>> https://www.qemu.org/docs/master/devel/submitting-a-patch.html#patch-emails-must-include-a-signed-off-by-line
>> , too)
>
>
> I'll submit the new patch request with my pseudonym in the From: and
> Signed-off-by: lines, per your request. Doesn't matter to me. However, this
> arises simply because I don't give gmail my real name -
> https://en.wikipedia.org/wiki/Nymwars
>
>
I've sent the new patches just now. The repro disk images mentioned in the
patch descriptions are attached to this email.
>
>> > > default:
>> > > trace_usb_ohci_td_bad_direction(dir);
>> > > @@ -936,8 +941,8 @@ static int ohci_service_td(OHCIState
>> > *ohci, struct
>> > > ohci_ed *ed)
>> > > if ((td.cbp & 0xfffff000) != (td.be <http://td.be>
>> > & 0xfffff000)) {
>> > > len = (td.be <http://td.be> & 0xfff) + 0x1001
>> -
>> > (td.cbp & 0xfff);
>> > > } else {
>> > > - if (td.cbp > td.be <http://td.be>) {
>> > > - trace_usb_ohci_iso_td_bad_cc_overrun(td.cbp,
>> > td.be <http://td.be>);
>> > > + if (td.cbp > td.be <http://td.be> + 1) {
>> > > + trace_usb_ohci_td_bad_buf(td.cbp, td.be
>> > <http://td.be>);
>> > > ohci_die(ohci);
>> > > return 1;
>> > > }
>> > > diff --git a/hw/usb/trace-events b/hw/usb/trace-events
>> > > index ed7dc210d3..b47d082fa3 100644
>> > > --- a/hw/usb/trace-events
>> > > +++ b/hw/usb/trace-events
>> > > @@ -28,6 +28,8 @@ usb_ohci_iso_td_data_overrun(int ret,
>> > ssize_t len)
>> > > "DataOverrun %d > %zu"
>> > > usb_ohci_iso_td_data_underrun(int ret) "DataUnderrun %d"
>> > > usb_ohci_iso_td_nak(int ret) "got NAK/STALL %d"
>> > > usb_ohci_iso_td_bad_response(int ret) "Bad device response
>> %d"
>> > > +usb_ohci_td_bad_buf(uint32_t cbp, uint32_t be) "Bad cbp =
>> > 0x%x > be = 0x%x"
>> > > +usb_ohci_td_bad_pid(const char *s, uint32_t edf, uint32_t
>> > tdf) "Bad
>> > > pid %s: ed.flags 0x%x td.flags 0x%x"
>> > > usb_ohci_port_attach(int index) "port #%d"
>> > > usb_ohci_port_detach(int index) "port #%d"
>> > > usb_ohci_port_wakeup(int index) "port #%d"
>> > >
>> >
>>
>>
[-- Attachment #1.2: Type: text/html, Size: 12191 bytes --]
[-- Attachment #2: testBadSetup.img.xz --]
[-- Type: application/x-xz, Size: 57324 bytes --]
[-- Attachment #3: testCbpOffBy1.img.xz --]
[-- Type: application/x-xz, Size: 57276 bytes --]
next prev parent reply other threads:[~2024-05-09 0:33 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-06 7:13 hw/usb/hcd-ohci: Fix #1510, #303: pid not IN or OUT Cord Amfmgm
2024-04-18 15:43 ` Michael Tokarev
2024-04-19 15:00 ` Cord Amfmgm
2024-04-24 20:43 ` Cord Amfmgm
2024-05-07 20:20 ` Cord Amfmgm
2024-05-08 8:44 ` Thomas Huth
2024-05-08 9:53 ` Philippe Mathieu-Daudé
2024-05-08 15:28 ` Cord Amfmgm
2024-05-09 0:32 ` Cord Amfmgm [this message]
2024-05-09 17:48 ` Peter Maydell
2024-05-09 18:16 ` Cord Amfmgm
2024-05-09 20:37 ` BALATON Zoltan
2024-05-10 7:08 ` Cord Amfmgm
2024-05-11 10:25 ` Peter Maydell
2024-05-12 16:24 ` Cord Amfmgm
-- strict thread matches above, loose matches on Subject: below --
2024-02-06 7:02 Cord Amfmgm
2024-02-06 7:05 ` Cord Amfmgm
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CACBuX0Qoz3cd7FjWGop9+qx3XU78TUxxjDkLMT8QQOZOJrmLhg@mail.gmail.com \
--to=dmamfmgm@gmail.com \
--cc=kraxel@redhat.com \
--cc=mjt@tls.msk.ru \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).