linux-kernel - Re: [PATCH/RFC] pci: dynids.use_driver

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:	Fri, 15 Aug 2008 20:55:00 +0200
From:	Jean Delvare <khali@...ux-fr.org>
To:	Jesse Barnes <jbarnes@...tuousgeek.org>
Cc:	Greg KH <greg@...ah.com>, Milton Miller <miltonm@....com>,
	Michael Ellerman <michael@...erman.id.au>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-pci@...r.kernel.org
Subject: Re: [PATCH/RFC] pci: dynids.use_driver_data considered harmful

Hi Jesse,

On Fri, 15 Aug 2008 10:46:59 -0700, Jesse Barnes wrote:
> So I think your point about dynamic IDs in general is a good one; this flag 
> really does look like an "audit was done" bit, but doesn't go as far is it 
> should.
> 
> The patch you posted to forbid dynamic binding unless use_driver_data is iset 
> is probably the safest thing to do, given that drivers that *don't* set 
> use_driver_data look like they might misbehave even with a driver_data value 
> of 0...

In fact we can do even better than that. We could accept from
user-space only driver_data values which at least one device ID entry in
the driver already uses. That should be fairly easy to implement, and
would offer a level of safety an order of magnitude above what we have
at the moment... And it works both ways: if 0 is not a valid data for
some driver, that would force the user to provide a non-zero (and
valid) data value. And it guarantees that the user can't ask for
something the driver doesn't expect, so drivers don't even need extra
checks. And no need for a use_driver_data flag either.

The only drawback is that it prevents the user from passing a "new"
data value even if it would be valid. But honestly, I don't expect that
case to happen frequently... if ever at all. So I'd say the benefits
totally outweight the drawback.

If the interested people agree with the idea, I'll look into
implementing it.

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