linux-kernel - Re: [PATCH] usb: use memdup

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: <200905061534.53521.oliver@neukum.org>
Date:	Wed, 6 May 2009 15:34:52 +0200
From:	Oliver Neukum <oliver@...kum.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	David Brownell <david-b@...bell.net>,
	Li Hong <lihong.hi@...il.com>, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] usb: use memdup_user()

Am Dienstag, 5. Mai 2009 19:22:53 schrieb Andrew Morton:
> On Tue, 5 May 2009 12:44:01 +0200 Oliver Neukum <oliver@...kum.org> wrote:

> > USB drivers are interface level yet some functions, reset and power
> > management, are on a device level. As it is unpredictable whether
> > a driver will share a device with a storage driver, all USB drivers as
> > far as these functions are concerned must be considered block device
> > drivers. That's the reason GFP_NOIO is so prevalent in USB.
>
> There must be some particular action which flips the thread of control
> from one state to the other.  eg, taking of a lock.

Basically assigning an interface to the storage or ub driver.

> > > I wonder how hard it would be to add runtime debugging checks?  If
> >
> > I'd prefer compile time checks. Ideally we'd annotate a function with an
> > attribute making the compiler barf if copy_to/from_user or an
> > inappropriate kmalloc is used. It can't be perfect due to function
> > pointers, but it would be a good start.
>
> I don't think that would have enough coverage - bugs in this area tend
> to come from calling some function which looks innocent, but which
> calls some function which calls some function which calls some function
> which uses GFP_KERNEL.
>
> And then there's stuff like "usb takes a mutex which is also taken by
> some other thread which does a GFP_KERNEL allocation while holding that
> mutex".

Yes, but to catch that you'd have to teach lockdep about those functions
whose locks are dangerous to share with respect to memory allocation.
Is there another way to do that besides labelling dangerous methods?

	Regards
		Oliver


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