linux-kernel - Re: [PATCH] ide: motherboard-info based blacklist for ide-dma

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: <49707F20.4030600@ru.mvista.com>
Date:	Fri, 16 Jan 2009 15:35:44 +0300
From:	Sergei Shtylyov <sshtylyov@...mvista.com>
To:	Dmitry Gryazin <gdu@....spb.ru>
Cc:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>,
	Kirill Smelkov <kirr@....spb.ru>, linux-ide@...r.kernel.org,
	linux-kernel@...r.kernel.org, navy-patches@....spb.ru
Subject: Re: [PATCH] ide: motherboard-info based blacklist for ide-dma

Hello.

Dmitry Gryazin wrote:

>>>> True.  However it should be possible to handle it correctly by adding
>>>> the
>>>> DMA quirk to the respective host drivers (seems to be via82cxxx.c in
>>>> case of
>>>> IEI PCISA-C3/EDEN).
>>>>         
>>>   Yeah, this seems a viable approach...
>>>       
>>>> Kirill, could you please look into adding such quirk to via82cxxx
>>>> instead?
>>>>
>>>> [ It seems the best place to add it would be via_init_one() as we
>>>> could just
>>>>         
>>>   No, not really -- the issue is not at all as simple as this patch
>>> tried to present it. Looking at its "Quick Startup Reference"
>>> (http://f.ipc2u.ru/files/add/doc/496/M_PCISA-C800EV_ENG.pdf), the EPIC
>>> board has *two* normal IDE connectors in addition to the CF slot
>>> (connected to the secondary port -- and it seems possible that a hard
>>> drive can be connected to the same port as CF), so the right place
>>> seems to rather be in [mu]dma_filter() methods -- and the decision
>>> should be strictly based on the drive type indicating CF, i.e. by
>>> calling ata_id_is_cfa().
>>>       
>
> As you suggest, we could use the following criterions:
>
>     Board vendor="FIC"		&&
>     Board name="PT-2200"	&&
>     VIA-family IDE controller	&&
>     drive type=CF
>   

   Yes, but in almost exactly opposite order (well one check shoud be added)

    VT82C686 (or whatever) and
    secondary channel and
    CFA device and
    DMI ID is FIC PT2200

> It should work good enough.
>
> To test it I also tried to install external IDE CF adaptor to the secondary 
> IDE controller (both master and slave).

   You mean that this adaptor is directly connected to IDE slot with the 
cable... hm, haven't seen those.

> And it's also identified as CF drive 
> type. And we turn off DMA for it. But since external CF adaptor could be 
> wired right, turning DMA off would be incorrect in some cases.
>
> Yes, _that_ particular external IDE/CF adaptor that we bought, has the same  
> problem, so turning DMA off on it should be correct. We even decided to 
> verify ourselves that wrong soldering is the cause of problems, and wired 
> manually necessary pins, and, voila, DMA works. So the question is:
>
>     Is it right to implement the above-mentioned criterion, which would work 
>     correctly in 99 cases of 100, but will pessimistically turn DMA off in
>     rare cases (e.g. rightly wired external IDE/CF adaptor attached to
>     PCISA/C3), or is the whole problem unsolvable?
>   

   Good question. However, with the on-board CF adapter already present 
on the seconary channel it seems improbable that the user will need to 
connect another (external) CF adapter. Even if he'd need it, he'd still 
be able to use the primary port.

> We could not come up with the right criterion which selects exactly on-board 
> CF slot, so if there is no satisfactory 100% reliable solution maybe it 
> doesn't make sense to continue...
>   

   I think it still does make sense.

MBR, Sergei


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