[alsa-devel] Splitting out controls

[David Henningsson]

On 2015-10-13 18:08, Pierre-Louis Bossart wrote:
> On 10/13/15 10:56 AM, David Henningsson wrote:
>>
>>
>> On 2015-10-13 16:55, Pierre-Louis Bossart wrote:
>>> On 10/13/15 2:07 AM, David Henningsson wrote:
>>>>
>>>>
>>>> On 2015-10-12 22:59, James Cameron wrote:
>>>>> On Mon, Oct 12, 2015 at 02:49:46PM +0100, Liam Girdwood wrote:
>>>>>> I've written up the minutes here below
>>>>>
>>>>> Thanks!
>>>>>
>>>>>> Splitting out controls: Takashi
>>>>>> ===============================
>>>>>>
>>>>>>   - Restricted access.  Consensus to restrict access to some controls
>>
>> Note: There is NOT consensus.
>>
>>>>>> due
>>>>>> to possibility of breaking HW at kernel level. i.e. prevent feeding
>>>>>> digital Mic into HP amp to prevent speaker over heating.
>>>>>
>>>>> I'd like that.  rt5631.  Avoiding at the moment by removing the
>>>>> controls.
>>>>
>>>> IIRC, the debate was over "do not expose dangerous controls to
>>>> userspace
>>>> at all" vs "expose dangerous controls controls only to root".
>>>>
>>>> I'm strongly voting for "do not expose to userspace at all".
>>>>
>>>> I personally believe that if the physical hardware can be set to state
>>>> where it's bricked, the hardware itself is buggy.
>>>>
>>>> If the hardware is buggy, this should be worked around in BIOS or
>>>> whatever firmware is present on the machine. Otherwise there is a
>>>> bug in
>>>> BIOS.
>>>>
>>>> If BIOS is buggy and cannot protect the machine from being physically
>>>> damaged, then we need to work around that in the kernel. Otherwise
>>>> there
>>>> is a bug in the kernel.
>>>>
>>>> And if the kernel is buggy, we should fix the kernel. Period. :-)
>>>
>>> There are just too many variables linked to acoustic, mechanical and
>>> thermal design that just can't be handled with a simple rule at the
>>> kernel level or even BIOS/firmware. There were quite a few people in the
>>> room who voiced their opinion that handling 'dangerous' controls was an
>>> exercise for the integrator, not something that can be handled with a
>>> one-size-fits-all fix.
>>
>> If userspace can make complex decisions to avoid damage, then so can the
>> kernel. The integrator can just write that logic into the kernel instead
>> of writing it into userspace.
>
> That seems to go against everything we've done over the last few years.

Alsactl, a tool I believe is running by default on boot of almost every 
Linux distro, sets the mixer to (pretty high) values solely based on 
their names. It does so without user interaction, and it runs as root.

Likewise, alsamixer is one of the first tools you go to when you have 
problems with your sound not working. Ubuntu, Debian, Arch and more have 
guides on their wikis of how to use it.

Hence I'd say that allowing mixer controls to destroy your hardware is 
to go against everything done over *more* than the last few years.

Also, if simply booting up a Linux distro from a USB stick (or however 
you root your device) has even the slightest chance of destroying your 
hardware, that'd be a pretty big punch against getting people to try it 
out. :-(

And if that wasn't enough, it's also an attack vector for malicious apps.

> And it's not even feasible to put kernel-level safeguards with the new
> topology tool, since the kcontrols are instantiated at run time based on
> a firmware description.

Again, not buying it. A topology tool must not create kcontrols that 
could destroy the machine.

>>> 'userspace' is also a vague definition, most
>>> audio servers will use profiles that will avoid using bad
>>> configurations. It's not clear to me that we have to protect against a
>>> user setting random values with alsamixer.
>>
>> Whether the devices are phones, laptops, or everything in between,
>> people are replacing their original software with other software. Surely
>> those people are messing around with mixer controls, and surely they
>> don't want their devices damaged.
>>
>> These people might replace the kernel as well, of course, but are less
>> likely to do so than to replace userspace; and if they do, they are less
>> likely to mess around with a particular audio driver, especially if that
>> driver has a big warning sign saying "changing this value might fry your
>> speaker" (which, IMO, would be appropriate).
>
> It's a valid case but I would argue that if you install new software you
> should use profiles that have been shared or used by others.If you want
> to protect against the limited knowledge of an individual user 'messing
> around mixer controls' then this is going too far.

We actively enable and advocate that people with limited knowledge can 
'mess around mixer controls'. That's why we have an alsamixer 
application in the first place, and teach people how to use it.

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic