linux-kernel - Re: [PATCH] xhci: Cope with VIA VL805 readahead

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: <59DE2D60.1020500@linux.intel.com>
Date:   Wed, 11 Oct 2017 17:40:32 +0300
From:   Mathias Nyman <mathias.nyman@...ux.intel.com>
To:     Robin Murphy <robin.murphy@....com>, mathias.nyman@...el.com,
        gregkh@...uxfoundation.org
Cc:     linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
        David.Laight@...LAB.COM, angelsl@...4.sg
Subject: Re: [PATCH] xhci: Cope with VIA VL805 readahead

On 10.10.2017 21:09, Robin Murphy wrote:
> The VIA VL805 host controller is well-known for causing problems on
> systems with IOMMUs enabled, ranging from triggering endless streams of
> fault messages to locking itself up completely. It appears that the root
> of the problem might be an over-aggressive prefetching of TRBs, wherein
> consuming commands near the end of a queue segment causes it to read off
> the end of the segment, even across a page boundary. This blows up when
> DMA mapping ops are backed by an IOMMU, since there is no guarantee that
> addresses outside the allocated segment are accessible at all.
>
> Some trial-and-error investigation reveals that we can avoid such
> cross-page reads by not using the last few TRBs in a segment; to that
> end, factor out the implicit index of the end-of-segemnt link TRB, and
> implement a quirk to move it slightly further forward when necessary.
>
> Signed-off-by: Robin Murphy <robin.murphy@....com>
> ---
>   drivers/usb/host/xhci-mem.c  | 32 +++++++++++++++++++-------------
>   drivers/usb/host/xhci-pci.c  |  5 +++++
>   drivers/usb/host/xhci-ring.c | 10 +++++++++-
>   drivers/usb/host/xhci.c      | 10 +++++-----
>   drivers/usb/host/xhci.h      |  2 ++
>   5 files changed, 40 insertions(+), 19 deletions(-)
>

Thanks for testing all this.

If possible I'd like to try and find some other solution before chopping the Segment
size to smaller than 256.
I think that your first proposal of adding the guard page to the segment pool could be an option.

other things that could be checked:
- check if we can avoid prefetching over segment by altering the link TRB chain or ioc bits.
- check if we prefetch only over mid-ring link TRBs or also over last link TRB with cycle change.
   If only mid ring then we could try to allocate two consecutive pages for the segments.
- check if prefething over segment is related to manually setting the TR dequeue command.
   Set TR deq ponter command fushes xHC chached TRBs and might be the cause for the prefetch.
- does VIA VL805 have some odd xhci page size (xhci PAGEZISE register), does it affect anything.

But if nothing else seems to work then chopping the page size could be an option

-Mathias