OSS driver removal, 2nd round

OSS driver removal, 2nd round

[Adrian Bunk]

Now that I've sent the first round of actually removing the code for OSS 
drivers where ALSA drivers without regressions exist for the same 
hardware, it's time for a second round amongst the remaining drivers.


Removing OSS drivers where ALSA drivers for the same hardware exists has 
two reasons:

1. remove obsolete and mostly unmaintained code
2. get bugs in the ALSA drivers reported that weren't previously
   reported due to the possible workaround of using the OSS drivers


The list below divides the OSS drivers into the following three
categories:
1. ALSA drivers for the same hardware
2. ALSA drivers for the same hardware with known problems
3. no ALSA drivers for the same hardware


My proposed timeline is:
- 2.6.18: let the drivers under 1. in the list below depend on
          OSS_OBSOLETE_DRIVER
- 2.6.20: remove the options depending on OSS_OBSOLETE_DRIVER
- 2.6.22: remove the code for the drivers that were depending on
          OSS_OBSOLETE_DRIVER from the kernel tree


To make a long story short:

If you are using an OSS driver because the ALSA driver doesn't work 
equally well on your hardware listed under 1. below, send me an email 
with a bug number in the ALSA bug tracking system now.


A small FAQ:

Q: But OSS is kewl and ALSA sucks!
A: The decision for the OSS->ALSA move was four years ago.
   If ALSA sucks, please help to improve ALSA.

Q: What about the OSS emulation in ALSA?
A: The OSS emulation in ALSA is not affected by my patches
   (and it's not in any way scheduled for removal).


Please review the following list:


1. ALSA drivers for the same hardware

SOUND_ACI_MIXER and RADIO_MIROPCM20
SOUND_AD1889
SOUND_ADLIB
SOUND_FUSION
SOUND_NM256
SOUND_OPL3SA2

2. ALSA drivers for the same hardware with known problems

DMASOUND_PMAC
- Olaf Hering regarding regressions in SND_POWERMAC:
  Some tumbler models work only after one plug/unplug cycle of
  the headphone. early powerbooks report/handle the mute settings
  incorrectly. there are likely more bugs.

SOUND_AD1816
- ALSA #1301 (Kernel OSS emulation stops working after a few seconds
              when used with VoIP softphones)

SOUND_CS4232
- ALSA #1520 (Soundchip was not detected on HP Omnibook 5700 CTX)

SOUND_EMU10K1
- ALSA #1735 (OSS emulation 4-channel mode rear channels not working)
- ALSA #1782 (really poor sound with my SB Live 1024 and ALSA)

SOUND_ES1371
- ALSA #1774 (missing joystick connector support for PCI Ensoniq ES1371)

SOUND_ICH
- ALSA #1764 (Recording signal quality is inacceptable (using OSS API))
- Alan Cox:
  ALSA driver lacks "support for AC97 wired touchscreens and the like"

SOUND_SSCAPE
- ALSA #2234 (driver does not find Soundscape Elite)

SOUND_TRIDENT
- ALSA #1293 (device supported by OSS but not by ALSA)
- maintainer of the OSS driver wants his driver to stay

SOUND_VIA82CXXX
- ALSA #1906 (1-second overruns reported by arecord,
              complete system hang with jackd -d alsa)


3. no ALSA drivers for the same hardware

DMASOUND_ATARI
DMASOUND_PAULA
DMASOUND_Q40
SOUND_AEDSP16
SOUND_AU1550_AC97
SOUND_BCM_CS4297A
SOUND_HAL2
SOUND_IT8172
SOUND_KAHLUA
SOUND_MSNDCLAS
SOUND_MSNDPIN
SOUND_MSS (also due to SOUND_PSS, SOUND_TRIX and perhaps SOUND_AEDSP16)
SOUND_PAS
SOUND_PSS
SOUND_SB (also due to SOUND_KAHLUA, SOUND_PAS and perhaps SOUND_AEDSP16)
SOUND_SH_DAC_AUDIO
SOUND_TRIX
SOUND_VIDC
SOUND_VRC5477
SOUND_VWSND
SOUND_WAVEARTIST


cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: OSS driver removal, 2nd round

[Ralf Baechle]

On Thu, Jun 29, 2006 at 09:21:28PM +0200, Adrian Bunk wrote:

> SOUND_IT8172

Both board based on the ITE 8172 chipset are on my death list already; I
will probably remove it after 2.6.18 is out unless against all expectation
I receive patches.

  Ralf

Re: [Alsa-devel] OSS driver removal, 2nd round

[James Courtier-Dutton]

Adrian Bunk wrote:
> Now that I've sent the first round of actually removing the code for OSS 
> drivers where ALSA drivers without regressions exist for the same 
> hardware, it's time for a second round amongst the remaining drivers.
>
>
> SOUND_EMU10K1
> - ALSA #1735 (OSS emulation 4-channel mode rear channels not working)
> - ALSA #1782 (really poor sound with my SB Live 1024 and ALSA)
>   

As the MAINTAINER of EMU10K1, I am happy for EMU10K1 driver to be 
removed from the kernel.

ALSA #1735 is now closed. All the apps the user was trying also support 
ALSA natively now, so OSS is not needed.
ALSA #1782 requires more information from the user. I am expecting this 
to be a configuration problem, and not a driver problem.

Re: [Alsa-devel] OSS driver removal, 2nd round

[Olivier Galibert]

On Fri, Jun 30, 2006 at 05:13:02PM +0100, James Courtier-Dutton wrote:
> Adrian Bunk wrote:
> >- ALSA #1735 (OSS emulation 4-channel mode rear channels not working)
> 
> As the MAINTAINER of EMU10K1, I am happy for EMU10K1 driver to be 
> removed from the kernel.
> 
> ALSA #1735 is now closed. All the apps the user was trying also support 
> ALSA natively now, so OSS is not needed.

Are you joking ?

  OG.

Re: [Alsa-devel] OSS driver removal, 2nd round

[Lee Revell]

On Fri, 2006-06-30 at 18:31 +0200, Olivier Galibert wrote:
> On Fri, Jun 30, 2006 at 05:13:02PM +0100, James Courtier-Dutton wrote:
> > Adrian Bunk wrote:
> > >- ALSA #1735 (OSS emulation 4-channel mode rear channels not working)
> > 
> > As the MAINTAINER of EMU10K1, I am happy for EMU10K1 driver to be 
> > removed from the kernel.
> > 
> > ALSA #1735 is now closed. All the apps the user was trying also support 
> > ALSA natively now, so OSS is not needed.
> 
> Are you joking ?
> 

Even if you reject this argument, the bug is in ALSA's in-kernel OSS
emulation, not the emu10k1 driver.

As sound hardware gets dumber and cheaper, kernel OSS emulation will
become increasingly useless.  The cheap onboard devices (and even mid
range stuff like the SBLive! 24 bit) require sample rate conversion,
mixing, and even volume control to be handled in software.  ALSA's
in-kernel OSS emulation does not have these features and never will.

(I wish the authors of Skype, Flash, TeamSpeak, Enemy Territory, and
other proprietary OSS-only apps would understand this ;-)

Lee

Re: [Alsa-devel] OSS driver removal, 2nd round

[Arjan van de Ven]

On Fri, 2006-06-30 at 17:29 -0400, Lee Revell wrote:
> On Fri, 2006-06-30 at 18:31 +0200, Olivier Galibert wrote:
> > On Fri, Jun 30, 2006 at 05:13:02PM +0100, James Courtier-Dutton wrote:
> > > Adrian Bunk wrote:
> > > >- ALSA #1735 (OSS emulation 4-channel mode rear channels not working)
> > > 
> > > As the MAINTAINER of EMU10K1, I am happy for EMU10K1 driver to be 
> > > removed from the kernel.
> > > 
> > > ALSA #1735 is now closed. All the apps the user was trying also support 
> > > ALSA natively now, so OSS is not needed.
> > 
> > Are you joking ?
> > 
> 
> Even if you reject this argument, the bug is in ALSA's in-kernel OSS
> emulation, not the emu10k1 driver.
> 
> As sound hardware gets dumber and cheaper, kernel OSS emulation will
> become increasingly useless.  The cheap onboard devices (and even mid
> range stuff like the SBLive! 24 bit) require sample rate conversion,
> mixing, and even volume control to be handled in software.  ALSA's
> in-kernel OSS emulation does not have these features and never will.
> 
> (I wish the authors of Skype, Flash, TeamSpeak, Enemy Territory, and
> other proprietary OSS-only apps would understand this ;-)


maybe it's time to start printing a warning to users of OSS api (rate
limited etc etc)

Re: [Alsa-devel] OSS driver removal, 2nd round

[Lee Revell]

On Fri, 2006-06-30 at 23:34 +0200, Arjan van de Ven wrote:
> On Fri, 2006-06-30 at 17:29 -0400, Lee Revell wrote:
> > As sound hardware gets dumber and cheaper, kernel OSS emulation will
> > become increasingly useless.  The cheap onboard devices (and even mid
> > range stuff like the SBLive! 24 bit) require sample rate conversion,
> > mixing, and even volume control to be handled in software.  ALSA's
> > in-kernel OSS emulation does not have these features and never will.
> > 
> > (I wish the authors of Skype, Flash, TeamSpeak, Enemy Territory, and
> > other proprietary OSS-only apps would understand this ;-)
> 
> 
> maybe it's time to start printing a warning to users of OSS api (rate
> limited etc etc)

It might help, but I'm not so sure.  The users have been complaining for
years (the most common complaint by far on #alsa is that OSS apps block
the soundcard) but these vendors don't seem to listen.  I doubt that
complaints in the kernel log will have an effect if they won't listen to
their users.

I've heard that one reason they won't port to ALSA is that they think
the in-kernel OSS emulation will be "fixed" someday.  Maybe we need to
make it clearer that this won't happen?

Lee

Re: [Alsa-devel] OSS driver removal, 2nd round

[Lee Revell]

On Sat, 2006-07-01 at 00:42 +0300, İsmail Dönmez wrote:
> Cumartesi 1 Temmuz 2006 00:29 tarihinde şunları yazmıştınız:
> > (I wish the authors of Skype, Flash, TeamSpeak, Enemy Territory, and
> > other proprietary OSS-only apps would understand this ;-)
> 
> New skype beta supports Alsa, doesn't work ATM but its a great step in that 
> direction and Flash9 for Linux will use Alsa.

Really?  Got a link?  Last I heard about Flash was that their lawyers
won't let them link to LGPL libraries which would rule out ALSA support.

Lee

Re: [Alsa-devel] OSS driver removal, 2nd round

[Olivier Galibert]

On Fri, Jun 30, 2006 at 05:29:26PM -0400, Lee Revell wrote:
> Even if you reject this argument, the bug is in ALSA's in-kernel OSS
> emulation, not the emu10k1 driver.

That's irrelevant.  You can't remove the oss emu10k1 driver in favor
of alsa's until alsa provides an equivalent interface.  That's a basic
compatibility requirement.


> ALSA's in-kernel OSS emulation does not have these features and
> never will.

"Never" is terribly long.

  OG.

Re: [Alsa-devel] OSS driver removal, 2nd round

[James Courtier-Dutton]

Olivier Galibert wrote:
> On Fri, Jun 30, 2006 at 05:29:26PM -0400, Lee Revell wrote:
>> Even if you reject this argument, the bug is in ALSA's in-kernel OSS
>> emulation, not the emu10k1 driver.
> 
> That's irrelevant.  You can't remove the oss emu10k1 driver in favor
> of alsa's until alsa provides an equivalent interface.  That's a basic
> compatibility requirement.
> 
> 
>> ALSA's in-kernel OSS emulation does not have these features and
>> never will.
> 
> "Never" is terribly long.
> 
>   OG.

"Never" probably only means terribly long. :-)

If one takes the ALSA todo list, that is massive (it is so long in fact,
that we have not had time to write it all down!), sort it by priority,
then divide by the amount of ALSA developers time available, for this
particular feature, the time to implementation is getting very close to
"Never".

James

Re: [Alsa-devel] OSS driver removal, 2nd round

[Jan Engelhardt]

>> 
>> As sound hardware gets dumber and cheaper, kernel OSS emulation will
>> become increasingly useless.  The cheap onboard devices (and even mid
>> range stuff like the SBLive! 24 bit) require sample rate conversion,
>> mixing, and even volume control to be handled in software.  ALSA's
>> in-kernel OSS emulation does not have these features and never will.
>> 

Brilliant. While in the graphics sector, cards and drivers always become fatter
and potentially less source-available than now, sound cards in contrast always
become thinner and more useless (while there is an open driver).
I cannot really use my onboard snd-intel8x0 because it lacks volume control on
Master/PCM (= blows every headphone away), etc.
00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS] AC'97
Sound Controller (rev a0)

>> (I wish the authors of Skype, Flash, TeamSpeak, Enemy Territory, and
>> other proprietary OSS-only apps would understand this ;-)
>
>maybe it's time to start printing a warning to users of OSS api (rate
>limited etc etc)

Not rate limited, so that it fulls up nicely, and admins see it sooner. If 
it just makes one message per hour or so, it may eventually be handled by 
the logrotate turnaround. Be faster than logrotate :)


Jan Engelhardt
-- 

Re: [Alsa-devel] OSS driver removal, 2nd round

[Jaroslav Kysela]

On Sat, 1 Jul 2006, Olivier Galibert wrote:

> On Fri, Jun 30, 2006 at 05:29:26PM -0400, Lee Revell wrote:
> > Even if you reject this argument, the bug is in ALSA's in-kernel OSS
> > emulation, not the emu10k1 driver.
> 
> That's irrelevant.  You can't remove the oss emu10k1 driver in favor
> of alsa's until alsa provides an equivalent interface.  That's a basic
> compatibility requirement.

Sorry, but the OSS interface is not an issue for the emu10k1 driver. It 
already supports multi-open, because emu10k1/emu10k2 chip supports more 
voices in hardware. Lee was speaking about cheap versions of Sound Blaster 
cards and they are not supported with the OSS emu10k1 linux driver, too.

> > ALSA's in-kernel OSS emulation does not have these features and
> > never will.
> 
> "Never" is terribly long.

The questions is which feature is missing from the ALSA emu10k1 driver. 
Personally, I don't know about any, except some extra features like 
rear/center/lfe channel binding, but the old OSS app binaries does not 
know about them, so it's no worth to care.

In my opinion, the OSS emu10k1 driver is ready to be removed unless 
someone notify us about any missing feature.

					Thanks,
						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs

Re: [Alsa-devel] OSS driver removal, 2nd round

[Lee Revell]

On Sat, 2006-07-01 at 08:43 +0100, James Courtier-Dutton wrote:
> Olivier Galibert wrote:
> > On Fri, Jun 30, 2006 at 05:29:26PM -0400, Lee Revell wrote:
> >> Even if you reject this argument, the bug is in ALSA's in-kernel OSS
> >> emulation, not the emu10k1 driver.
> > 
> > That's irrelevant.  You can't remove the oss emu10k1 driver in favor
> > of alsa's until alsa provides an equivalent interface.  That's a basic
> > compatibility requirement.
> > 
> > 
> >> ALSA's in-kernel OSS emulation does not have these features and
> >> never will.
> > 
> > "Never" is terribly long.
> > 
> >   OG.
> 
> "Never" probably only means terribly long. :-)
> 
> If one takes the ALSA todo list, that is massive (it is so long in fact,
> that we have not had time to write it all down!), sort it by priority,
> then divide by the amount of ALSA developers time available, for this
> particular feature, the time to implementation is getting very close to
> "Never".

The reason I say "never" is because it would either require moving
alsa-lib into the kernel (long ago rejected), or devising some system to
redirect operations on /dev/dsp back into userspace to alsa-lib.  It
seems insane for the audio path to be
userspace->kernel->userspace->kernel and I'm pretty sure this idea was
also rejected a while back.

Lee

Re: [Alsa-devel] OSS driver removal, 2nd round

[Lee Revell]

On Sat, 2006-07-01 at 10:54 +0200, Jan Engelhardt wrote:
> I cannot really use my onboard snd-intel8x0 because it lacks volume
> control on Master/PCM (= blows every headphone away), etc.
> 00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS]
> AC'97 Sound Controller (rev a0)
> 

ALSA should provide a master volume, it's only the kernel OSS emulation
that cannot control the volume on such devices.  If ALSA does not give
you volume controls, please file a bug report.

Lee

Re: [Alsa-devel] OSS driver removal, 2nd round

[Adrian Bunk]

On Fri, Jun 30, 2006 at 06:31:14PM +0200, Olivier Galibert wrote:
> On Fri, Jun 30, 2006 at 05:13:02PM +0100, James Courtier-Dutton wrote:
> > Adrian Bunk wrote:
> > >- ALSA #1735 (OSS emulation 4-channel mode rear channels not working)
> > 
> > As the MAINTAINER of EMU10K1, I am happy for EMU10K1 driver to be 
> > removed from the kernel.
> > 
> > ALSA #1735 is now closed. All the apps the user was trying also support 
> > ALSA natively now, so OSS is not needed.
> 
> Are you joking ?

Besides what was already mentioned in this thread, let me add some 
points:
- most Linux applications already support ALSA
- kernel 2.6.0 with ALSA as default sound system was released in 2003
- the ALSA developers provide an in-kernel OSS emulation
- the ALSA developers provide an alternative user space OSS emulation
- there are many new soundcards without any OSS driver at all [1]

Compatibility is important, and it's nearly always working
(e.g. "aoss audacity" works for me perfectly).

There are only few exotic cornercases like ALSA #1735 where a subset of 
the OSS functionality is not working in the OSS emulation - and I doubt 
it would be worth putting much effort into fixing such cornercases.

>   OG.

cu
Adrian

[1] we are talking about the in-kernel OSS drivers, not the
    commercial OSS

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [Alsa-devel] OSS driver removal, 2nd round

[Jan Engelhardt]

>> I cannot really use my onboard snd-intel8x0 because it lacks volume
>> control on Master/PCM (= blows every headphone away), etc.
>> 00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS]
>> AC'97 Sound Controller (rev a0)
>
>ALSA should provide a master volume, it's only the kernel OSS emulation
>that cannot control the volume on such devices.  If ALSA does not give
>you volume controls, please file a bug report.
>
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2250


Jan Engelhardt
-- 

Re: OSS driver removal, 2nd round

[Adrian Bunk]

On Thu, Jun 29, 2006 at 09:21:28PM +0200, Adrian Bunk wrote:

> Now that I've sent the first round of actually removing the code for OSS 
> drivers where ALSA drivers without regressions exist for the same 
> hardware, it's time for a second round amongst the remaining drivers.
> 
> 
> Removing OSS drivers where ALSA drivers for the same hardware exists has 
> two reasons:
> 
> 1. remove obsolete and mostly unmaintained code
> 2. get bugs in the ALSA drivers reported that weren't previously
>    reported due to the possible workaround of using the OSS drivers
> 
> 
> The list below divides the OSS drivers into the following three
> categories:
> 1. ALSA drivers for the same hardware
> 2. ALSA drivers for the same hardware with known problems
> 3. no ALSA drivers for the same hardware
> 
> 
> My proposed timeline is:
> - 2.6.18: let the drivers under 1. in the list below depend on
>           OSS_OBSOLETE_DRIVER
> - 2.6.20: remove the options depending on OSS_OBSOLETE_DRIVER
> - 2.6.22: remove the code for the drivers that were depending on
>           OSS_OBSOLETE_DRIVER from the kernel tree
>...
> 2. ALSA drivers for the same hardware with known problems
> 
> DMASOUND_PMAC
> - Olaf Hering regarding regressions in SND_POWERMAC:
>   Some tumbler models work only after one plug/unplug cycle of
>   the headphone. early powerbooks report/handle the mute settings
>   incorrectly. there are likely more bugs.
>...

Could anyone tell me whether there are still regressions in ALSA 
compared to DMASOUND_PMAC, and if yes give me bug numbers in the 
ALSA BTS so that I can track them?

TIA
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [Alsa-devel] OSS driver removal, 2nd round

[James Courtier-Dutton]

James Courtier-Dutton wrote:
> "Never" probably only means terribly long. :-)
> 

There is in fact one implementation method that we would like to
implement, but currently we don't know how, so some input from people
from this list might be helpful.

There is an ALSA tool called aoss.
What this does is hook any calls the application does to
fopen/fwrite/fread/fclose/open/close/read/write/ioctl etc. and detects
any calls to open /dev/dsp and /dev/mixer and diverts them to use
alsa-lib. This therefore manages to divert the applications use of
/dev/dsp before it even reaches the kernel. This therefore gives the
application full use of all the alsa-lib features. So, for example,
4-channel output would work in this mode. But, and this is the bit we
need help with, if the application uses dlopen to dynamically open a
plugin, the plugin's calls to open/close/read/write etc. are not hooked,
so the application fails.

Is there any way to also hook the IO calls of dlopened plugins?

James

Re: [Alsa-devel] OSS driver removal, 2nd round

[Jan Engelhardt]

>
>There is an ALSA tool called aoss.
>What this does is hook any calls the application does to
>fopen/fwrite/fread/fclose/open/close/read/write/ioctl etc. and detects
>any calls to open /dev/dsp and /dev/mixer and diverts them to use
>alsa-lib. This therefore manages to divert the applications use of
>/dev/dsp before it even reaches the kernel. This therefore gives the
>application full use of all the alsa-lib features. So, for example,
>4-channel output would work in this mode. But, and this is the bit we
>need help with, if the application uses dlopen to dynamically open a
>plugin, the plugin's calls to open/close/read/write etc. are not hooked,
>so the application fails.
>
>Is there any way to also hook the IO calls of dlopened plugins?
>
Well you could patch the affected plugin's .dynstr table so that it should at
best try to call a function that has not yet been defined somewhere else (like
open); IOW, you change the .dynstr entry from 'open' to say 'my_open', and
regularly include libmy.so through e.g. LD_PRELOAD.

Of course the MD5 won't match afterwards, but I think the plugin should execute
as usual afterwards, since .dynstr is something no app should rely on.


Jan Engelhardt
-- 

Re: [Alsa-devel] OSS driver removal, 2nd round

[Lee Revell]

On Sun, 2006-07-02 at 11:58 +0200, Jan Engelhardt wrote:
> >
> >There is an ALSA tool called aoss.
> >What this does is hook any calls the application does to
> >fopen/fwrite/fread/fclose/open/close/read/write/ioctl etc. and detects
> >any calls to open /dev/dsp and /dev/mixer and diverts them to use
> >alsa-lib. This therefore manages to divert the applications use of
> >/dev/dsp before it even reaches the kernel. This therefore gives the
> >application full use of all the alsa-lib features. So, for example,
> >4-channel output would work in this mode. But, and this is the bit we
> >need help with, if the application uses dlopen to dynamically open a
> >plugin, the plugin's calls to open/close/read/write etc. are not hooked,
> >so the application fails.
> >
> >Is there any way to also hook the IO calls of dlopened plugins?
> >
> Well you could patch the affected plugin's .dynstr table so that it should at
> best try to call a function that has not yet been defined somewhere else (like
> open); IOW, you change the .dynstr entry from 'open' to say 'my_open', and
> regularly include libmy.so through e.g. LD_PRELOAD.
> 
> Of course the MD5 won't match afterwards, but I think the plugin should execute
> as usual afterwards, since .dynstr is something no app should rely on.

Is this likely to work with an app like Skype that takes extensive steps
to thwart reverse engineers?

(Of course a Skype beta with ALSA support was just released, so it's
much less important now)

Lee

Re: [Alsa-devel] OSS driver removal, 2nd round

[Jan Engelhardt]

>> Well you could patch the affected plugin's .dynstr table so that it should at
>> best try to call a function that has not yet been defined somewhere else (like
>> open); IOW, you change the .dynstr entry from 'open' to say 'my_open', and
>> regularly include libmy.so through e.g. LD_PRELOAD.
>> 
>> Of course the MD5 won't match afterwards, but I think the plugin should execute
>> as usual afterwards, since .dynstr is something no app should rely on.
>
>Is this likely to work with an app like Skype that takes extensive steps
>to thwart reverse engineers?

We do not reverse engineer the .text section, but change the .dynstr 
section that is specific to the ELF format. I doubt any app out there md5s 
itself.

>(Of course a Skype beta with ALSA support was just released, so it's
>much less important now)

A nice challenge anyhow!


Jan Engelhardt
-- 

Re: [Alsa-devel] OSS driver removal, 2nd round

[Lee Revell]

On Sun, 2006-07-02 at 23:08 +0200, Jan Engelhardt wrote:
> >> Well you could patch the affected plugin's .dynstr table so that it should at
> >> best try to call a function that has not yet been defined somewhere else (like
> >> open); IOW, you change the .dynstr entry from 'open' to say 'my_open', and
> >> regularly include libmy.so through e.g. LD_PRELOAD.
> >> 
> >> Of course the MD5 won't match afterwards, but I think the plugin should execute
> >> as usual afterwards, since .dynstr is something no app should rely on.
> >
> >Is this likely to work with an app like Skype that takes extensive steps
> >to thwart reverse engineers?
> 
> We do not reverse engineer the .text section, but change the .dynstr 
> section that is specific to the ELF format. I doubt any app out there md5s 
> itself.
> 

It's possible.  They certainly try very hard to thwart reverse
engineers.

http://www.secdev.org/conf/skype_BHEU06.handout.pdf

Lee

Re: [Alsa-devel] OSS driver removal, 2nd round

[Jan Engelhardt]

>> 
>> We do not reverse engineer the .text section, but change the .dynstr 
>> section that is specific to the ELF format. I doubt any app out there md5s 
>> itself.
>
>It's possible.  They certainly try very hard to thwart reverse
>engineers.
>
>http://www.secdev.org/conf/skype_BHEU06.handout.pdf
>

Here is your POC for the manipulation of dynstr (and therefore, interception of
library calls without interfering with redefining/overriden libc names like
memory debuggers and AOSS do).

skype-1.2.0.18.tar.bz2

.dynsym table (0x2f80), as printed per "HT"
0130 global   func     00000000 0000007c *undefined  writ
05b9 global   func     00000000 0000007c *undefined  open
074d global   func     00000000 0000007c *undefined  read

.dynsym table (absaddr 0x2f80):
ofs     absaddr stringptr
+0x0130 0x4280  0xe0c0
+0x05b9 0x8b10  0xddbc
+0x074d 0xa450  0xdff0

.dynstr table (absaddr 0xa750):
ofs     absaddr name
+0xe0c0 0x18810 write
+0xddbc 0x1850c open  (note it is part of "fdopen")
+0xdff0 0x18740 read

Change to w2ite, o2en, r2en. Implement w2ite(), o2en(), r2()en and fdo2en() in
an extra library. Load that via LD_PRELOAD.

---extra.c---
#include <sys/stat.h>
#include <sys/types.h>
#include <fcntl.h>
#include <stdio.h>
#include <unistd.h>

int o2en(const char *path, int flags, mode_t mode) {
    int ret = open(path, flags, mode);
    printf("open(\"%s\", %x, %04o) = %d\n", path, flags, (int)mode, ret);
    return ret;
}

FILE *fdo2en(int fd, const char *mode) {
    FILE *ret = fdopen(fd, mode);
    printf("fdopen(%d, \"%s\") = %#p\n", fd, mode, ret);
    return ret;
}

ssize_t r2ad(int fd, void *buf, size_t count) {
    ssize_t ret = read(fd, buf, count);
    printf("read(%d, %#p, %zu) = %zd\n", fd, buf, count, ret);
    return ret;
}

ssize_t w2ite(int fd, const void *buf, size_t count) {
    ssize_t ret = write(fd, buf, count);
    printf("write(%d, %#p, %zu) = %zd\n", fd, buf, count, ret);
    return ret;
}

---eof---
11:21 linux01:~ > cc extra.c -Wall -o extra.so -shared
11:21 linux01:~ > export LD_PRELOAD=$PWD/extra.so
write(4, 0xbfffe82b, 1) = 1
write(4, 0x8a211d0, 26) = 26
read(4, 0x8a27620, 2048) = 4
write(4, 0x8a211d0, 7) = 7
read(4, 0x8a31750, 2048) = 260
read(4, 0x8a31f60, 2048) = -1
read(4, 0x8a31f60, 2048) = 82
read(4, 0x8a32770, 2048) = -1
read(4, 0x8a32770, 2048) = 256
read(4, 0x8a31f60, 2048) = -1
open("/home/jengelh/.Skype/shared.lck", 8041, 0777) = 8
open("/home/jengelh/.Skype/shared.xml", 8000, 0777) = 9
read(9, 0x8a3c900, 168) = 168
open("/dev/urandom", 0, 0004) = 8
read(8, 0xbfffe760, 8) = 8
open("/dev/urandom", 0, 0004) = 8
read(8, 0xbfffe760, 8) = 8
open("/dev/urandom", 0, 1051125610) = 8
read(8, 0xbfffe7a0, 8) = 8
open("/dev/urandom", 0, 1051131340) = 8
read(8, 0xbfffe7a0, 8) = 8


W.W.W.W.W.


Jan Engelhardt
-- 

Re: OSS driver removal, 2nd round

[Benjamin Herrenschmidt]

> DMASOUND_PMAC
> - Olaf Hering regarding regressions in SND_POWERMAC:
>   Some tumbler models work only after one plug/unplug cycle of
>   the headphone. early powerbooks report/handle the mute settings
>   incorrectly. there are likely more bugs.

dmasound_pmac is crippled with bugs too... We should look at reported
bug reports on snd-powermac (and snd-aoa which replaces the later for
recent machines) and kill dmasound-pmac. I'm ok with that. snd-aoa is
the only one to be properly maintained anyway, we'll add support for
older machines to it over time and hopefully, it's a much saner codebase
in the first place so handling weird machines regressions will be
easier.

Ben.

Re: OSS driver removal, 2nd round

[Adrian Bunk]

On Mon, Jul 03, 2006 at 09:52:59PM +1000, Benjamin Herrenschmidt wrote:
> 
> > DMASOUND_PMAC
> > - Olaf Hering regarding regressions in SND_POWERMAC:
> >   Some tumbler models work only after one plug/unplug cycle of
> >   the headphone. early powerbooks report/handle the mute settings
> >   incorrectly. there are likely more bugs.
> 
> dmasound_pmac is crippled with bugs too... We should look at reported
> bug reports on snd-powermac (and snd-aoa which replaces the later for
> recent machines) and kill dmasound-pmac. I'm ok with that. snd-aoa is
> the only one to be properly maintained anyway, we'll add support for
> older machines to it over time and hopefully, it's a much saner codebase
> in the first place so handling weird machines regressions will be
> easier.

Thanks for this information.

I'll include DMASOUND_PMAC in the list of OSS drivers that might be 
removed in this round (if people report regressions in the ALSA drivers, 
this can still be undone (if someone observes such a regression, he 
should send me the bug number in the ALSA BTS (this is also what 
will be written in the help text of the OSS_OBSOLETE_DRIVER option))).

> Ben.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: OSS driver removal, 2nd round

[Bill Davidsen]

İsmail Dönmez wrote:
> Cumartesi 1 Temmuz 2006 00:56 tarihinde, Lee Revell şunları yazmıştı: 
>> On Sat, 2006-07-01 at 00:42 +0300, İsmail Dönmez wrote:
>>> Cumartesi 1 Temmuz 2006 00:29 tarihinde şunları yazmıştınız:
>>>> (I wish the authors of Skype, Flash, TeamSpeak, Enemy Territory, and
>>>> other proprietary OSS-only apps would understand this ;-)
>>> New skype beta supports Alsa, doesn't work ATM but its a great step in
>>> that direction and Flash9 for Linux will use Alsa.
>> Really?  Got a link?  Last I heard about Flash was that their lawyers
>> won't let them link to LGPL libraries which would rule out ALSA support.
> 
> Hear from the lead developer for Flash Linux : 
> http://blogs.adobe.com/penguin.swf/2006/06/week_in_review_1.html
> 
Is that right? After years of negative comments about Flash and OSS, as 
soon as it's converted to ALSA v1 api that going out in 2.6.18?

-- 
Bill Davidsen <davidsen@tmr.com>
   Obscure bug of 2004: BASH BUFFER OVERFLOW - if bash is being run by a
normal user and is setuid root, with the "vi" line edit mode selected,
and the character set is "big5," an off-by-one errors occurs during
wildcard (glob) expansion.

Re: OSS driver removal, 2nd round

[Stefan Smietanowski]

[-- Attachment #1: Type: text/plain, Size: 1237 bytes --]

Bill Davidsen wrote:
> İsmail Dönmez wrote:
> 
>> Cumartesi 1 Temmuz 2006 00:56 tarihinde, Lee Revell şunları yazmıştı:
>>
>>> On Sat, 2006-07-01 at 00:42 +0300, İsmail Dönmez wrote:
>>>
>>>> Cumartesi 1 Temmuz 2006 00:29 tarihinde şunları yazmıştınız:
>>>>
>>>>> (I wish the authors of Skype, Flash, TeamSpeak, Enemy Territory, and
>>>>> other proprietary OSS-only apps would understand this ;-)
>>>>
>>>> New skype beta supports Alsa, doesn't work ATM but its a great step in
>>>> that direction and Flash9 for Linux will use Alsa.
>>>
>>> Really?  Got a link?  Last I heard about Flash was that their lawyers
>>> won't let them link to LGPL libraries which would rule out ALSA support.
>>
>>
>> Hear from the lead developer for Flash Linux :
>> http://blogs.adobe.com/penguin.swf/2006/06/week_in_review_1.html
>>
> Is that right? After years of negative comments about Flash and OSS, as
> soon as it's converted to ALSA v1 api that going out in 2.6.18?
> 

Actually I think you're mixing stuff up ?

It's being written for v4l v1 api which is being phased out with 2.6.18.

They already have alsa working (and from the sound of it it's working
great!).

v4l != alsa. :)

// Stefan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 251 bytes --]

Re: [Alsa-devel] OSS driver removal, 2nd round

[Stefan Smietanowski]

[-- Attachment #1: Type: text/plain, Size: 912 bytes --]

Jan Engelhardt wrote:
>>>Well you could patch the affected plugin's .dynstr table so that it should at
>>>best try to call a function that has not yet been defined somewhere else (like
>>>open); IOW, you change the .dynstr entry from 'open' to say 'my_open', and
>>>regularly include libmy.so through e.g. LD_PRELOAD.
>>>
>>>Of course the MD5 won't match afterwards, but I think the plugin should execute
>>>as usual afterwards, since .dynstr is something no app should rely on.
>>
>>Is this likely to work with an app like Skype that takes extensive steps
>>to thwart reverse engineers?
> 
> 
> We do not reverse engineer the .text section, but change the .dynstr 
> section that is specific to the ELF format. I doubt any app out there md5s 
> itself.

There is at least one. True that it doesn't do sound (it's an antivirus
scanner for mailservers :)) but regardless, it checksums the whole
thing.

// Stefan

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 251 bytes --]

Re: OSS driver removal, 2nd round

[Lee Revell]

On Wed, 2006-07-05 at 09:27 +0200, Stefan Smietanowski wrote:
> It's being written for v4l v1 api which is being phased out with
> 2.6.18.
> 
> They already have alsa working (and from the sound of it it's working
> great!).
> 
> v4l != alsa. :) 

A user visible API is being removed in 2.6.18?  Really?

I thought the rule was that 2.6 is a stable series therefore no
user-visible API changes were allowed.

Lee

Re: OSS driver removal, 2nd round

[Alan Cox]

Ar Mer, 2006-07-05 am 15:34 -0400, ysgrifennodd Lee Revell:
> > v4l != alsa. :) 
> 
> A user visible API is being removed in 2.6.18?  Really?
> 
> I thought the rule was that 2.6 is a stable series therefore no
> user-visible API changes were allowed.

V4L2 has a translation layer