linux-kernel - [PATCH v3 0/3] Bring the BusLogic host bus adapter driver up to Y2021

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

Date:   Sun, 2 Jan 2022 23:23:36 +0000 (GMT)
From:   "Maciej W. Rozycki" <macro@...am.me.uk>
To:     Khalid Aziz <khalid@...ehiking.org>,
        "James E.J. Bottomley" <jejb@...ux.ibm.com>,
        "Martin K. Petersen" <martin.petersen@...cle.com>
cc:     Christoph Hellwig <hch@....de>, Nix <nix@...eri.org.uk>,
        linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: [PATCH v3 0/3] Bring the BusLogic host bus adapter driver up to
 Y2021

Hi,

 Or was it Y2022?

 Anyway, here's v3 of the series, with original patches 1/5 and 2/5 
removed as they have since gone in (thanks!).  No code or description 
change with the remaining patches, just a mechanical regeneration, except 
for Nick's Tested-by annotation for 3/3 (thanks!).  Parts of the original 
cover letter follow that are still relevant, for reference.

 So we are here owing to Christoph's recent ISA bounce buffering sweep: 
<https://lore.kernel.org/linux-scsi/20210331073001.46776-1-hch@lst.de/T/#m981284e74e93216626a0728ce1601ca18fca92e8> 
which has prompted me to verify the current version of Linux with my old 
server, which has been long equipped with venerable Linux 2.6.18 and which 
I now have available for general experimenting, and the BusLogic BT-958 
PCI SCSI host bus adapter the server has used for 20-something years now. 
This revealed an issue with the BusLogic driver.

 It has become obvious the BusLogic driver would have been non-functional, 
should I have upgraded the kernel, at least with this configuration for 
some 8 years now, and the underlying cause has been a long-known issue 
with the MultiMaster firmware I have dealt with already, back in 2003.  
To put it short the firmware cannot cope with commands that request an 
allocation length exceeding the length of actual data returned.

 I have originally observed it with a LOG SENSE command in the course of 
investigating why smartmontools bring the system to a death, and worked it 
around: <https://sourceforge.net/p/smartmontools/mailman/message/4993087/> 
by issuing the command twice, first just to obtain the allocation length 
required.  As it turns out we need a similar workaround in the kernel now.

 But in the course of investigating this issue I have discovered there is 
a second bottom to it and hence I have prepared follow-up changes to 
address problems with our handling of Vital Product Data INQUIRY pages.

 See individual change descriptions for further details.

 Any questions, comments, concerns still?  Otherwise please apply.

  Maciej