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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 21 Apr 2021 20:36:37 -0600
From:   Khalid Aziz <khalid@...ehiking.org>
To:     "Maciej W. Rozycki" <macro@...am.me.uk>
Cc:     Ondrej Zary <linux@...y.sk>,
        "James E.J. Bottomley" <jejb@...ux.ibm.com>,
        "Martin K. Petersen" <martin.petersen@...cle.com>,
        Christoph Hellwig <hch@....de>, linux-scsi@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/5] Bring the BusLogic host bus adapter driver up to
 Y2021

On 4/20/21 12:02 PM, Maciej W. Rozycki wrote:
> On Mon, 19 Apr 2021, Khalid Aziz wrote:
> 
>>>  Khalid: I have skimmed over these documents and I infer 24-bit addressing 
>>> can be verified with any MultiMaster adapter, including ones that do have 
>>> 32-bit addressing implemented, by using the legacy Initialize Mailbox HBA 
>>> command.  That could be used to stop Christoph's recent changes for older 
>>> adapter support removal and replace them with proper fixes for whatever 
>>> has become broken.  Is that something you'd be willing as the driver's 
>>> maintainer to look into, or shall I?
>>
>> Do you mean use OpCode 01 (INITIALIZE MAILBOX) to set a 24-bit address
>> for mailbox in place of OpCode 81? Verifying the change would be a
>> challenge. Do you have an old adapter to test it with? If you do, go
>> ahead and make the changes. I will be happy to review. I have only a
>> BT-757 adapter.
> 
>  Yes, but upon inspection it looks like our driver doesn't use that opcode 
> and relies solely on 32-bit Mode Initialize Mailbox (0x81) even with ISA 
> devices.  That makes sense as documentation indicates the firmware has 
> been designed to be unified so that the same binary microcontroller code 
> runs across all BusLogic MultiMaster devices.
> 
>  Anyway given the unified API it should be straightforward to simulate an 
> older adapter with a newer one, except for host bus protocol differences.  
> So verifying the workaround for broken BT-445S adapters continues to work 
> once modernised is not going to be a problem as it can be unconditionally 
> activated in a debug environment.  That would verify correct DMA bounce 
> buffer operation under the new scheme.
> 
>  Verifying actual ISA operations (third-party DMA, etc.) cannot be made 
> this way, but as I understand the issue there is merely with passing data 
> structures around and that may not require too much attention beyond 
> getting things syntactically correct, which I gather someone forgot to do 
> with a change made a while ago.  So that should be doable as well.

In theory this sounds reasonable, but without being able to test with a
real hardware I would be concerned about making this change.

> 
>  NB as noted before I only have a BT-958 readily wired for operation.  I 
> don't expect I have any other BusLogic hardware, but I may yet have to 
> double-check a stash of hardware I have accumulated over the years.  But 
> that is overseas, so I won't be able to get at it before we're at least 
> somewhat closer to normality.  If all else fails I could possibly buy one.
> 
>  I have respun the series now as promised.  Does your BT-757 adapter avoid 
> the issue with trailing allocation somehow?
> 

Well, my only test machine with a legacy PCI slot died some time back. I
have been working on putting together a replacement and have now been
able to get a working machine with a BT-950 adapter. I have not seen
issue with trailing allocation upto 5.12-rc8. I am going to try the top
of tree as well to make sure I do not run into this issue.

--
Khalid

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ