linux-kernel - Re: [tip:x86/urgent] x86: Remove usedac in feature-removal-schedule.txt

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

Message-Id: <20091215081341Y.fujita.tomonori@lab.ntt.co.jp>
Date:	Tue, 15 Dec 2009 08:13:53 +0900
From:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
To:	Valdis.Kletnieks@...edu
Cc:	mingo@...hat.com, hpa@...or.com, linux-kernel@...r.kernel.org,
	fujita.tomonori@....ntt.co.jp, tglx@...utronix.de,
	amwang@...hat.com, mingo@...e.hu, linux-tip-commits@...r.kernel.org
Subject: Re: [tip:x86/urgent] x86: Remove usedac in
 feature-removal-schedule.txt

On Mon, 14 Dec 2009 09:57:55 -0500
Valdis.Kletnieks@...edu wrote:

> On Mon, 14 Dec 2009 07:58:01 GMT, tip-bot for FUJITA Tomonori said:
> > Commit-ID:  06f8bda8324fa8bf39eed81d8b3df08063a37696
> 
> > x86: Remove usedac in feature-removal-schedule.txt
> 
> > The usedac option enables us to stop via_no_dac() setting
> > forbid_dac to 1. That is, someone who uses VIA bridges can use
> > DAC with this option even if some of VIA bridges seem to be
> > broken about DAC.
> 
> Does there exist real hardware where this makes sense?  If the chipset
> detects as "broken-DAC", is it in fact safe to use?

Not safe. Probably, you would see data corruption.

arch/x86/kernel/pci-dma.c says:

/* Many VIA bridges seem to corrupt data for DAC. Disable it here */


Seems that some of VIA bridges were fine. So this option made sense
with some hardware. I'm not sure if there are still users of this
option now.


>  Or is it similar to
> the 'force-enable HPET' code for some older boxes, where the HPET was in
> fact there but simply not advertised, so going ahead and using it was
> in fact perfectly safe? Allowing the use of "working but not advertised"
> is probably a good thing, allowing the use of known-broken probably isn't.
> 
> If it's just unadvertised, I wonder if if there's a way to write a quirk
> for VIA systems that will detect the situation and enable the support?

I guess that we could however it doesn't worth adding tricks for old
hardware.
--
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/