linux-kernel - Re: Pegasos OHCI bug (was Re: PROBLEM: memory corrupting bug,

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: <20101028210753.22240.qmail@kosh.dhis.org>
Date:	Thu, 28 Oct 2010 16:07:53 -0500 (GMT+5)
From:	pacman@...h.dhis.org
To:	segher@...nel.crashing.org (Segher Boessenkool)
Cc:	linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org
Subject: Re: Pegasos OHCI bug (was Re: PROBLEM: memory corrupting bug,

Segher Boessenkool writes:
> 
> > So is it wrong to leave the host controller enabled when the OS is booted?
> 
> Yes.  Or, rather, there should be some way for the client to turn off
> all dma and interrupt activity; if the client closes the ihandles in
> "/chosen", and perhaps calls "quiesce", that should be enough.

Sounds good to me, I only wish someone had written down what "quiesce" means.

> >
> > Almost all of my devices are under that PCI node. What will I prove by
> > disabling them?
> 
> You should put it after "load", and before "go".
> 
> It should give you a working system; it's a sledgehammer workaround.

I can do it a little more gracefully than that. This works to deactivate the
problem devices manually:

  1 lbflip 80000000 8 + rl!
  1 lbflip 80001000 8 + rl!

where 80000000 and 80001000 have been obtained from
/pci@...00000/usb@...ssigned-addresses and
/pci@...00000/usb@5,1/assigned-addresses; 8 is the offset of the
HcCommandStatus register; and the 1 bit is HostControllerReset (HCR).

Now I'm just trying to find the more correct way of doing it, without
hardcoded addresses. That'll be something like this:

  search the device tree for OHCI nodes
  for each OHCI node
    get assigned-addresses
    map-in
    set HCR
    wait for acknowledgement
    map-out

which can be done any time before the quiesce call, since that marks the
point where the kernel assumes that there are no devices writing to memory.
Sound good?

-- 
Alan Curry
--
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/