linux-kernel - Re: [PATCH 00/23] Floppy driver cleanups

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: <20200331152812.GA16100@infradead.org>
Date:   Tue, 31 Mar 2020 08:28:12 -0700
From:   Christoph Hellwig <hch@...radead.org>
To:     Willy Tarreau <w@....eu>
Cc:     Christoph Hellwig <hch@...radead.org>,
        Denis Efremov <efremov@...ux.com>,
        Jens Axboe <axboe@...nel.dk>, linux-block@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        "David S. Miller" <davem@...emloft.net>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Helge Deller <deller@....de>, Ian Molton <spyro@....com>,
        Ivan Kokshaysky <ink@...assic.park.msu.ru>,
        Matt Turner <mattst88@...il.com>,
        Richard Henderson <rth@...ddle.net>,
        Russell King <linux@...linux.org.uk>,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>, x86@...nel.org
Subject: Re: [PATCH 00/23] Floppy driver cleanups

On Tue, Mar 31, 2020 at 01:01:36PM +0200, Willy Tarreau wrote:
> I'm not sure what this implies regarding this code, to be honest. It's
> very tricky and implements sort of a state machine using function pointers
> within its interrupt handler so you never know exactly what accesses what,
> and quite a part of it remains obscure to me :-/  I can accept to help, I
> can even run tests since I still have running hardware, but I'd at least
> need some guidance. And probably Denis would know better than me there.
> Also I doubt we'd get sufficient testing on less common archs. While I
> do have sparc64/parisc/alpha available, I haven't booted a recent kernel
> on any of them for a while (2.4 used to be the last ones), and I'm not
> sure it's reasonable to go into such changes without proper testing.

The basic change is that instead of using bio_data() or page_address
all pages coming from the block layer need to be properly kmap()ed.
I'll try to cook something up an will send it to Denis and you for
review and testing.  The code things about sparc64/parisc/alpha is
that they all don't have highmem, so these changes should be effective
no-ops for them.