linux-kernel - Re: [PATCH 10/53] Input: atmel_mxt_ts - Add memory access interface via sysfs

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:	Thu, 06 Jun 2013 12:17:56 +0100
From:	Nick Dyer <nick.dyer@...ev.co.uk>
To:	Mark Brown <broonie@...nel.org>
CC:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Daniel Kurtz <djkurtz@...omium.org>,
	Henrik Rydberg <rydberg@...omail.se>,
	Joonyoung Shim <jy0922.shim@...sung.com>,
	Alan.Bowens@...el.com, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org, pmeerw@...erw.net,
	bleung@...omium.org, olofj@...omium.org
Subject: Re: [PATCH 10/53] Input: atmel_mxt_ts - Add memory access interface
 via sysfs

Mark Brown wrote:
> On Thu, Jun 06, 2013 at 11:31:57AM +0100, Nick Dyer wrote:
>> Having to define every parameter in each object (there are thousands) in
>> the kernel driver would be impractically technically, since it would result
>> in a huge, and constantly updating API, which would be always out-of-date,
>> and impossible to support.
> 
>> Also, I'm afraid it would also be impractical legally, since it would
>> breach the NDA terms that Atmel require on these parameter definitions.
> 
> If that's a big problem just put the data table in a section of the
> firmware (or a separate file that gets requested as a firmware).  Or
> have the firmware be able to enumerate itself when asked.

That still would breach the NDA, I'm afraid. And there's hundreds of
existing versions of maXTouch chips already out there which don't have the
infrastructure in place to do what you describe.

>> It works very well in practice. This same abstraction is used across
>> maXTouch products on many platforms to provide tool support. I agree that
>> its use should be restricted to system programs.
> 
> It works well so long as people use the supplied binaries in the way
> that's been proscribed.  As soon as people start upgrading kernels,
> customising things out of your expected flow (because they can or
> they're on a tight deadline) things will get more fragile.  This sort of
> stuff is really common, the approaches I'm describing are fairly
> standard solutions.

If we expose every single parameter as a get/set as you suggest, we haven't
added anything that stops a binary of the wrong version doing something
stupid. We've just added a complex API to the same underlying thing, which
gains nothing.

In practice, where there is a risk of the user mucking up their
configuration, the open-source user-space tools that we have released
provide an easy way to back up and restore the configuration in use, and
the kernel driver provides a way to load a known good configuration on
probe. The same configuration formats and tools are used across maXTouch
products on many platforms.
--
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/