linux-kernel - Re: [PATCHv3 2/2] Add force_epp module option for parport

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:	Thu, 10 Jul 2014 11:56:15 +0400 (MSK)
From:	"Matwey V. Kornilov" <matwey@....msu.ru>
To:	Greg KH <gregkh@...uxfoundation.org>
cc:	linux-kernel@...r.kernel.org, linux-parport@...ts.infradead.org,
	hsommer@....org, matwey.kornilov@...il.com
Subject: Re: [PATCHv3 2/2] Add force_epp module option for parport_pc.

On Wed, 9 Jul 2014, Greg KH wrote:

> On Mon, Jul 07, 2014 at 11:01:51AM +0400, Matwey V. Kornilov wrote:
>>> From cf37d0cc4d51da5c0b368e1f5ab05082c041d1e1 Mon Sep 17 00:00:00 2001
>> From: "Matwey V. Kornilov" <matwey.kornilov@...il.com>
>> Date: Wed, 25 Jun 2014 01:08:45 +0400
>> Subject: [PATCHv3 2/2] Add force_epp module option for parport_pc.
>>
>> The detection of Intel EPP bug is known to produce much false positives.
>> The new option is introduced to force enable EPP in spite of the test result.

Hi,

First of all, maybe I missed something fundamental, or did something 
wrong, but I can't understand how is it going to break working systems? We 
have current behaviour B0, and introduce an option switches between B0 
(which is default value) and alternative behaviour B1. So, until you go to 
/etc/modprobe.d to override defaults or modprobe with specific option the 
current behaviour B0 is active. Am I not right here?

> module parameters are horrid, how is someone supposed to know to use
> this?

I usually do `modinfo' to list existing options. Do I understand right 
that description has to be added into Documentations also?

> Why can't we "fix" the detection logic?

Initial check had been introduced in 1999 [1], however I am failed to find 
any proves, because davej/history.git is missed. Initial committer is 
unknown. The check fixes issue with the affected hardware (A) and 
introduces new one with false-positive (F) hardware.

Now, there are no evidences of what hardware is affected (it seems to be 
quite aged), and no owners of this hardware are known. So, If I had fixed 
the detection logic (in one or another way), I would have not been able to 
check it.

What I am trying to do here (as it is described in 0/2) is to allow people 
with false-positive hardware somehow operate with it.

> You just now broke systems that were working by forcing them to now set a module option
> where previously they didn't

See above.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=630593#79

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