linux-kernel - Re: [PATCH 01/10] floppy: cleanup: expand macro FDCS

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:   Tue, 25 Feb 2020 15:02:07 +0100
From:   Willy Tarreau <w@....eu>
To:     Denis Efremov <efremov@...ux.com>
Cc:     Jens Axboe <axboe@...nel.dk>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-block <linux-block@...r.kernel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH 01/10] floppy: cleanup: expand macro FDCS

On Tue, Feb 25, 2020 at 10:14:40AM +0300, Denis Efremov wrote:
> 
> 
> On 2/25/20 6:45 AM, Willy Tarreau wrote:
> > On Tue, Feb 25, 2020 at 02:13:42AM +0300, Denis Efremov wrote:
> >> On 2/25/20 12:53 AM, Linus Torvalds wrote:
> >>> So I'd like to see that second step that does the
> >>>
> >>>     -static int fdc;                 /* current fdc */
> >>>     +static int current_fdc;
> >>>
> >>> change.
> >>>
> >>> We already call the global 'drive' variable 'current_drive', so it
> >>> really is 'fdc' that is misnamed and ambiguous because it then has two
> >>> different cases: the global 'fdc' and then the various shadowing local
> >>> 'fdc' variables (or function arguments).
> >>>
> >>> Mind adding that too? Slightly less automatic, I agree, because then
> >>> you really do have to disambiguate between the "is this the shadowed
> >>> use of a local 'fdc'" case or the "this is the global 'fdc' use" case.
> > 
> > I definitely agree. I first wanted to be sure the patches were acceptable
> > as a principle, but disambiguating the variables is easy to do now.
> 
> Ok, I don't want to break in the middle of your changes in this case.

So I started this and discovered the nice joke you were telling me
about regarding FD_IOPORT which references fdc. Then the address
registers FD_STATUS, FD_DATA, FD_DOR, FD_DIR, FD_DCR which are
based on FD_IOPORT also depend on it.

These ones are used by fd_outb() which is arch-dependent, so if we
want to pass a third argument we have to change them all and make sure
not to break them too much.

In addition the FD_* macros defined above are used by x86, and FD_DOR is
also used by arm while all other archs hard-code all the values. ARM also
uses floppy_selects[fdc] and new_dor... I'm starting to feel the trap here!
I also feel a bit concerned that these are exported in uapi with a hard-coded
0x3f0 base address. I'm just not sure how portable all of this is in
the end :-/

Now I'm wondering, how far should we go and how much is it acceptable to
change ? I'd rather not have "#define fdc current_fdc" just so that it
builds, but on the other hand this problem clearly outlights the roots
of the issue, which lies in "fdc" being silently accessed by macros with
nobody noticing!

Willy