Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <s5hv9277oux.wl-tiwai@suse.de>
Date: Fri, 08 Oct 2021 13:11:34 +0200
From: Takashi Iwai <tiwai@...e.de>
To: Arnd Bergmann <arnd@...db.de>
Cc: musl@...ts.openwall.com,
	Rich Felker <dalias@...c.org>,
	Michael Forney <mforney@...rney.org>,
	ALSA Development Mailing List <alsa-devel@...a-project.org>,
	Takashi Iwai <tiwai@...e.com>,
	Baolin Wang <baolin.wang@...aro.org>,
	y2038 Mailman List <y2038@...ts.linaro.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Mark Brown <broonie@...nel.org>,
	Baolin Wang <baolin.wang7@...il.com>
Subject: Re: 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 <tiwai@...e.de> 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.flags, (unsigned __user *)&(_sync_ptr->flags)))
+		return -EFAULT;
+	if (copy_from_user(sync_cp, &(_sync_ptr->c.control), sizeof(*sync_cp)))
+		return -EFAULT;
+	status = runtime->status;
+	control = runtime->control;
+	if (sync_ptr.flags & SNDRV_PCM_SYNC_PTR_HWSYNC) {
+		err = snd_pcm_hwsync(substream);
+		if (err < 0)
+			return err;
+	}
+	snd_pcm_stream_lock_irq(substream);
+	if (!(sync_ptr.flags & SNDRV_PCM_SYNC_PTR_APPL)) {
+		err = pcm_lib_apply_appl_ptr(substream, sync_cp->appl_ptr);
+		if (err < 0) {
+			snd_pcm_stream_unlock_irq(substream);
+			return err;
+		}
+	} else {
+		sync_cp->appl_ptr = control->appl_ptr;
+	}
+	if (!(sync_ptr.flags & SNDRV_PCM_SYNC_PTR_AVAIL_MIN))
+		control->avail_min = sync_cp->avail_min;
+	else
+		sync_cp->avail_min = control->avail_min;
+	sync_ptr.s.status.state = status->state;
+	sync_ptr.s.status.hw_ptr = status->hw_ptr;
+	sync_ptr.s.status.tstamp = status->tstamp;
+	sync_ptr.s.status.suspended_state = status->suspended_state;
+	sync_ptr.s.status.audio_tstamp = status->audio_tstamp;
+	snd_pcm_stream_unlock_irq(substream);
+	if (copy_to_user(_sync_ptr, &sync_ptr, sizeof(sync_ptr)))
+		return -EFAULT;
+	return 0;
+}
+
 /*
  */
 enum {
@@ -537,7 +606,7 @@ static long snd_pcm_ioctl_compat(struct file *file, unsigned int cmd, unsigned l
 		if (in_x32_syscall())
 			return snd_pcm_ioctl_sync_ptr_x32(substream, argp);
 #endif /* CONFIG_X86_X32 */
-		return snd_pcm_common_ioctl(file, substream, cmd, argp);
+		return snd_pcm_ioctl_sync_ptr_buggy(substream, argp);
 	case SNDRV_PCM_IOCTL_HW_REFINE32:
 		return snd_pcm_ioctl_hw_params_compat(substream, 1, argp);
 	case SNDRV_PCM_IOCTL_HW_PARAMS32:

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.