Re: [PATCH 0/2] add sysfs for acpi interfaces of thinkpad hardware mute

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 08/14/2013 10:05 PM, Matthew Garrett wrote:
> On Wed, 2013-08-14 at 21:53 +0200, David Henningsson wrote:
>> On 08/14/2013 04:57 PM, Matthew Garrett wrote:
>>> On Wed, 2013-08-14 at 11:27 +0200, David Henningsson wrote:
>>>
>>>> The privacy issue is interesting, but I don't see a practical way of
>>>> implementing things that would protect us against compromised userspaces.
>>>
>>> That's pretty easy - just tie the LED control to the HDA device in-kernel.
>>>
>>
>> Well, my point was that the compromised userspace could still record
>> from other possibly connected microphones (such as USB or bluetooth
>> headsets).
> 
> Ok, true. It'd need to be at a higher level than HDA to make this
> consistent. But in theory, this is something that could be tied to the
> full set of input sources.

In theory perhaps, but in practice, I doubt it. USB audio perhaps,
because that's at least ALSA. Bluetooth uses its own stack (it's not
even ALSA), and I'm not sure how much of that stack is in the kernel.

And then we haven't considered other oddities such as FFADO, network
connected devices and what not...but perhaps we could leave those out?

>> But I guess one compromise could be to refuse userspace turn the mic
>> mute LED on, if the internal mic is unmuted.
>> Userspace would still be able to turn the mic mute LED off, to indicate
>> that recording can happen from other sources. It will be slightly more
>> complex for userspace though.
> 
> Like I said, I don't think there's any reason for this to be in
> userspace. If it's only going to represent the internal device, that's
> trivial. If it's going to represent the global state of audio devices,
> that's more complicated but doable. The only policy aspect is "What if I
> want it to track the state of the currently selected audio device",
> which just doesn't seem like a useful thing for it to do.

I say it's the *most* useful thing for it to do.

Imagine you're a non-technical user, who has never heard the words
"compromised userspace". You connect your headset where it fits (or
cordless), and then select the headset in sound settings (if it didn't
get selected for you when you plugged it in). You're on a VOIP call and
press the mic mute hotkey. Which mic did you expect to mute? The
selected one. On the mic mute hotkey button, there is also a LED. You
expect it to lit, because you muted the mic that you currently care
about, i e, the selected one.


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux