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

Message-ID: <0c7f8b85-1c23-f9bc-fbfe-037d33b1b5c3@in04.sg>
Date:   Thu, 12 Oct 2017 18:35:44 +0800
From:   Hao Wei Tee <angelsl@...4.sg>
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
Subject: Re: [PATCH] xhci: Cope with VIA VL805 readahead

On 11/10/2017 02: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(-)

Seems like the invalid DMA I'm getting on xhci_reset during the xhci driver's
initialisation/probing process isn't the same one you're getting.. This patch
doesn't appear to change that at all.

Oh well.

Thanks,

-- 
Hao Wei