Re: [PATCH 6/8] ALSA: emu10k1: add support for 2x/4x word clocks in E-MU D.A.S. mode

[Oswald Buddenhagen <oswald.buddenhagen@gmx.de>]

On Wed, Jun 14, 2023 at 11:16:19AM +0200, Takashi Iwai wrote:
>On Wed, 14 Jun 2023 10:52:54 +0200,
>Oswald Buddenhagen wrote:
>> 
>> you're allowing _hypothetical_ crappy 3rd party code to dictate what
>> you can and cannot do. that's a completely unreasonable and
>> counterproductive attitude, akin to letting hostage-takers set the
>> rules.
>
>Oswald, it's no hypothetical, I have seen lots of applications that
>did crash with such mixer element changes in the past.
>
these apps have been meanwhile fixed or become obsolete, which makes it 
a hypothetical again.

>It's no dictation by 3rd party.
>
it IS. that's exactly what letting downstream limit your possibilities 
is. especially if it's BROKEN downstream.

>We simply must not crash things by an
>update (unless it's a must, something like a security fix).
>
and i'm telling you that this is an unreasonable reading of the rule.  
_every_ new feature in something already existing has the potential to 
blow up some crappy downstream code.

>> >> > Oh well, that's really not a change to be advertised for creating /
>> >> > deleting kctls from the put callback at all.
>> >> > and? it's done, and it's basically impossible to revert. so we
>> >> may
>> >> reap its full benefits just as well, as i did in that previous commit.
>> > 
>> > Well, I can revert your commit, too...
>> > 
>> sure, but my point was that there are likely many more such commits,
>> some of them not explicitly marked as such. it would be a very costly
>> and risky exercise to actually do that revert at this point.
>
>Sure, I didn't mean to do it immediately, it's no easy task.
>
great! then you can adjust this driver at that later point as well, when 
you actually want to go forward with that project. ;-)

>> > The way you're trying to implement is an anti-pattern,
>> > 
>> that's something you keep repeating in various ways, but i see no
>> evidence that there is an _actual_ problem.
>
>There were actual problems, and we had to address them.
>
what exactly where those problems?
do the circumstances under which they occurred still apply?

>The API is there and it should be usable in the ideal world, but we
>know that it breaks far more than expected.  We don't prohibit that
>API, but the actual use should be limited for very special use cases.
>
that's exactly the wrong way to go about it. the way to make sure that 
fewer apps crash is to hammer them as much as possible. if you wanted to 
make sure that they all *really* work, you'd randomly create and destroy 
fake controls from time to time.

>If it were triggered in only certain (rare and race-free) situations,
>it'd be acceptable.  But your patch allows every user to trigger it by
>the normal kctl value adjustment, which is simply no-go.
>
you are describing a completely contrieved attack scenario. it would 
have to be a multi-user system with an e-mu card where one user 
intentionally messes with the mixer to crash a broken application 
another user is using at the same time. think through the probabilities, 
motivations, alternative attack vectors, and how the whole affair would 
play out IRL for the attacker.

regards,
ossi