lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Thu, 30 Oct 2014 21:29:17 +0000
From:	Hartley Sweeten <HartleyS@...ionengravers.com>
To:	Ian Abbott <abbotti@....co.uk>,
	"driverdev-devel@...uxdriverproject.org" 
	<driverdev-devel@...uxdriverproject.org>
CC:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 0/7] staging: comedi: enforce data transfer direction

On Thursday, October 30, 2014 5:42 AM, Ian Abbott wrote:
> Most comedi subdevices that support asynchronous data acquisition
> commands only support data transfer in a single direction, as indicated
> by the `SDF_CMD_READ` and `SDF_CMD_WRITE` subdevice flags.  A few allow
> data transfer in either direction, but only a single direction at a
> time, as indicated by the `CMDF_WRITE` command flag in the `flags`
> member of the `struct comedi_cmd` from user-space used to set up the
> asynchronous command.  The `CMDF_WRITE` flag isn't commonly set for
> "write" commands if that is the only direction the subdevice supports.
>
> Since it would be useful for comedi to have a clear indication of which
> data transfer direction is being used, patch 1 forces the `CMDF_WRITE`
> command flag to the correct state if only one direction is supported.
> The flag can then be checked by comedi in the subdevice's local copy of
> the current command (in `s->async->cmd`) to determine the data transfer
> direction unambiguously.
>
> Patch 2 stops the "me4000" driver clobbering the command flags.
>
> Patch 3 removes some now redundant modification of the `CMDF_WRITE` flag
> in "ni_mio_common.c" (used by the "ni_pcimio", "ni_atmio" and
> "ni_mio_cs" drivers).
>
> Patches 4 and 5 disallow the read() and write() file operations if the
> subdevice has been set up with a command in the "write" or "read" data
> transfer direction respectively.
>
> Patch 6 changes the readable/writeable checks for the poll() file
> operation.  It already considers the file readable/writeable if
> read()/write() would fail with an error, so change it to check for
> "wrong direction" as one of the possible failures.
>
> Patch 7 makes the direction test in the handling of the `COMEDI_BUFINFO`
> ioctl (used to update buffer positions for mmapped buffers) less
> ambiguous.  The current test used the `SDF_CMD_READ` and `SDF_CMD_WRITE`
> subdevice flags to check the direction, which is ambiguous if both flags
> are set.  Update it to use the `CMDF_WRITE` command flag instead.

Reviewed-by: H Hartley Sweeten <hsweeten@...ionengravers.com>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ