linux-kernel - Re: [PATCH] Input: fixed EVIOCGRAB iterative grab/release.

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: <20110211183246.GA31385@core.coreip.homeip.net>
Date:	Fri, 11 Feb 2011 10:32:46 -0800
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Terry Lambert <tlambert@...omium.org>
Cc:	Henrik Rydberg <rydberg@...omail.se>, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Input: fixed EVIOCGRAB iterative grab/release.

Hi Terry,

On Fri, Feb 11, 2011 at 09:55:53AM -0800, Terry Lambert wrote:
> Hi Henrik,
> 

First of all, please do not top-post.

> I'm in the middle of cutting down my failure case right now, so I
> should be able to provide a stand-alone test case shortly.  This is my
> top priority at work right now.
> 
> And you are correct about the race.  This is about back-to-back
> operations of a tool in a script, on a relatively slow machine with
> obstinate hardware, and a grabby Xorg driver (it's the closed source
> one, so I can't make it non-grabby).  So technically a stress test.
> 
> You noted the evdev->mutex; the idempotence of the call for the two
> pointer clears will be preserved by the mutex, so no one is going to
> get in under it while it's grabbed in the evdev_* layer, and not
> grabbed in the input_*_device layer, and get unhappy.
> 
> So at worst it's a no-op change that scratches my particularly weird itch here.

No, it is either a real problem that can happen with any hardware and
userspace or it is not, and it does not matter if userspace portion is
open or close source, it should work the same.

Before I can apply the patch I need to understand exactly:

1. How the problem is triggered (on the level "CPU1 enters particular
section of the code and then event A happens that causes CPU2 to do
something and then we are in trouble")

2. How the proposed change helps to avoid the sequence of events in 1.

> 
> PS: I supposed this use of the mutex is worthy of a comment in the
> code?  Any guidance?

If it helps people to understand the code - by all means. However you
need to realize that almost every operation within the kernel is
protected by some lock or mutex...

Thanks.

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