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]

Message-ID: <alpine.LRH.2.00.1407111032170.17648@lnfm1.sai.msu.ru>
Date:	Fri, 11 Jul 2014 10:39:14 +0400 (MSK)
From:	"Matwey V. Kornilov" <matwey@....msu.ru>
To:	Greg KH <gregkh@...uxfoundation.org>
cc:	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-parport <linux-parport@...ts.infradead.org>,
	Heiko Andreas Sommer <hsommer@....org>,
	matwey.kornilov@...il.com
Subject: Re: [PATCHv3 2/2] Add force_epp module option for parport_pc.


>>> Or did I read the patch incorrectly?
>>
>> Maybe I've implemented something incorrectly? I think I suggested
>> exactly inverse thing: the check is disabled only when the option is
>> touched by user:
>>
>> !force_epp && intel_bug_present(pb) <=> intel_bug_present(pb) (given
>> that force_epp is false)
>
> I don't understand, care to just resend the patches? I really don't
> remember what the patch said...

The patch is in bottom of this message. My suggestion was that people 
suffering from false positives will set the option to TRUE, and other 
won't touch it.

>>> Why not implement Alan's suggestion?
>>
>> Why not, if you are fine with it. Are you sure that PPro was turning point?
>
> If Alan says so, I believe him :)

Ok, then I believe you, I will go to reimplement it in Alan's way.


>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: [PATCH 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.

Tested-by: Heiko Andreas Sommer <hsommer@....org>
Signed-off-by: Matwey V. Kornilov <matwey@....msu.ru>
---
  drivers/parport/parport_pc.c | 9 ++++++++-
  1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/parport/parport_pc.c b/drivers/parport/parport_pc.c
index a6eaafb..fb7530d 100644
--- a/drivers/parport/parport_pc.c
+++ b/drivers/parport/parport_pc.c
@@ -105,6 +105,9 @@ static int user_specified;
         (defined(CONFIG_PARPORT_1284) && defined(CONFIG_PARPORT_PC_FIFO))
  static int verbose_probing;
  #endif
+#ifdef CONFIG_PARPORT_1284
+static int force_epp;
+#endif
  static int pci_registered_parport;
  static int pnp_registered_parport;

@@ -1764,7 +1767,7 @@ static int parport_EPP_supported(struct parport *pb)
  		return 0;  /* No way to clear timeout */

  	/* Check for Intel bug. */
-	if (intel_bug_present(pb))
+	if (!force_epp && intel_bug_present(pb))
  		return 0;

  	pb->modes |= PARPORT_MODE_EPP;
@@ -3147,6 +3150,10 @@ module_param_array(dma, charp, NULL, 0);
  MODULE_PARM_DESC(verbose_probing, "Log chit-chat during initialisation");
  module_param(verbose_probing, int, 0644);
  #endif
+#ifdef CONFIG_PARPORT_1284
+MODULE_PARM_DESC(force_epp, "Force EPP enabling when buggy hardware found by the module checks");
+module_param(force_epp, int, 0);
+#endif
  #ifdef CONFIG_PCI
  static char *init_mode;
  MODULE_PARM_DESC(init_mode,
-- 
1.8.1.4

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