linux-kernel - [BUG] parport_pc: ECP+EPP mode doesn't work

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

Date:	Sat, 7 Mar 2009 01:07:22 +0300
From:	Max Dmitrichenko <dmitrmax@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: [BUG] parport_pc: ECP+EPP mode doesn't work

Hi!

I've been facing a strange bug (at least in 2.6.24 and 2.6.26). I've
got a PC with SuperIO controller which supports (de jure non-standard
but de facto very common) mode of LPT which is called ECP+EPP, along
with the standard modes "EPP only" and "ECP only". But kernel detects
port to have only [SPP, TRISTATE] when I switch the SuperIO into this
mode in BIOS. ECP mode is not detected since CONFIG_PARPORT_PC_FIFO is
turned off, so its OK. But why it fails to detect EPP?

I've investigated parport_pc code and that's what I found. Have a look
at parport_EPP_supported() function.

1932         /* If EPP timeout bit clear then EPP available */
1933         if (!clear_epp_timeout(pb)) {
1934                 return 0;  /* No way to clear timeout */
1935         }
1936
1937         /* Check for Intel bug. */
1938         if (priv->ecr) {
1939                 unsigned char i;
1940                 for (i = 0x00; i < 0x80; i += 0x20) {
1941                         ECR_WRITE (pb, i);
1942                         if (clear_epp_timeout (pb)) {
1943                                 /* Phony EPP in ECP. */
1944                                 return 0;
1945                         }
1946                 }
1947         }

Here, if ECP mode is supported by SuperIO, the code checkes for some
bug. Semantics is that it puts ECP port into every supported mode
(Standard mode, Byte mode, FIFO mode and ECP FIFO Mode) except the EPP
mode. In every mode it tries to clear EPP timeout condition. If it
succeeds to clear EPP timeout then bug is found. I don't know anything
about this bug, but let's suppose that author of this code thought so,
because EPP timeout can't be cleared in non-EPP mode.

I've found that EPP mode is not detected because this function return
at line 1944 (i.e. code decides that this strange bug is found). But
what happens in clear_epp_timeout() function?

 250 static int clear_epp_timeout(struct parport *pb)
 251 {
 252         unsigned char r;
 253
 254         if (!(parport_pc_read_status(pb) & 0x01))
 255                 return 1;
 ....
 265 }

So, if timeout bit is not asserted (i.e. nothing to clear) then
function returns a success. From one side, we have a code which finds
success of this function to be a bug (if non-EPP mode is active), from
the other side, it is definitely normal that in non-EPP mode there is
nothing to clear so this function has no option to fail.

So does anybody know something about this strange "intel bug"? I think
if this bug exists then it should be handled in a different way,
because now it prevents the EPP mode to be detected when ECP+EPP mode
enabled.

I also appreciate if someone can test a fairy recent kernel with the
LPT port configured into ECP+EPP mode in BIOS and check whether EPP is
detected along with ECP.

--
  Max
--
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/