From: Arnd Bergmann <arnd@arndb.de> To: Takashi Iwai <tiwai@suse.de> Cc: Arnd Bergmann <arnd@arndb.de>, Michael Forney <mforney@mforney.org>, ALSA Development Mailing List <alsa-devel@alsa-project.org>, Takashi Iwai <tiwai@suse.com>, Baolin Wang <baolin.wang@linaro.org>, y2038 Mailman List <y2038@lists.linaro.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Mark Brown <broonie@kernel.org>, Baolin Wang <baolin.wang7@gmail.com>, musl@lists.openwall.com Subject: Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control Date: Thu, 7 Oct 2021 15:11:00 +0200 [thread overview] Message-ID: <CAK8P3a0pSZxqfk-bn+idrDYDwANSfiP9L6U1O5jLQvK+3vwyVQ@mail.gmail.com> (raw) In-Reply-To: <s5hee8x9f92.wl-tiwai@suse.de> On Thu, Oct 7, 2021 at 2:43 PM Takashi Iwai <tiwai@suse.de> wrote: > On Thu, 07 Oct 2021 13:48:44 +0200, Arnd Bergmann wrote: > > On Thu, Oct 7, 2021 at 12:53 PM Takashi Iwai <tiwai@suse.de> wrote: > > > On Wed, 06 Oct 2021 19:49:17 +0200, Michael Forney wrote: > > > > As far as I can tell, the broken interface will always result in > > user space seeing a zero value for "avail_min". Can you > > make a prediction what that would mean for actual > > applications? Will they have no audio output, run into > > a crash, or be able to use recover and appear to work normally > > here? > > No, fortunately it's only about control->avail_min, and fiddling this > value can't break severely (otherwise it'd be a security problem ;) > > In the buggy condition, it's always zero, and the kernel treated as if > 1, i.e. wake up as soon as data is available, which is OK-ish for most > applications. Apps usually don't care about the wake-up condition so > much. There are subtle difference and may influence on the stability > of stream processing, but the stability usually depends more strongly > on the hardware and software configurations. > > That being said, the impact by this bug (from the application behavior > POV) is likely quite small, but the contamination is large; as you > pointed out, it's much larger than I thought. Ok, got it. > The definition in uapi/sound/asound.h is a bit cryptic, but IIUC, > __snd_pcm_mmap_control64 is used for 64bit archs, right? If so, the > problem rather hits more widely on 64bit archs silently. Then, the > influence by this bug must be almost negligible, as we've had no bug > report about the behavior change. While __snd_pcm_mmap_control64 is only used on 32-bit architectures when 64-bit time_t is used. At the moment, this means all users of musl-1.2.x libc, but not glibc. On 64-bit architectures, __snd_pcm_mmap_control and __snd_pcm_mmap_control64 are meant to be identical, and this is actually true regardless of the bug, since __pad_before_uframe and __pad_after_uframe both end up as zero-length arrays here. > We may just fix it in kernel and for new library with hoping that no > one sees the actual problem. Or, we may provide a complete new set of > mmap offsets and ioctl to cover both broken and fixed interfaces... > The decision depends on how perfectly we'd like to address the bug. > As of now, I'm inclined to go for the former, but I'm open for more > opinions. Adding the musl list to Cc for additional testers, anyone interested please see [1] for the original report. It would be good to hear from musl users that are already using audio support with 32-bit applications on 64-bit kernels, which is the case that has the problem today. Have you noticed any problems with audio support here? If not, we can probably "fix" the kernel here and make the existing binaries behave the same way on 32-bit kernels. If there are applications that don't work in that environment today, I think we need to instead change the kernel to accept the currently broken format on both 32-bit and 64-bit kernels, possibly introducing yet another format that works as originally intended but requires a newly built kernel. Arnd [1] https://lore.kernel.org/all/29QBMJU8DE71E.2YZSH8IHT5HMH@mforney.org/
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de> To: Takashi Iwai <tiwai@suse.de> Cc: ALSA Development Mailing List <alsa-devel@alsa-project.org>, Arnd Bergmann <arnd@arndb.de>, Baolin Wang <baolin.wang@linaro.org>, y2038 Mailman List <y2038@lists.linaro.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, musl@lists.openwall.com, Takashi Iwai <tiwai@suse.com>, Michael Forney <mforney@mforney.org>, Mark Brown <broonie@kernel.org>, Baolin Wang <baolin.wang7@gmail.com> Subject: Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control Date: Thu, 7 Oct 2021 15:11:00 +0200 [thread overview] Message-ID: <CAK8P3a0pSZxqfk-bn+idrDYDwANSfiP9L6U1O5jLQvK+3vwyVQ@mail.gmail.com> (raw) In-Reply-To: <s5hee8x9f92.wl-tiwai@suse.de> On Thu, Oct 7, 2021 at 2:43 PM Takashi Iwai <tiwai@suse.de> wrote: > On Thu, 07 Oct 2021 13:48:44 +0200, Arnd Bergmann wrote: > > On Thu, Oct 7, 2021 at 12:53 PM Takashi Iwai <tiwai@suse.de> wrote: > > > On Wed, 06 Oct 2021 19:49:17 +0200, Michael Forney wrote: > > > > As far as I can tell, the broken interface will always result in > > user space seeing a zero value for "avail_min". Can you > > make a prediction what that would mean for actual > > applications? Will they have no audio output, run into > > a crash, or be able to use recover and appear to work normally > > here? > > No, fortunately it's only about control->avail_min, and fiddling this > value can't break severely (otherwise it'd be a security problem ;) > > In the buggy condition, it's always zero, and the kernel treated as if > 1, i.e. wake up as soon as data is available, which is OK-ish for most > applications. Apps usually don't care about the wake-up condition so > much. There are subtle difference and may influence on the stability > of stream processing, but the stability usually depends more strongly > on the hardware and software configurations. > > That being said, the impact by this bug (from the application behavior > POV) is likely quite small, but the contamination is large; as you > pointed out, it's much larger than I thought. Ok, got it. > The definition in uapi/sound/asound.h is a bit cryptic, but IIUC, > __snd_pcm_mmap_control64 is used for 64bit archs, right? If so, the > problem rather hits more widely on 64bit archs silently. Then, the > influence by this bug must be almost negligible, as we've had no bug > report about the behavior change. While __snd_pcm_mmap_control64 is only used on 32-bit architectures when 64-bit time_t is used. At the moment, this means all users of musl-1.2.x libc, but not glibc. On 64-bit architectures, __snd_pcm_mmap_control and __snd_pcm_mmap_control64 are meant to be identical, and this is actually true regardless of the bug, since __pad_before_uframe and __pad_after_uframe both end up as zero-length arrays here. > We may just fix it in kernel and for new library with hoping that no > one sees the actual problem. Or, we may provide a complete new set of > mmap offsets and ioctl to cover both broken and fixed interfaces... > The decision depends on how perfectly we'd like to address the bug. > As of now, I'm inclined to go for the former, but I'm open for more > opinions. Adding the musl list to Cc for additional testers, anyone interested please see [1] for the original report. It would be good to hear from musl users that are already using audio support with 32-bit applications on 64-bit kernels, which is the case that has the problem today. Have you noticed any problems with audio support here? If not, we can probably "fix" the kernel here and make the existing binaries behave the same way on 32-bit kernels. If there are applications that don't work in that environment today, I think we need to instead change the kernel to accept the currently broken format on both 32-bit and 64-bit kernels, possibly introducing yet another format that works as originally intended but requires a newly built kernel. Arnd [1] https://lore.kernel.org/all/29QBMJU8DE71E.2YZSH8IHT5HMH@mforney.org/
next prev parent reply other threads:[~2021-10-07 13:11 UTC|newest] Thread overview: 94+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-12-11 21:20 [PATCH v7 0/8] Fix year 2038 issue for sound subsystem Arnd Bergmann 2019-12-11 21:20 ` [alsa-devel] " Arnd Bergmann 2019-12-11 21:20 ` [PATCH v7 1/9] ALSA: Replace timespec with timespec64 Arnd Bergmann 2019-12-11 21:20 ` [alsa-devel] " Arnd Bergmann 2019-12-11 21:20 ` [PATCH v7 2/9] ALSA: Avoid using timespec for struct snd_timer_status Arnd Bergmann 2019-12-11 21:20 ` [alsa-devel] " Arnd Bergmann 2019-12-11 21:20 ` [PATCH v7 3/9] ALSA: Avoid using timespec for struct snd_ctl_elem_value Arnd Bergmann 2019-12-11 21:20 ` [alsa-devel] " Arnd Bergmann 2019-12-11 21:20 ` [PATCH v7 4/9] ALSA: Avoid using timespec for struct snd_pcm_status Arnd Bergmann 2019-12-11 21:20 ` [alsa-devel] " Arnd Bergmann 2019-12-11 21:20 ` [PATCH v7 5/9] ALSA: Avoid using timespec for struct snd_rawmidi_status Arnd Bergmann 2019-12-11 21:20 ` [alsa-devel] " Arnd Bergmann 2019-12-11 21:20 ` [PATCH v7 6/9] ALSA: Avoid using timespec for struct snd_timer_tread Arnd Bergmann 2019-12-11 21:20 ` [alsa-devel] " Arnd Bergmann 2019-12-12 0:14 ` [Y2038] " Ben Hutchings 2019-12-12 0:14 ` [alsa-devel] " Ben Hutchings 2019-12-12 9:57 ` Arnd Bergmann 2019-12-12 9:57 ` [alsa-devel] " Arnd Bergmann 2019-12-12 14:27 ` Ben Hutchings 2019-12-12 14:27 ` [alsa-devel] " Ben Hutchings 2019-12-13 10:25 ` Arnd Bergmann 2019-12-13 10:25 ` [alsa-devel] " Arnd Bergmann 2019-12-11 21:20 ` [PATCH v7 7/9] ALSA: move snd_pcm_ioctl_sync_ptr_compat into pcm_native.c Arnd Bergmann 2019-12-11 21:20 ` [alsa-devel] " Arnd Bergmann 2019-12-11 21:20 ` [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control Arnd Bergmann 2019-12-11 21:20 ` [alsa-devel] " Arnd Bergmann 2021-10-06 17:49 ` Michael Forney 2021-10-06 17:49 ` Michael Forney 2021-10-07 10:52 ` Takashi Iwai 2021-10-07 10:52 ` Takashi Iwai 2021-10-07 11:48 ` Arnd Bergmann 2021-10-07 11:48 ` Arnd Bergmann 2021-10-07 12:43 ` Takashi Iwai 2021-10-07 12:43 ` Takashi Iwai 2021-10-07 13:02 ` Takashi Iwai 2021-10-07 13:02 ` Takashi Iwai 2021-10-07 13:11 ` Arnd Bergmann [this message] 2021-10-07 13:11 ` Arnd Bergmann 2021-10-07 15:33 ` Takashi Iwai 2021-10-07 15:33 ` Takashi Iwai 2021-10-07 16:06 ` [musl] " Rich Felker 2021-10-07 16:06 ` Rich Felker 2021-10-07 16:18 ` Takashi Iwai 2021-10-07 16:18 ` Takashi Iwai 2021-10-07 16:51 ` Rich Felker 2021-10-07 16:51 ` Rich Felker 2021-10-08 8:43 ` Takashi Iwai 2021-10-08 8:43 ` Takashi Iwai 2021-10-08 8:44 ` Takashi Iwai 2021-10-08 8:44 ` Takashi Iwai 2021-10-08 9:24 ` Arnd Bergmann 2021-10-08 9:24 ` Arnd Bergmann 2021-10-08 11:11 ` Takashi Iwai 2021-10-08 11:11 ` Takashi Iwai 2021-10-08 11:45 ` Arnd Bergmann 2021-10-08 11:45 ` Arnd Bergmann 2021-10-08 11:53 ` Takashi Iwai 2021-10-08 11:53 ` Takashi Iwai 2021-10-08 12:13 ` Arnd Bergmann 2021-10-08 12:13 ` Arnd Bergmann 2021-10-08 12:07 ` Rich Felker 2021-10-08 12:07 ` Rich Felker 2021-10-10 7:53 ` Takashi Iwai 2021-10-10 7:53 ` Takashi Iwai 2021-10-18 14:43 ` Rich Felker 2021-10-18 14:43 ` Rich Felker 2021-10-18 14:58 ` Takashi Iwai 2021-10-18 14:58 ` Takashi Iwai 2021-10-18 15:08 ` Rich Felker 2021-10-18 15:08 ` Rich Felker 2021-10-18 15:26 ` Arnd Bergmann 2021-10-18 15:26 ` Arnd Bergmann 2021-10-18 20:42 ` Rich Felker 2021-10-18 20:42 ` Rich Felker 2021-10-19 14:16 ` Rich Felker 2021-10-19 14:16 ` Rich Felker 2021-10-19 14:23 ` Arnd Bergmann 2021-10-19 14:23 ` Arnd Bergmann 2021-10-08 12:06 ` Rich Felker 2021-10-08 12:06 ` Rich Felker 2021-10-08 12:37 ` Arnd Bergmann 2021-10-08 12:37 ` Arnd Bergmann 2021-10-08 17:20 ` Rich Felker 2021-10-08 17:20 ` Rich Felker 2019-12-11 21:20 ` [PATCH v7 9/9] ALSA: bump uapi version numbers Arnd Bergmann 2019-12-11 21:20 ` [alsa-devel] " Arnd Bergmann 2019-12-17 10:42 ` [PATCH v7 0/8] Fix year 2038 issue for sound subsystem Takashi Iwai 2019-12-17 10:42 ` [alsa-devel] " Takashi Iwai 2019-12-17 21:15 ` Arnd Bergmann 2019-12-17 21:15 ` [alsa-devel] " Arnd Bergmann 2019-12-17 21:16 ` [GIT PULL, v8] " Arnd Bergmann 2019-12-17 21:16 ` [alsa-devel] " Arnd Bergmann 2019-12-17 22:22 ` [PATCH v7 0/8] " Takashi Iwai 2019-12-17 22:22 ` [alsa-devel] " Takashi Iwai
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAK8P3a0pSZxqfk-bn+idrDYDwANSfiP9L6U1O5jLQvK+3vwyVQ@mail.gmail.com \ --to=arnd@arndb.de \ --cc=alsa-devel@alsa-project.org \ --cc=baolin.wang7@gmail.com \ --cc=baolin.wang@linaro.org \ --cc=broonie@kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mforney@mforney.org \ --cc=musl@lists.openwall.com \ --cc=tiwai@suse.com \ --cc=tiwai@suse.de \ --cc=y2038@lists.linaro.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.