Re: [Y2038] [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
On Tue, Oct 19, 2021 at 4:16 PM Rich Felker wrote: > On Mon, Oct 18, 2021 at 04:42:04PM -0400, Rich Felker wrote: > > > > Well for little endian either would work (because adj is 0 :) but yes > > there are 3 such paddings before the second member on big endian, so > > it should be 3. > > How about this? It avoids open coding the logic and handles it as 2 > 4-byte substructures with endian-specific offsets. Looks good to me. Arnd ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
On Mon, Oct 18, 2021 at 04:42:04PM -0400, Rich Felker wrote:
> On Mon, Oct 18, 2021 at 05:26:35PM +0200, Arnd Bergmann wrote:
> > On Mon, Oct 18, 2021 at 5:08 PM Rich Felker wrote:
> > > On Mon, Oct 18, 2021 at 04:58:03PM +0200, Takashi Iwai wrote:
> > > > On Mon, 18 Oct 2021 16:43:00 +0200, Rich Felker wrote:
> > >
> > > No, I don't think so. The musl translator is to translate between the
> > > time64 ioctl structures and the old time32 ones for the sake of
> > > executing on an old kernel. Up til now, it has been broken comparably
> > > to how 32-bit binaries running in compat mode on a 64-bit kernel were
> > > broken: the code in musl translated the time64 structure to (and back
> > > from) the time32 one assuming the intended padding. But the
> > > application was using the actual kernel uapi struct where the padding
> > > was (and still is) illogical. Thus, nothing was built with the wrong
> > > ABI; it's only the musl-internal translation logic that was wrong (and
> > > only pre-time64 kernels are affected).
> > >
> > > The attached patch should fix it, I think.
> > >
> > > + int adj = BYTE_ORDER==BIG_ENDIAN ? 4 : 0;
> > > + if (dir==W) {
> > > + memcpy(old+68, new+72+adj, 4);
> > > + memcpy(old+72, new+72+4+2*adj, 4);
> >
> > I think that should be "new+72+4+3*adj": the "2*adj" would
> > be what the code does already for the originally intended
> > format.
>
> Well for little endian either would work (because adj is 0 :) but yes
> there are 3 such paddings before the second member on big endian, so
> it should be 3.
How about this? It avoids open coding the logic and handles it as 2
4-byte substructures with endian-specific offsets.
Rich
diff --git a/src/misc/ioctl.c b/src/misc/ioctl.c
index 49282811..35804f02 100644
--- a/src/misc/ioctl.c
+++ b/src/misc/ioctl.c
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
#include "syscall.h"
#define alignof(t) offsetof(struct { char c; t x; }, x)
@@ -53,7 +54,7 @@ static const struct ioctl_compat_map compat_map[] = {
{ _IOWR('A', 0x23, char[136]), _IOWR('A', 0x23, char[132]), 0, WR, 1, 0
},
{ 0, 0, 4, WR, 1, 0 }, /* snd_pcm_sync_ptr (flags only) */
{ 0, 0, 32, WR, 1, OFFS(8,12,16,24,28) }, /* snd_pcm_mmap_status */
- { 0, 0, 8, WR, 1, OFFS(0,4) }, /* snd_pcm_mmap_control */
+ { 0, 0, 4, WR, 1, 0 }, /* snd_pcm_mmap_control (each member) */
/* VIDIOC_QUERYBUF, VIDIOC_QBUF, VIDIOC_DQBUF, VIDIOC_PREPARE_BUF */
{ _IOWR('V', 9, new_misaligned(68)), _IOWR('V', 9, char[68]), 68, WR,
1, OFFS(20, 24) },
@@ -90,7 +91,11 @@ static void convert_ioctl_struct(const struct
ioctl_compat_map *map, char *old,
* if another exception appears this needs changing. */
convert_ioctl_struct(map+1, old, new, dir);
convert_ioctl_struct(map+2, old+4, new+8, dir);
- convert_ioctl_struct(map+3, old+68, new+72, dir);
+ /* snd_pcm_mmap_control, special-cased due to kernel
+* type definition having been botched. */
+ int adj = BYTE_ORDER==BIG_ENDIAN ? 4 : 0;
+ convert_ioctl_struct(map+3, old+68, new+72+adj, dir);
+ convert_ioctl_struct(map+3, old+72, new+76+3*adj, dir);
return;
}
for (int i=0; i < map->noffs; i++) {
___
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
On Mon, Oct 18, 2021 at 05:26:35PM +0200, Arnd Bergmann wrote:
> On Mon, Oct 18, 2021 at 5:08 PM Rich Felker wrote:
> > On Mon, Oct 18, 2021 at 04:58:03PM +0200, Takashi Iwai wrote:
> > > On Mon, 18 Oct 2021 16:43:00 +0200, Rich Felker wrote:
> >
> > No, I don't think so. The musl translator is to translate between the
> > time64 ioctl structures and the old time32 ones for the sake of
> > executing on an old kernel. Up til now, it has been broken comparably
> > to how 32-bit binaries running in compat mode on a 64-bit kernel were
> > broken: the code in musl translated the time64 structure to (and back
> > from) the time32 one assuming the intended padding. But the
> > application was using the actual kernel uapi struct where the padding
> > was (and still is) illogical. Thus, nothing was built with the wrong
> > ABI; it's only the musl-internal translation logic that was wrong (and
> > only pre-time64 kernels are affected).
> >
> > The attached patch should fix it, I think.
> >
> > + int adj = BYTE_ORDER==BIG_ENDIAN ? 4 : 0;
> > + if (dir==W) {
> > + memcpy(old+68, new+72+adj, 4);
> > + memcpy(old+72, new+72+4+2*adj, 4);
>
> I think that should be "new+72+4+3*adj": the "2*adj" would
> be what the code does already for the originally intended
> format.
Well for little endian either would work (because adj is 0 :) but yes
there are 3 such paddings before the second member on big endian, so
it should be 3.
Rich
___
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
On Mon, Oct 18, 2021 at 5:08 PM Rich Felker wrote:
> On Mon, Oct 18, 2021 at 04:58:03PM +0200, Takashi Iwai wrote:
> > On Mon, 18 Oct 2021 16:43:00 +0200, Rich Felker wrote:
>
> No, I don't think so. The musl translator is to translate between the
> time64 ioctl structures and the old time32 ones for the sake of
> executing on an old kernel. Up til now, it has been broken comparably
> to how 32-bit binaries running in compat mode on a 64-bit kernel were
> broken: the code in musl translated the time64 structure to (and back
> from) the time32 one assuming the intended padding. But the
> application was using the actual kernel uapi struct where the padding
> was (and still is) illogical. Thus, nothing was built with the wrong
> ABI; it's only the musl-internal translation logic that was wrong (and
> only pre-time64 kernels are affected).
>
> The attached patch should fix it, I think.
>
> + int adj = BYTE_ORDER==BIG_ENDIAN ? 4 : 0;
> + if (dir==W) {
> + memcpy(old+68, new+72+adj, 4);
> + memcpy(old+72, new+72+4+2*adj, 4);
I think that should be "new+72+4+3*adj": the "2*adj" would
be what the code does already for the originally intended
format.
Arnd
___
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
On Mon, Oct 18, 2021 at 04:58:03PM +0200, Takashi Iwai wrote:
> On Mon, 18 Oct 2021 16:43:00 +0200,
> Rich Felker wrote:
> >
> > On Sun, Oct 10, 2021 at 09:53:38AM +0200, Takashi Iwai wrote:
> > > On Fri, 08 Oct 2021 14:07:39 +0200,
> > > Rich Felker wrote:
> > > >
> > > > On Fri, Oct 08, 2021 at 01:11:34PM +0200, Takashi Iwai wrote:
> > > > > On Fri, 08 Oct 2021 11:24:39 +0200,
> > > > > Arnd Bergmann wrote:
> > > > > >
> > > > > > On Fri, Oct 8, 2021 at 10:43 AM Takashi Iwai wrote:
> > > > > > > On Thu, 07 Oct 2021 18:51:58 +0200, Rich Felker wrote:
> > > > > > > > On Thu, Oct 07, 2021 at 06:18:52PM +0200, Takashi Iwai wrote:
> > > > > > >
> > > > > > > @@ -557,11 +558,15 @@ struct __snd_pcm_sync_ptr {
> > > > > > > #if defined(__BYTE_ORDER) ? __BYTE_ORDER == __BIG_ENDIAN :
> > > > > > > defined(__BIG_ENDIAN)
> > > > > > > typedef char __pad_before_uframe[sizeof(__u64) -
> > > > > > > sizeof(snd_pcm_uframes_t)];
> > > > > > > typedef char __pad_after_uframe[0];
> > > > > > > +typedef char __pad_before_u32[4];
> > > > > > > +typedef char __pad_after_u32[0];
> > > > > > > #endif
> > > > > > >
> > > > > > > #if defined(__BYTE_ORDER) ? __BYTE_ORDER == __LITTLE_ENDIAN :
> > > > > > > defined(__LITTLE_ENDIAN)
> > > > > > > typedef char __pad_before_uframe[0];
> > > > > > > typedef char __pad_after_uframe[sizeof(__u64) -
> > > > > > > sizeof(snd_pcm_uframes_t)];
> > > > > > > +typedef char __pad_before_u32[0];
> > > > > > > +typedef char __pad_after_u32[4];
> > > > > > > #endif
> > > > > >
> > > > > > I think these should remain unchanged, the complex expression was
> > > > > > intentionally
> > > > > > done so the structures are laid out the same way on 64-bit
> > > > > > architectures, so that
> > > > > > the kernel can use the __SND_STRUCT_TIME64 path internally on both
> > > > > > 32-bit
> > > > > > and 64-bit architectures.
> > > > >
> > > > > That was explicitly defined, but OK, this isn't necessarily defined
> > > > > here.
> > > > >
> > > > > > > @@ -2970,8 +2981,17 @@ static int snd_pcm_sync_ptr(struct
> > > > > > > snd_pcm_substream *substream,
> > > > > > > memset(&sync_ptr, 0, sizeof(sync_ptr));
> > > > > > > if (get_user(sync_ptr.flags, (unsigned __user
> > > > > > > *)&(_sync_ptr->flags)))
> > > > > > > return -EFAULT;
> > > > > > > - if (copy_from_user(&sync_ptr.c.control,
> > > > > > > &(_sync_ptr->c.control), sizeof(struct snd_pcm_mmap_control)))
> > > > > > > - return -EFAULT;
> > > > > > > + if (buggy_control) {
> > > > > > > + if (copy_from_user(&sync_ptr.c.control_api_2_0_15,
> > > > > > > +
> > > > > > > &(_sync_ptr->c.control_api_2_0_15),
> > > > > > > +
> > > > > > > sizeof(sync_ptr.c.control_api_2_0_15)))
> > > > > > > + return -EFAULT;
> > > > > > > + } else {
> > > > > > > + if (copy_from_user(&sync_ptr.c.control,
> > > > > > > + &(_sync_ptr->c.control),
> > > > > > > + sizeof(sync_ptr.c.control)))
> > > > > > > + return -EFAULT;
> > > > > > > + }
> > > > > >
> > > > > > The problem I see with this is that it might break musl's ability to
> > > > > > emulate the new
> > > > > > interface on top of the old (time32) one for linux-4.x and older
> > > > > > kernels, as the conversion
> > > > > > function is no longer stateless but has to know the negotiated
> > > > > > interface version.
> > > > > >
> > > > > > It's probably fine as long as we can be sure that the 2.0.16+ API
> > > > > > version only gets
> > > > > > negotiated if both the kernel and user sides support it, and musl
> > > > > > only emulates
> > > > > > the 2.0.15 API version from the current kernels.
> > > > > >
> > > > > > I've tried to understand this part of musl's
> > > > > > convert_ioctl_struct(), but I just
> > > > > > can't figure out whether it does the conversion based the on the
> > > > > > layout that
> > > > > > is currently used in the kernel, or based on the layout we should
> > > > > > have been
> > > > > > using, and would use with the above fix. Rich, can you help me here?
> > > > >
> > > > > So, at this moment, I'm not sure whether we should correct the struct
> > > > > at all. This will lead to yet more breakage, and basically the struct
> > > > > itself *works* -- the only bug is in 32bit compat handling in the
> > > > > kernel (again).
> > > > >
> > > > > The below is a revised kernel patch (again untested), just correcting
> > > > > the behavior of 32bit compat mode. 32bit apps on 32bit kernel work
> > > > > fine as is, as well as 64bit apps on 64bit kernel.
> > > >
> > > > I'm perfectly okay with this if Arnd is! It's probably the least
> > > > invasive and has the least long-term maintenance cost and fallout on
> > > > other projects.
> > >
> > > OK, I'll submit a proper patch now, to be in
Re: [Y2038] [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
On Mon, 18 Oct 2021 16:43:00 +0200,
Rich Felker wrote:
>
> On Sun, Oct 10, 2021 at 09:53:38AM +0200, Takashi Iwai wrote:
> > On Fri, 08 Oct 2021 14:07:39 +0200,
> > Rich Felker wrote:
> > >
> > > On Fri, Oct 08, 2021 at 01:11:34PM +0200, Takashi Iwai wrote:
> > > > On Fri, 08 Oct 2021 11:24:39 +0200,
> > > > Arnd Bergmann wrote:
> > > > >
> > > > > On Fri, Oct 8, 2021 at 10:43 AM Takashi Iwai wrote:
> > > > > > On Thu, 07 Oct 2021 18:51:58 +0200, Rich Felker wrote:
> > > > > > > On Thu, Oct 07, 2021 at 06:18:52PM +0200, Takashi Iwai wrote:
> > > > > >
> > > > > > @@ -557,11 +558,15 @@ struct __snd_pcm_sync_ptr {
> > > > > > #if defined(__BYTE_ORDER) ? __BYTE_ORDER == __BIG_ENDIAN :
> > > > > > defined(__BIG_ENDIAN)
> > > > > > typedef char __pad_before_uframe[sizeof(__u64) -
> > > > > > sizeof(snd_pcm_uframes_t)];
> > > > > > typedef char __pad_after_uframe[0];
> > > > > > +typedef char __pad_before_u32[4];
> > > > > > +typedef char __pad_after_u32[0];
> > > > > > #endif
> > > > > >
> > > > > > #if defined(__BYTE_ORDER) ? __BYTE_ORDER == __LITTLE_ENDIAN :
> > > > > > defined(__LITTLE_ENDIAN)
> > > > > > typedef char __pad_before_uframe[0];
> > > > > > typedef char __pad_after_uframe[sizeof(__u64) -
> > > > > > sizeof(snd_pcm_uframes_t)];
> > > > > > +typedef char __pad_before_u32[0];
> > > > > > +typedef char __pad_after_u32[4];
> > > > > > #endif
> > > > >
> > > > > I think these should remain unchanged, the complex expression was
> > > > > intentionally
> > > > > done so the structures are laid out the same way on 64-bit
> > > > > architectures, so that
> > > > > the kernel can use the __SND_STRUCT_TIME64 path internally on both
> > > > > 32-bit
> > > > > and 64-bit architectures.
> > > >
> > > > That was explicitly defined, but OK, this isn't necessarily defined
> > > > here.
> > > >
> > > > > > @@ -2970,8 +2981,17 @@ static int snd_pcm_sync_ptr(struct
> > > > > > snd_pcm_substream *substream,
> > > > > > memset(&sync_ptr, 0, sizeof(sync_ptr));
> > > > > > if (get_user(sync_ptr.flags, (unsigned __user
> > > > > > *)&(_sync_ptr->flags)))
> > > > > > return -EFAULT;
> > > > > > - if (copy_from_user(&sync_ptr.c.control,
> > > > > > &(_sync_ptr->c.control), sizeof(struct snd_pcm_mmap_control)))
> > > > > > - return -EFAULT;
> > > > > > + if (buggy_control) {
> > > > > > + if (copy_from_user(&sync_ptr.c.control_api_2_0_15,
> > > > > > +
> > > > > > &(_sync_ptr->c.control_api_2_0_15),
> > > > > > +
> > > > > > sizeof(sync_ptr.c.control_api_2_0_15)))
> > > > > > + return -EFAULT;
> > > > > > + } else {
> > > > > > + if (copy_from_user(&sync_ptr.c.control,
> > > > > > + &(_sync_ptr->c.control),
> > > > > > + sizeof(sync_ptr.c.control)))
> > > > > > + return -EFAULT;
> > > > > > + }
> > > > >
> > > > > The problem I see with this is that it might break musl's ability to
> > > > > emulate the new
> > > > > interface on top of the old (time32) one for linux-4.x and older
> > > > > kernels, as the conversion
> > > > > function is no longer stateless but has to know the negotiated
> > > > > interface version.
> > > > >
> > > > > It's probably fine as long as we can be sure that the 2.0.16+ API
> > > > > version only gets
> > > > > negotiated if both the kernel and user sides support it, and musl
> > > > > only emulates
> > > > > the 2.0.15 API version from the current kernels.
> > > > >
> > > > > I've tried to understand this part of musl's convert_ioctl_struct(),
> > > > > but I just
> > > > > can't figure out whether it does the conversion based the on the
> > > > > layout that
> > > > > is currently used in the kernel, or based on the layout we should
> > > > > have been
> > > > > using, and would use with the above fix. Rich, can you help me here?
> > > >
> > > > So, at this moment, I'm not sure whether we should correct the struct
> > > > at all. This will lead to yet more breakage, and basically the struct
> > > > itself *works* -- the only bug is in 32bit compat handling in the
> > > > kernel (again).
> > > >
> > > > The below is a revised kernel patch (again untested), just correcting
> > > > the behavior of 32bit compat mode. 32bit apps on 32bit kernel work
> > > > fine as is, as well as 64bit apps on 64bit kernel.
> > >
> > > I'm perfectly okay with this if Arnd is! It's probably the least
> > > invasive and has the least long-term maintenance cost and fallout on
> > > other projects.
> >
> > OK, I'll submit a proper patch now, to be included in the next PR for
> > 5.15-rc. For further fixes, let's think carefully.
>
> Am I correct in my understanding that the fix of keeping the "broken"
> definition (and having the 64-bit kernel honor it for 32-bit binaries)
> has been accepted?
Yes, as it was a
Re: [Y2038] [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
On Sun, Oct 10, 2021 at 09:53:38AM +0200, Takashi Iwai wrote:
> On Fri, 08 Oct 2021 14:07:39 +0200,
> Rich Felker wrote:
> >
> > On Fri, Oct 08, 2021 at 01:11:34PM +0200, Takashi Iwai wrote:
> > > On Fri, 08 Oct 2021 11:24:39 +0200,
> > > Arnd Bergmann wrote:
> > > >
> > > > On Fri, Oct 8, 2021 at 10:43 AM Takashi Iwai wrote:
> > > > > On Thu, 07 Oct 2021 18:51:58 +0200, Rich Felker wrote:
> > > > > > On Thu, Oct 07, 2021 at 06:18:52PM +0200, Takashi Iwai wrote:
> > > > >
> > > > > @@ -557,11 +558,15 @@ struct __snd_pcm_sync_ptr {
> > > > > #if defined(__BYTE_ORDER) ? __BYTE_ORDER == __BIG_ENDIAN :
> > > > > defined(__BIG_ENDIAN)
> > > > > typedef char __pad_before_uframe[sizeof(__u64) -
> > > > > sizeof(snd_pcm_uframes_t)];
> > > > > typedef char __pad_after_uframe[0];
> > > > > +typedef char __pad_before_u32[4];
> > > > > +typedef char __pad_after_u32[0];
> > > > > #endif
> > > > >
> > > > > #if defined(__BYTE_ORDER) ? __BYTE_ORDER == __LITTLE_ENDIAN :
> > > > > defined(__LITTLE_ENDIAN)
> > > > > typedef char __pad_before_uframe[0];
> > > > > typedef char __pad_after_uframe[sizeof(__u64) -
> > > > > sizeof(snd_pcm_uframes_t)];
> > > > > +typedef char __pad_before_u32[0];
> > > > > +typedef char __pad_after_u32[4];
> > > > > #endif
> > > >
> > > > I think these should remain unchanged, the complex expression was
> > > > intentionally
> > > > done so the structures are laid out the same way on 64-bit
> > > > architectures, so that
> > > > the kernel can use the __SND_STRUCT_TIME64 path internally on both
> > > > 32-bit
> > > > and 64-bit architectures.
> > >
> > > That was explicitly defined, but OK, this isn't necessarily defined
> > > here.
> > >
> > > > > @@ -2970,8 +2981,17 @@ static int snd_pcm_sync_ptr(struct
> > > > > snd_pcm_substream *substream,
> > > > > memset(&sync_ptr, 0, sizeof(sync_ptr));
> > > > > if (get_user(sync_ptr.flags, (unsigned __user
> > > > > *)&(_sync_ptr->flags)))
> > > > > return -EFAULT;
> > > > > - if (copy_from_user(&sync_ptr.c.control,
> > > > > &(_sync_ptr->c.control), sizeof(struct snd_pcm_mmap_control)))
> > > > > - return -EFAULT;
> > > > > + if (buggy_control) {
> > > > > + if (copy_from_user(&sync_ptr.c.control_api_2_0_15,
> > > > > + &(_sync_ptr->c.control_api_2_0_15),
> > > > > +
> > > > > sizeof(sync_ptr.c.control_api_2_0_15)))
> > > > > + return -EFAULT;
> > > > > + } else {
> > > > > + if (copy_from_user(&sync_ptr.c.control,
> > > > > + &(_sync_ptr->c.control),
> > > > > + sizeof(sync_ptr.c.control)))
> > > > > + return -EFAULT;
> > > > > + }
> > > >
> > > > The problem I see with this is that it might break musl's ability to
> > > > emulate the new
> > > > interface on top of the old (time32) one for linux-4.x and older
> > > > kernels, as the conversion
> > > > function is no longer stateless but has to know the negotiated
> > > > interface version.
> > > >
> > > > It's probably fine as long as we can be sure that the 2.0.16+ API
> > > > version only gets
> > > > negotiated if both the kernel and user sides support it, and musl only
> > > > emulates
> > > > the 2.0.15 API version from the current kernels.
> > > >
> > > > I've tried to understand this part of musl's convert_ioctl_struct(),
> > > > but I just
> > > > can't figure out whether it does the conversion based the on the layout
> > > > that
> > > > is currently used in the kernel, or based on the layout we should have
> > > > been
> > > > using, and would use with the above fix. Rich, can you help me here?
> > >
> > > So, at this moment, I'm not sure whether we should correct the struct
> > > at all. This will lead to yet more breakage, and basically the struct
> > > itself *works* -- the only bug is in 32bit compat handling in the
> > > kernel (again).
> > >
> > > The below is a revised kernel patch (again untested), just correcting
> > > the behavior of 32bit compat mode. 32bit apps on 32bit kernel work
> > > fine as is, as well as 64bit apps on 64bit kernel.
> >
> > I'm perfectly okay with this if Arnd is! It's probably the least
> > invasive and has the least long-term maintenance cost and fallout on
> > other projects.
>
> OK, I'll submit a proper patch now, to be included in the next PR for
> 5.15-rc. For further fixes, let's think carefully.
Am I correct in my understanding that the fix of keeping the "broken"
definition (and having the 64-bit kernel honor it for 32-bit binaries)
has been accepted? Since musl's translation for pre-time64 kernels
seems to have been using the "non-broken" definition, I think
completing the fix requires a change in musl too.
Rich
___
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinf
Re: [Y2038] [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
On Fri, 08 Oct 2021 14:07:39 +0200,
Rich Felker wrote:
>
> On Fri, Oct 08, 2021 at 01:11:34PM +0200, Takashi Iwai wrote:
> > On Fri, 08 Oct 2021 11:24:39 +0200,
> > Arnd Bergmann wrote:
> > >
> > > On Fri, Oct 8, 2021 at 10:43 AM Takashi Iwai wrote:
> > > > On Thu, 07 Oct 2021 18:51:58 +0200, Rich Felker wrote:
> > > > > On Thu, Oct 07, 2021 at 06:18:52PM +0200, Takashi Iwai wrote:
> > > >
> > > > @@ -557,11 +558,15 @@ struct __snd_pcm_sync_ptr {
> > > > #if defined(__BYTE_ORDER) ? __BYTE_ORDER == __BIG_ENDIAN :
> > > > defined(__BIG_ENDIAN)
> > > > typedef char __pad_before_uframe[sizeof(__u64) -
> > > > sizeof(snd_pcm_uframes_t)];
> > > > typedef char __pad_after_uframe[0];
> > > > +typedef char __pad_before_u32[4];
> > > > +typedef char __pad_after_u32[0];
> > > > #endif
> > > >
> > > > #if defined(__BYTE_ORDER) ? __BYTE_ORDER == __LITTLE_ENDIAN :
> > > > defined(__LITTLE_ENDIAN)
> > > > typedef char __pad_before_uframe[0];
> > > > typedef char __pad_after_uframe[sizeof(__u64) -
> > > > sizeof(snd_pcm_uframes_t)];
> > > > +typedef char __pad_before_u32[0];
> > > > +typedef char __pad_after_u32[4];
> > > > #endif
> > >
> > > I think these should remain unchanged, the complex expression was
> > > intentionally
> > > done so the structures are laid out the same way on 64-bit
> > > architectures, so that
> > > the kernel can use the __SND_STRUCT_TIME64 path internally on both 32-bit
> > > and 64-bit architectures.
> >
> > That was explicitly defined, but OK, this isn't necessarily defined
> > here.
> >
> > > > @@ -2970,8 +2981,17 @@ static int snd_pcm_sync_ptr(struct
> > > > snd_pcm_substream *substream,
> > > > memset(&sync_ptr, 0, sizeof(sync_ptr));
> > > > if (get_user(sync_ptr.flags, (unsigned __user
> > > > *)&(_sync_ptr->flags)))
> > > > return -EFAULT;
> > > > - if (copy_from_user(&sync_ptr.c.control,
> > > > &(_sync_ptr->c.control), sizeof(struct snd_pcm_mmap_control)))
> > > > - return -EFAULT;
> > > > + if (buggy_control) {
> > > > + if (copy_from_user(&sync_ptr.c.control_api_2_0_15,
> > > > + &(_sync_ptr->c.control_api_2_0_15),
> > > > +
> > > > sizeof(sync_ptr.c.control_api_2_0_15)))
> > > > + return -EFAULT;
> > > > + } else {
> > > > + if (copy_from_user(&sync_ptr.c.control,
> > > > + &(_sync_ptr->c.control),
> > > > + sizeof(sync_ptr.c.control)))
> > > > + return -EFAULT;
> > > > + }
> > >
> > > The problem I see with this is that it might break musl's ability to
> > > emulate the new
> > > interface on top of the old (time32) one for linux-4.x and older
> > > kernels, as the conversion
> > > function is no longer stateless but has to know the negotiated
> > > interface version.
> > >
> > > It's probably fine as long as we can be sure that the 2.0.16+ API
> > > version only gets
> > > negotiated if both the kernel and user sides support it, and musl only
> > > emulates
> > > the 2.0.15 API version from the current kernels.
> > >
> > > I've tried to understand this part of musl's convert_ioctl_struct(), but
> > > I just
> > > can't figure out whether it does the conversion based the on the layout
> > > that
> > > is currently used in the kernel, or based on the layout we should have
> > > been
> > > using, and would use with the above fix. Rich, can you help me here?
> >
> > So, at this moment, I'm not sure whether we should correct the struct
> > at all. This will lead to yet more breakage, and basically the struct
> > itself *works* -- the only bug is in 32bit compat handling in the
> > kernel (again).
> >
> > The below is a revised kernel patch (again untested), just correcting
> > the behavior of 32bit compat mode. 32bit apps on 32bit kernel work
> > fine as is, as well as 64bit apps on 64bit kernel.
>
> I'm perfectly okay with this if Arnd is! It's probably the least
> invasive and has the least long-term maintenance cost and fallout on
> other projects.
OK, I'll submit a proper patch now, to be included in the next PR for
5.15-rc. For further fixes, let's think carefully.
thanks,
Takashi
___
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
On Fri, Oct 08, 2021 at 02:37:12PM +0200, Arnd Bergmann wrote: > On Fri, Oct 8, 2021 at 2:06 PM Rich Felker wrote: > > On Fri, Oct 08, 2021 at 11:24:39AM +0200, Arnd Bergmann wrote: > > > > > > I've tried to understand this part of musl's convert_ioctl_struct(), but > > > I just > > > can't figure out whether it does the conversion based the on the layout > > > that > > > is currently used in the kernel, or based on the layout we should have > > > been > > > using, and would use with the above fix. Rich, can you help me here? > > > > If the attempted 64-bit ioctl is missing (ENOTTY), it does the > > conversion to the legacy 32-bit one and retries with that, then > > converts the results back to the 64-bit form. > > I understand that it tries to do that. > > The part that I'm not sure about is which of the two possible > 64-bit forms it's using -- the broken one we have defined in the > kernel headers, or the one we were trying to define but failed. It's attempting to convert the intended format, not the one that the uapi headers defined. That is, it's taking padded-to-64-bit values at offsets 0 and 8 in __snd_pcm_mmap_control64, putting them at offsets 0 and 4 in the 32-bit struct, and padding them back to 64-bit in the result. Since applications would have been compiled with the buggy (unintended) version of the uapi headers, this will not match the application's layout of the struct. I haven't worked through what all the consequences of that are, but I think some fix is needed here in musl regardless of what happens on the kernel side. Rich ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
On Fri, Oct 8, 2021 at 2:06 PM Rich Felker wrote: > On Fri, Oct 08, 2021 at 11:24:39AM +0200, Arnd Bergmann wrote: > > > > I've tried to understand this part of musl's convert_ioctl_struct(), but I > > just > > can't figure out whether it does the conversion based the on the layout that > > is currently used in the kernel, or based on the layout we should have been > > using, and would use with the above fix. Rich, can you help me here? > > If the attempted 64-bit ioctl is missing (ENOTTY), it does the > conversion to the legacy 32-bit one and retries with that, then > converts the results back to the 64-bit form. I understand that it tries to do that. The part that I'm not sure about is which of the two possible 64-bit forms it's using -- the broken one we have defined in the kernel headers, or the one we were trying to define but failed. Arnd ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
On Fri, Oct 8, 2021 at 1:53 PM Takashi Iwai wrote:
> On Fri, 08 Oct 2021 13:45:45 +0200, Arnd Bergmann wrote:
> > On Fri, Oct 8, 2021 at 1:11 PM Takashi Iwai wrote:
> > > On Fri, 08 Oct 2021 11:24:39 +0200, Arnd Bergmann wrote:
> > > The below is a revised kernel patch (again untested), just correcting
> > > the behavior of 32bit compat mode. 32bit apps on 32bit kernel work
> > > fine as is, as well as 64bit apps on 64bit kernel.
> >
> > Right, this should cover all cases of the ioctl itself misbehaving.
> > In addition, we still need to disallow the mmap() interface on compat
> > kernels then. Strictly speaking, we could allow the snd_pcm_mmap_status
> > but not snd_pcm_mmap_control to be mapped, but I'm not sure if
> > that's better than disallowing both.
>
> IIRC, the compat mmap is already disallowed even for the
> SNDRV_PCM_MMAP_OFFSET_CONTROL_NEW (in pcm_control_mmap_allowed()), so
> no need to change around that.
Ah, right. I think it was meant to become allowed as part of commit
80fe7430c708 ("ALSA: add new 32-bit layout for snd_pcm_mmap_status/control"),
which did allow the snd_pcm_mmap_status to be mmap()ed, but it appears
to be the rare case where two mistakes cancel out and we don't have to
change the mmap code.
Arnd
___
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
On Fri, Oct 08, 2021 at 01:11:34PM +0200, Takashi Iwai wrote:
> On Fri, 08 Oct 2021 11:24:39 +0200,
> Arnd Bergmann wrote:
> >
> > On Fri, Oct 8, 2021 at 10:43 AM Takashi Iwai wrote:
> > > On Thu, 07 Oct 2021 18:51:58 +0200, Rich Felker wrote:
> > > > On Thu, Oct 07, 2021 at 06:18:52PM +0200, Takashi Iwai wrote:
> > >
> > > @@ -557,11 +558,15 @@ struct __snd_pcm_sync_ptr {
> > > #if defined(__BYTE_ORDER) ? __BYTE_ORDER == __BIG_ENDIAN :
> > > defined(__BIG_ENDIAN)
> > > typedef char __pad_before_uframe[sizeof(__u64) -
> > > sizeof(snd_pcm_uframes_t)];
> > > typedef char __pad_after_uframe[0];
> > > +typedef char __pad_before_u32[4];
> > > +typedef char __pad_after_u32[0];
> > > #endif
> > >
> > > #if defined(__BYTE_ORDER) ? __BYTE_ORDER == __LITTLE_ENDIAN :
> > > defined(__LITTLE_ENDIAN)
> > > typedef char __pad_before_uframe[0];
> > > typedef char __pad_after_uframe[sizeof(__u64) -
> > > sizeof(snd_pcm_uframes_t)];
> > > +typedef char __pad_before_u32[0];
> > > +typedef char __pad_after_u32[4];
> > > #endif
> >
> > I think these should remain unchanged, the complex expression was
> > intentionally
> > done so the structures are laid out the same way on 64-bit
> > architectures, so that
> > the kernel can use the __SND_STRUCT_TIME64 path internally on both 32-bit
> > and 64-bit architectures.
>
> That was explicitly defined, but OK, this isn't necessarily defined
> here.
>
> > > @@ -2970,8 +2981,17 @@ static int snd_pcm_sync_ptr(struct
> > > snd_pcm_substream *substream,
> > > memset(&sync_ptr, 0, sizeof(sync_ptr));
> > > if (get_user(sync_ptr.flags, (unsigned __user
> > > *)&(_sync_ptr->flags)))
> > > return -EFAULT;
> > > - if (copy_from_user(&sync_ptr.c.control, &(_sync_ptr->c.control),
> > > sizeof(struct snd_pcm_mmap_control)))
> > > - return -EFAULT;
> > > + if (buggy_control) {
> > > + if (copy_from_user(&sync_ptr.c.control_api_2_0_15,
> > > + &(_sync_ptr->c.control_api_2_0_15),
> > > + sizeof(sync_ptr.c.control_api_2_0_15)))
> > > + return -EFAULT;
> > > + } else {
> > > + if (copy_from_user(&sync_ptr.c.control,
> > > + &(_sync_ptr->c.control),
> > > + sizeof(sync_ptr.c.control)))
> > > + return -EFAULT;
> > > + }
> >
> > The problem I see with this is that it might break musl's ability to
> > emulate the new
> > interface on top of the old (time32) one for linux-4.x and older
> > kernels, as the conversion
> > function is no longer stateless but has to know the negotiated
> > interface version.
> >
> > It's probably fine as long as we can be sure that the 2.0.16+ API
> > version only gets
> > negotiated if both the kernel and user sides support it, and musl only
> > emulates
> > the 2.0.15 API version from the current kernels.
> >
> > I've tried to understand this part of musl's convert_ioctl_struct(), but I
> > just
> > can't figure out whether it does the conversion based the on the layout that
> > is currently used in the kernel, or based on the layout we should have been
> > using, and would use with the above fix. Rich, can you help me here?
>
> So, at this moment, I'm not sure whether we should correct the struct
> at all. This will lead to yet more breakage, and basically the struct
> itself *works* -- the only bug is in 32bit compat handling in the
> kernel (again).
>
> The below is a revised kernel patch (again untested), just correcting
> the behavior of 32bit compat mode. 32bit apps on 32bit kernel work
> fine as is, as well as 64bit apps on 64bit kernel.
I'm perfectly okay with this if Arnd is! It's probably the least
invasive and has the least long-term maintenance cost and fallout on
other projects.
Rich
___
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
On Fri, Oct 08, 2021 at 11:24:39AM +0200, Arnd Bergmann wrote:
> On Fri, Oct 8, 2021 at 10:43 AM Takashi Iwai wrote:
> > On Thu, 07 Oct 2021 18:51:58 +0200, Rich Felker wrote:
> > > On Thu, Oct 07, 2021 at 06:18:52PM +0200, Takashi Iwai wrote:
> >
> > @@ -557,11 +558,15 @@ struct __snd_pcm_sync_ptr {
> > #if defined(__BYTE_ORDER) ? __BYTE_ORDER == __BIG_ENDIAN :
> > defined(__BIG_ENDIAN)
> > typedef char __pad_before_uframe[sizeof(__u64) -
> > sizeof(snd_pcm_uframes_t)];
> > typedef char __pad_after_uframe[0];
> > +typedef char __pad_before_u32[4];
> > +typedef char __pad_after_u32[0];
> > #endif
> >
> > #if defined(__BYTE_ORDER) ? __BYTE_ORDER == __LITTLE_ENDIAN :
> > defined(__LITTLE_ENDIAN)
> > typedef char __pad_before_uframe[0];
> > typedef char __pad_after_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> > +typedef char __pad_before_u32[0];
> > +typedef char __pad_after_u32[4];
> > #endif
>
> I think these should remain unchanged, the complex expression was
> intentionally
> done so the structures are laid out the same way on 64-bit
> architectures, so that
> the kernel can use the __SND_STRUCT_TIME64 path internally on both 32-bit
> and 64-bit architectures.
>
> > @@ -2970,8 +2981,17 @@ static int snd_pcm_sync_ptr(struct snd_pcm_substream
> > *substream,
> > memset(&sync_ptr, 0, sizeof(sync_ptr));
> > if (get_user(sync_ptr.flags, (unsigned __user
> > *)&(_sync_ptr->flags)))
> > return -EFAULT;
> > - if (copy_from_user(&sync_ptr.c.control, &(_sync_ptr->c.control),
> > sizeof(struct snd_pcm_mmap_control)))
> > - return -EFAULT;
> > + if (buggy_control) {
> > + if (copy_from_user(&sync_ptr.c.control_api_2_0_15,
> > + &(_sync_ptr->c.control_api_2_0_15),
> > + sizeof(sync_ptr.c.control_api_2_0_15)))
> > + return -EFAULT;
> > + } else {
> > + if (copy_from_user(&sync_ptr.c.control,
> > + &(_sync_ptr->c.control),
> > + sizeof(sync_ptr.c.control)))
> > + return -EFAULT;
> > + }
>
> The problem I see with this is that it might break musl's ability to
> emulate the new
> interface on top of the old (time32) one for linux-4.x and older
> kernels, as the conversion
> function is no longer stateless but has to know the negotiated
> interface version.
>
> It's probably fine as long as we can be sure that the 2.0.16+ API
> version only gets
> negotiated if both the kernel and user sides support it, and musl only
> emulates
> the 2.0.15 API version from the current kernels.
>
> I've tried to understand this part of musl's convert_ioctl_struct(), but I
> just
> can't figure out whether it does the conversion based the on the layout that
> is currently used in the kernel, or based on the layout we should have been
> using, and would use with the above fix. Rich, can you help me here?
If the attempted 64-bit ioctl is missing (ENOTTY), it does the
conversion to the legacy 32-bit one and retries with that, then
converts the results back to the 64-bit form.
Not only do I fail to see how the proposed fix is workable with this
framework; I also don't see how the proposed fix would let new
applications (compiled without the buggy type) run on old kernels. I'm
pretty sure there really should be a new ioctl number for this...
Rich
___
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
On Fri, 08 Oct 2021 13:45:45 +0200, Arnd Bergmann wrote: > > On Fri, Oct 8, 2021 at 1:11 PM Takashi Iwai wrote: > > On Fri, 08 Oct 2021 11:24:39 +0200, Arnd Bergmann wrote: > > > > > > > I've tried to understand this part of musl's convert_ioctl_struct(), but > > > I just > > > can't figure out whether it does the conversion based the on the layout > > > that > > > is currently used in the kernel, or based on the layout we should have > > > been > > > using, and would use with the above fix. Rich, can you help me here? > > > > So, at this moment, I'm not sure whether we should correct the struct > > at all. This will lead to yet more breakage, and basically the struct > > itself *works* -- the only bug is in 32bit compat handling in the > > kernel (again). > > I'm still unsure if the musl fallback code is correct or not. We need to verify the current behavior in anyway... > > The below is a revised kernel patch (again untested), just correcting > > the behavior of 32bit compat mode. 32bit apps on 32bit kernel work > > fine as is, as well as 64bit apps on 64bit kernel. > > Right, this should cover all cases of the ioctl itself misbehaving. > In addition, we still need to disallow the mmap() interface on compat > kernels then. Strictly speaking, we could allow the snd_pcm_mmap_status > but not snd_pcm_mmap_control to be mapped, but I'm not sure if > that's better than disallowing both. IIRC, the compat mmap is already disallowed even for the SNDRV_PCM_MMAP_OFFSET_CONTROL_NEW (in pcm_control_mmap_allowed()), so no need to change around that. thanks, Takashi ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
On Fri, Oct 8, 2021 at 1:11 PM Takashi Iwai wrote: > On Fri, 08 Oct 2021 11:24:39 +0200, Arnd Bergmann wrote: > > > > I've tried to understand this part of musl's convert_ioctl_struct(), but I > > just > > can't figure out whether it does the conversion based the on the layout that > > is currently used in the kernel, or based on the layout we should have been > > using, and would use with the above fix. Rich, can you help me here? > > So, at this moment, I'm not sure whether we should correct the struct > at all. This will lead to yet more breakage, and basically the struct > itself *works* -- the only bug is in 32bit compat handling in the > kernel (again). I'm still unsure if the musl fallback code is correct or not. > The below is a revised kernel patch (again untested), just correcting > the behavior of 32bit compat mode. 32bit apps on 32bit kernel work > fine as is, as well as 64bit apps on 64bit kernel. Right, this should cover all cases of the ioctl itself misbehaving. In addition, we still need to disallow the mmap() interface on compat kernels then. Strictly speaking, we could allow the snd_pcm_mmap_status but not snd_pcm_mmap_control to be mapped, but I'm not sure if that's better than disallowing both. Arnd ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
On Fri, 08 Oct 2021 11:24:39 +0200,
Arnd Bergmann wrote:
>
> On Fri, Oct 8, 2021 at 10:43 AM Takashi Iwai wrote:
> > On Thu, 07 Oct 2021 18:51:58 +0200, Rich Felker wrote:
> > > On Thu, Oct 07, 2021 at 06:18:52PM +0200, Takashi Iwai wrote:
> >
> > @@ -557,11 +558,15 @@ struct __snd_pcm_sync_ptr {
> > #if defined(__BYTE_ORDER) ? __BYTE_ORDER == __BIG_ENDIAN :
> > defined(__BIG_ENDIAN)
> > typedef char __pad_before_uframe[sizeof(__u64) -
> > sizeof(snd_pcm_uframes_t)];
> > typedef char __pad_after_uframe[0];
> > +typedef char __pad_before_u32[4];
> > +typedef char __pad_after_u32[0];
> > #endif
> >
> > #if defined(__BYTE_ORDER) ? __BYTE_ORDER == __LITTLE_ENDIAN :
> > defined(__LITTLE_ENDIAN)
> > typedef char __pad_before_uframe[0];
> > typedef char __pad_after_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> > +typedef char __pad_before_u32[0];
> > +typedef char __pad_after_u32[4];
> > #endif
>
> I think these should remain unchanged, the complex expression was
> intentionally
> done so the structures are laid out the same way on 64-bit
> architectures, so that
> the kernel can use the __SND_STRUCT_TIME64 path internally on both 32-bit
> and 64-bit architectures.
That was explicitly defined, but OK, this isn't necessarily defined
here.
> > @@ -2970,8 +2981,17 @@ static int snd_pcm_sync_ptr(struct snd_pcm_substream
> > *substream,
> > memset(&sync_ptr, 0, sizeof(sync_ptr));
> > if (get_user(sync_ptr.flags, (unsigned __user
> > *)&(_sync_ptr->flags)))
> > return -EFAULT;
> > - if (copy_from_user(&sync_ptr.c.control, &(_sync_ptr->c.control),
> > sizeof(struct snd_pcm_mmap_control)))
> > - return -EFAULT;
> > + if (buggy_control) {
> > + if (copy_from_user(&sync_ptr.c.control_api_2_0_15,
> > + &(_sync_ptr->c.control_api_2_0_15),
> > + sizeof(sync_ptr.c.control_api_2_0_15)))
> > + return -EFAULT;
> > + } else {
> > + if (copy_from_user(&sync_ptr.c.control,
> > + &(_sync_ptr->c.control),
> > + sizeof(sync_ptr.c.control)))
> > + return -EFAULT;
> > + }
>
> The problem I see with this is that it might break musl's ability to
> emulate the new
> interface on top of the old (time32) one for linux-4.x and older
> kernels, as the conversion
> function is no longer stateless but has to know the negotiated
> interface version.
>
> It's probably fine as long as we can be sure that the 2.0.16+ API
> version only gets
> negotiated if both the kernel and user sides support it, and musl only
> emulates
> the 2.0.15 API version from the current kernels.
>
> I've tried to understand this part of musl's convert_ioctl_struct(), but I
> just
> can't figure out whether it does the conversion based the on the layout that
> is currently used in the kernel, or based on the layout we should have been
> using, and would use with the above fix. Rich, can you help me here?
So, at this moment, I'm not sure whether we should correct the struct
at all. This will lead to yet more breakage, and basically the struct
itself *works* -- the only bug is in 32bit compat handling in the
kernel (again).
The below is a revised kernel patch (again untested), just correcting
the behavior of 32bit compat mode. 32bit apps on 32bit kernel work
fine as is, as well as 64bit apps on 64bit kernel.
Takashi
--- a/sound/core/pcm_compat.c
+++ b/sound/core/pcm_compat.c
@@ -468,6 +468,75 @@ static int snd_pcm_ioctl_sync_ptr_x32(struct
snd_pcm_substream *substream,
}
#endif /* CONFIG_X86_X32 */
+#ifdef __BIG_ENDIAN
+typedef char __pad_before_u32[4];
+typedef char __pad_after_u32[0];
+#else
+typedef char __pad_before_u32[0];
+typedef char __pad_after_u32[4];
+#endif
+
+/* PCM 2.0.15 API definition had a bug in mmap control; it puts the avail_min
+ * at the wrong offset due to a typo in padding type, hitting only on 32bit.
+ * Workaround for incorrect read/write is needed only in 32bit compat mode.
+ */
+struct __snd_pcm_mmap_control64_buggy {
+ __pad_before_u32 __pad1;
+ __u32 appl_ptr;
+ __pad_before_u32 __pad2;/* SiC! here is the bug */
+ __pad_before_u32 __pad3;
+ __u32 avail_min;
+ __pad_after_uframe __pad4;
+};
+
+static int snd_pcm_ioctl_sync_ptr_buggy(struct snd_pcm_substream *substream,
+ struct snd_pcm_sync_ptr __user
*_sync_ptr)
+{
+ struct snd_pcm_runtime *runtime = substream->runtime;
+ struct snd_pcm_sync_ptr sync_ptr;
+ struct __snd_pcm_mmap_control64_buggy *sync_cp;
+ volatile struct snd_pcm_mmap_status *status;
+ volatile struct snd_pcm_mmap_control *control;
+ int err;
+
+ memset(&sync_ptr, 0, sizeof(sync_ptr));
+ sync_cp = (struct __snd_pcm_mmap_control64_buggy *)&sync_ptr.c.control;
+ if (get_user(sync_ptr.f
Re: [Y2038] [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
On Fri, Oct 8, 2021 at 10:43 AM Takashi Iwai wrote:
> On Thu, 07 Oct 2021 18:51:58 +0200, Rich Felker wrote:
> > On Thu, Oct 07, 2021 at 06:18:52PM +0200, Takashi Iwai wrote:
>
> @@ -557,11 +558,15 @@ struct __snd_pcm_sync_ptr {
> #if defined(__BYTE_ORDER) ? __BYTE_ORDER == __BIG_ENDIAN :
> defined(__BIG_ENDIAN)
> typedef char __pad_before_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> typedef char __pad_after_uframe[0];
> +typedef char __pad_before_u32[4];
> +typedef char __pad_after_u32[0];
> #endif
>
> #if defined(__BYTE_ORDER) ? __BYTE_ORDER == __LITTLE_ENDIAN :
> defined(__LITTLE_ENDIAN)
> typedef char __pad_before_uframe[0];
> typedef char __pad_after_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> +typedef char __pad_before_u32[0];
> +typedef char __pad_after_u32[4];
> #endif
I think these should remain unchanged, the complex expression was intentionally
done so the structures are laid out the same way on 64-bit
architectures, so that
the kernel can use the __SND_STRUCT_TIME64 path internally on both 32-bit
and 64-bit architectures.
> @@ -2970,8 +2981,17 @@ static int snd_pcm_sync_ptr(struct snd_pcm_substream
> *substream,
> memset(&sync_ptr, 0, sizeof(sync_ptr));
> if (get_user(sync_ptr.flags, (unsigned __user *)&(_sync_ptr->flags)))
> return -EFAULT;
> - if (copy_from_user(&sync_ptr.c.control, &(_sync_ptr->c.control),
> sizeof(struct snd_pcm_mmap_control)))
> - return -EFAULT;
> + if (buggy_control) {
> + if (copy_from_user(&sync_ptr.c.control_api_2_0_15,
> + &(_sync_ptr->c.control_api_2_0_15),
> + sizeof(sync_ptr.c.control_api_2_0_15)))
> + return -EFAULT;
> + } else {
> + if (copy_from_user(&sync_ptr.c.control,
> + &(_sync_ptr->c.control),
> + sizeof(sync_ptr.c.control)))
> + return -EFAULT;
> + }
The problem I see with this is that it might break musl's ability to
emulate the new
interface on top of the old (time32) one for linux-4.x and older
kernels, as the conversion
function is no longer stateless but has to know the negotiated
interface version.
It's probably fine as long as we can be sure that the 2.0.16+ API
version only gets
negotiated if both the kernel and user sides support it, and musl only emulates
the 2.0.15 API version from the current kernels.
I've tried to understand this part of musl's convert_ioctl_struct(), but I just
can't figure out whether it does the conversion based the on the layout that
is currently used in the kernel, or based on the layout we should have been
using, and would use with the above fix. Rich, can you help me here?
Arnd
___
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
On Fri, 08 Oct 2021 10:43:24 +0200, Takashi Iwai wrote: > > On Thu, 07 Oct 2021 18:51:58 +0200, > Rich Felker wrote: > > > > On Thu, Oct 07, 2021 at 06:18:52PM +0200, Takashi Iwai wrote: > > > On Thu, 07 Oct 2021 18:06:36 +0200, > > > Rich Felker wrote: > > > > > > > > On Thu, Oct 07, 2021 at 05:33:19PM +0200, Takashi Iwai wrote: > > > > > On Thu, 07 Oct 2021 15:11:00 +0200, > > > > > Arnd Bergmann wrote: > > > > > > > > > > > > On Thu, Oct 7, 2021 at 2:43 PM Takashi Iwai wrote: > > > > > > > On Thu, 07 Oct 2021 13:48:44 +0200, Arnd Bergmann wrote: > > > > > > > > On Thu, Oct 7, 2021 at 12:53 PM Takashi Iwai > > > > > > > > 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. > > > > > > > > > > Thanks! > > > > > > > > > > And now, looking more deeply, I feel more desperate. > > > > > > > > > > This bug makes the expected padding gone on little-endian. > > > > > On LE 32bit, the buggy definition is: > > > > > > > > > > char __pad1[0]; > > > > > u32 appl_ptr; > > > > > char __pad2[0]; // this should have been [4] > > > > >
Re: [Y2038] [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
On Thu, 07 Oct 2021 18:51:58 +0200, Rich Felker wrote: > > On Thu, Oct 07, 2021 at 06:18:52PM +0200, Takashi Iwai wrote: > > On Thu, 07 Oct 2021 18:06:36 +0200, > > Rich Felker wrote: > > > > > > On Thu, Oct 07, 2021 at 05:33:19PM +0200, Takashi Iwai wrote: > > > > On Thu, 07 Oct 2021 15:11:00 +0200, > > > > Arnd Bergmann wrote: > > > > > > > > > > On Thu, Oct 7, 2021 at 2:43 PM Takashi Iwai wrote: > > > > > > On Thu, 07 Oct 2021 13:48:44 +0200, Arnd Bergmann wrote: > > > > > > > On Thu, Oct 7, 2021 at 12:53 PM Takashi Iwai > > > > > > > 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. > > > > > > > > Thanks! > > > > > > > > And now, looking more deeply, I feel more desperate. > > > > > > > > This bug makes the expected padding gone on little-endian. > > > > On LE 32bit, the buggy definition is: > > > > > > > > char __pad1[0]; > > > > u32 appl_ptr; > > > > char __pad2[0]; // this should have been [4] > > > > char __pad3[0]; > > > > u32 avail_min; > > > > char __pad4[4]; > > > > > > > > When an application issues SYNC_PTR64 ioctl to submit appl_ptr and > > > > avail_min updates, 64bit kernel (in compat mode) reads directly as: > > > > > > > > u64 appl_ptr; > > > > u64 avail_min; > > > > > > > > Hence a bogus appl_ptr would
Re: [Y2038] [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
On Thu, Oct 07, 2021 at 06:18:52PM +0200, Takashi Iwai wrote: > On Thu, 07 Oct 2021 18:06:36 +0200, > Rich Felker wrote: > > > > On Thu, Oct 07, 2021 at 05:33:19PM +0200, Takashi Iwai wrote: > > > On Thu, 07 Oct 2021 15:11:00 +0200, > > > Arnd Bergmann wrote: > > > > > > > > On Thu, Oct 7, 2021 at 2:43 PM Takashi Iwai wrote: > > > > > On Thu, 07 Oct 2021 13:48:44 +0200, Arnd Bergmann wrote: > > > > > > On Thu, Oct 7, 2021 at 12:53 PM Takashi Iwai 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. > > > > > > Thanks! > > > > > > And now, looking more deeply, I feel more desperate. > > > > > > This bug makes the expected padding gone on little-endian. > > > On LE 32bit, the buggy definition is: > > > > > > char __pad1[0]; > > > u32 appl_ptr; > > > char __pad2[0]; // this should have been [4] > > > char __pad3[0]; > > > u32 avail_min; > > > char __pad4[4]; > > > > > > When an application issues SYNC_PTR64 ioctl to submit appl_ptr and > > > avail_min updates, 64bit kernel (in compat mode) reads directly as: > > > > > > u64 appl_ptr; > > > u64 avail_min; > > > > > > Hence a bogus appl_ptr would be passed if avail_min != 0. > > > And usually application sets non-zero avail_min. > > > That is, the bug must hit more severely if the new API were really > > > used. It wouldn't crash, but some weird streaming behavior can > > > happen like noise, jumping or underruns. > > > > > > (Reading back avail_min=0 to user-space is rather harmless. Ditto for > > > the case of BE, then at least there is no appl_ptr corru
Re: [Y2038] [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
On Thu, 07 Oct 2021 18:06:36 +0200, Rich Felker wrote: > > On Thu, Oct 07, 2021 at 05:33:19PM +0200, Takashi Iwai wrote: > > On Thu, 07 Oct 2021 15:11:00 +0200, > > Arnd Bergmann wrote: > > > > > > On Thu, Oct 7, 2021 at 2:43 PM Takashi Iwai wrote: > > > > On Thu, 07 Oct 2021 13:48:44 +0200, Arnd Bergmann wrote: > > > > > On Thu, Oct 7, 2021 at 12:53 PM Takashi Iwai 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. > > > > Thanks! > > > > And now, looking more deeply, I feel more desperate. > > > > This bug makes the expected padding gone on little-endian. > > On LE 32bit, the buggy definition is: > > > > char __pad1[0]; > > u32 appl_ptr; > > char __pad2[0]; // this should have been [4] > > char __pad3[0]; > > u32 avail_min; > > char __pad4[4]; > > > > When an application issues SYNC_PTR64 ioctl to submit appl_ptr and > > avail_min updates, 64bit kernel (in compat mode) reads directly as: > > > > u64 appl_ptr; > > u64 avail_min; > > > > Hence a bogus appl_ptr would be passed if avail_min != 0. > > And usually application sets non-zero avail_min. > > That is, the bug must hit more severely if the new API were really > > used. It wouldn't crash, but some weird streaming behavior can > > happen like noise, jumping or underruns. > > > > (Reading back avail_min=0 to user-space is rather harmless. Ditto for > > the case of BE, then at least there is no appl_ptr corruption.) > > > > This made me wonder which way to go: > > it's certainly possible to fix the new kernel to treat both buggy and > > sane formats (disabling compat mmap and re-define ioctls, having the > > code for old APIs). The problem is, howe
Re: [Y2038] [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
On Thu, Oct 07, 2021 at 05:33:19PM +0200, Takashi Iwai wrote: > On Thu, 07 Oct 2021 15:11:00 +0200, > Arnd Bergmann wrote: > > > > On Thu, Oct 7, 2021 at 2:43 PM Takashi Iwai wrote: > > > On Thu, 07 Oct 2021 13:48:44 +0200, Arnd Bergmann wrote: > > > > On Thu, Oct 7, 2021 at 12:53 PM Takashi Iwai 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. > > Thanks! > > And now, looking more deeply, I feel more desperate. > > This bug makes the expected padding gone on little-endian. > On LE 32bit, the buggy definition is: > > char __pad1[0]; > u32 appl_ptr; > char __pad2[0]; // this should have been [4] > char __pad3[0]; > u32 avail_min; > char __pad4[4]; > > When an application issues SYNC_PTR64 ioctl to submit appl_ptr and > avail_min updates, 64bit kernel (in compat mode) reads directly as: > > u64 appl_ptr; > u64 avail_min; > > Hence a bogus appl_ptr would be passed if avail_min != 0. > And usually application sets non-zero avail_min. > That is, the bug must hit more severely if the new API were really > used. It wouldn't crash, but some weird streaming behavior can > happen like noise, jumping or underruns. > > (Reading back avail_min=0 to user-space is rather harmless. Ditto for > the case of BE, then at least there is no appl_ptr corruption.) > > This made me wonder which way to go: > it's certainly possible to fix the new kernel to treat both buggy and > sane formats (disabling compat mmap and re-define ioctls, having the > code for old APIs). The problem is, however, in the case where the > application needs to run on the older kernel that expects the buggy > format. Then apps would still have to send in the old buggy format -- > or maybe better in the older 32bit format that won't hit the bug > above.
