linux-kernel - Re: [PATCH 1/2] pata_legacy: export functionality to ide

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: <20080806194754.GC31312@gollum.tnic>
Date:	Wed, 6 Aug 2008 21:47:55 +0200
From:	Borislav Petkov <petkovbb@...glemail.com>
To:	Sergei Shtylyov <sshtylyov@...mvista.com>
Cc:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	linux-kernel@...r.kernel.org, linux-ide@...r.kernel.org
Subject: Re: [PATCH 1/2] pata_legacy: export functionality to ide

On Wed, Aug 06, 2008 at 07:57:40PM +0400, Sergei Shtylyov wrote:
> Boris Petkov wrote:
>
>>>> From: Borislav Petkov <petkovbb@...il.com>
>>>> Date: Sun, 3 Aug 2008 18:46:35 +0200
>>>> Subject: [PATCH] ide-generic: handle probing of legacy io-ports v4
>
>>>> Avoid probing the io-ports in case an IDE PCI controller is present and it uses
>>>> the legacy iobases. If we still want to enforce the probing, we do
>
>>>> ide_generic.probe_mask=0x3f
>
>>>> on the kernel command line. The iobase checking code is adapted from
>>>> drivers/ata/pata_legacy.c after converting hex pci ids into their
>>>> corresponding
>>>> macros in <linux/pci_ids.h>.
>
>>>> CC: Sergei Shtylyov <sshtylyov@...mvista.com>
>>>> Signed-off-by: Borislav Petkov <petkovbb@...il.com>
>
>>> Acked-by: Sergei Shtylyov <sshtylyov@...mvista.com>
>
>>>> diff --git a/drivers/ide/ide-generic.c b/drivers/ide/ide-generic.c
>>>> index 8fe8b5b..efce159 100644
>>>> --- a/drivers/ide/ide-generic.c
>>>> +++ b/drivers/ide/ide-generic.c
>
>>> [...]
>
>>>> @@ -100,19 +101,69 @@ static const u16 legacy_bases[] = { 0x1f0, 0x170,
>>>> 0x1e8, 0x168, 0x1e0, 0x160 };
>>>> static const int legacy_irqs[]  = { 14, 15, 11, 10, 8, 12 };
>>>> #endif
>>>> +static void ide_generic_check_pci_legacy_iobases(int *primary, int
>>>> *secondary)
>>>> +{
>>>> +       struct pci_dev *p = NULL;
>>>> +       u16 val;
>>>> +
>>>> +       for_each_pci_dev(p) {
>>>> +               int r;
>>>> +
>>>> +               for (r = 0; r < 6; r++) {
>>>> +                       if (pci_resource_start(p, r) == 0x1f0)
>>>> +                               *primary = 1;
>>>> +                       if (pci_resource_start(p, r) == 0x170)
>>>> +                               *secondary = 1;
>>>> +               }
>
>>> Would have been probably enough to test only BAR0/2, don't you think?
>
>> I assume you're referring to the legacy ioports fixup in
>> drivers/pci/probe.c:pci_setup_device().
>
>    And to the fact that the value 0x1f0 should only be ever seen in BAR0 
> and 0x170 in BAR2 even if they would have been read off the chips (some 
> chips have these values reading back even in legacy mode, and even could 
> malfunction if other values are written there), not fixed up there, and 
> certainly not in BAR1 or BAR3, so it's quite pointless to look in these 
> BARs too.

So the comment in there saying that in some cases BAR0-3 could contain junk is a
bogus? In other words, can we assume that one will always read 0x1f0 from BAR0
and 0x170 from BAR2 in compatibility mode. If so, the check is even simpler:

	if (pci_resource_start(p, 0) == 0x1f0)
		*primary = 1;
	if (pci_resource_start(p, 2) == 0x170)
		*secondary = 1;


-- 
Regards/Gruss,
    Boris.
--
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/