Re: [PATCH v2 1/2] mmc: Add ioctl to let userspace apps send ACMDs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2011/4/5 John Calixto <john.calixto@xxxxxxxxxxxxxx>:
> Sending ACMDs from userspace is useful for such things as:
>
> Â Â- The security application of an SD card (SD Specification, Part 3,
> Â Â ÂSecurity)
>
> Â Â- SD passthrough for virtual machines
>
> Tested on TI PCIxx12 (SDHCI), Sigma Designs SMP8652 SoC, TI OMAP3621
> SoC, TI OMAP3630 SoC, Samsung S5PC110 SoC, Qualcomm MSM7200A SoC.
>
> Signed-off-by: John Calixto <john.calixto@xxxxxxxxxxxxxx>
> ---
> Âdrivers/mmc/card/block.c Â| Â191 +++++++++++++++++++++++++++++++++++++++++++++
> Âdrivers/mmc/core/sd_ops.c | Â Â3 +-
> Âinclude/linux/mmc/core.h Â| Â Â1 +
> Âinclude/linux/mmc/sd.h  Â|  16 ++++
> Â4 files changed, 210 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
> index 61d233a..c2e107c 100644
> --- a/drivers/mmc/card/block.c
> +++ b/drivers/mmc/card/block.c
> @@ -31,6 +31,8 @@
> Â#include <linux/mutex.h>
> Â#include <linux/scatterlist.h>
> Â#include <linux/string_helpers.h>
> +#include <linux/compat.h>
> +#include <linux/delay.h>
>
> Â#include <linux/mmc/card.h>
> Â#include <linux/mmc/host.h>
> @@ -158,11 +160,200 @@ mmc_blk_getgeo(struct block_device *bdev, struct hd_geometry *geo)
> Â Â Â Âreturn 0;
> Â}
>
> +static int mmc_blk_ioctl_acmd(struct block_device *bdev,
> + Â Â Â struct sd_ioc_cmd __user *sdic_ptr)
> +{
> + Â Â Â struct sd_ioc_cmd sdic;
> + Â Â Â struct mmc_blk_data *md;
> + Â Â Â struct mmc_host *host;
> + Â Â Â struct mmc_card *card;
> + Â Â Â struct mmc_command cmd = {0};
> + Â Â Â struct mmc_data data = {0};
> + Â Â Â struct mmc_request mrq = {0};
> + Â Â Â struct scatterlist sg = {0};
> + Â Â Â unsigned char *blocks = NULL;
> + Â Â Â size_t data_bytes;
> + Â Â Â int err;
> +
> + Â Â Â /*
> + Â Â Â Â* Only allow ACMDs on the whole block device, not on partitions. ÂThis
> + Â Â Â Â* prevents overspray between sibling partitions.
> + Â Â Â Â*/
> + Â Â Â if (bdev != bdev->bd_contains)
> + Â Â Â Â Â Â Â return -EPERM;

This should at least also check CAP_SYS_ADMIN capability.

> +
> + Â Â Â md = mmc_blk_get(bdev->bd_disk);
> + Â Â Â if (!md)
> + Â Â Â Â Â Â Â return -EINVAL;
> +
> + Â Â Â card = md->queue.card;
> + Â Â Â if (IS_ERR(card))
> + Â Â Â Â Â Â Â return PTR_ERR(card);
> +
> + Â Â Â host = card->host;
> + Â Â Â mmc_claim_host(host);
> +
> + Â Â Â err = mmc_app_cmd(host, card);
> + Â Â Â if (err)
> + Â Â Â Â Â Â Â goto acmd_done;
> +
> + Â Â Â mrq.cmd = &cmd;
> + Â Â Â mrq.data = &data;
> +
> + Â Â Â if (copy_from_user(&sdic, sdic_ptr, sizeof(sdic))) {
> + Â Â Â Â Â Â Â err = -EFAULT;
> + Â Â Â Â Â Â Â goto acmd_done;
> + Â Â Â }

You should first copy and verify ioctl's data and only then claim host
and send commands. Preferably the check-and-copy should be separate
function.

> +
> + Â Â Â cmd.opcode = sdic.opcode;
> + Â Â Â cmd.arg = sdic.arg;
> + Â Â Â cmd.flags = sdic.flags;
> +
> + Â Â Â data.sg = &sg;
> + Â Â Â data.sg_len = 1;
> + Â Â Â data.blksz = sdic.blksz;
> + Â Â Â data.blocks = sdic.blocks;
> +
> + Â Â Â data_bytes = data.blksz * data.blocks;
> + Â Â Â blocks = kzalloc(data_bytes, GFP_KERNEL);
> + Â Â Â if (!blocks) {
> + Â Â Â Â Â Â Â err = -ENOMEM;
> + Â Â Â Â Â Â Â goto acmd_done;
> + Â Â Â }
> + Â Â Â sg_init_one(data.sg, blocks, data_bytes);
> +
> +
> + Â Â Â if (copy_from_user(blocks, sdic_ptr->data_ptr, data_bytes)) {
> + Â Â Â Â Â Â Â err = -EFAULT;
> + Â Â Â Â Â Â Â goto acmd_done;
> + Â Â Â }
> + Â Â Â if (sdic.write_flag)
> + Â Â Â Â Â Â Â data.flags = MMC_DATA_WRITE;
> + Â Â Â else
> + Â Â Â Â Â Â Â data.flags = MMC_DATA_READ;
> +
> + Â Â Â /* data.flags must already be set before doing this. */
> + Â Â Â mmc_set_data_timeout(&data, card);
> + Â Â Â /* Allow overriding the timeout_ns for empirical tuning. */
> + Â Â Â if (sdic.force_timeout_ns)
> + Â Â Â Â Â Â Â data.timeout_ns = sdic.force_timeout_ns;
> +
> + Â Â Â mmc_wait_for_req(host, &mrq);
> +
> + Â Â Â if (cmd.error) {
> + Â Â Â Â Â Â Â dev_err(mmc_dev(host), "%s: cmd error %d\n",
> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â __func__, cmd.error);
> + Â Â Â Â Â Â Â err = cmd.error;
> + Â Â Â Â Â Â Â goto acmd_done;
> + Â Â Â }
> + Â Â Â if (data.error) {
> + Â Â Â Â Â Â Â dev_err(mmc_dev(host), "%s: data error %d\n",
> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â __func__, data.error);
> + Â Â Â Â Â Â Â err = data.error;
> + Â Â Â Â Â Â Â goto acmd_done;
> + Â Â Â }
> +
> + Â Â Â /*
> + Â Â Â Â* According to the SD specs, some commands require a delay after
> + Â Â Â Â* issuing the command.
> + Â Â Â Â*/
> + Â Â Â if (sdic.postsleep_us)
> + Â Â Â Â Â Â Â udelay(sdic.postsleep_us);
> +
> + Â Â Â if (copy_to_user(&(sdic_ptr->response), cmd.resp, sizeof(cmd.resp))) {
> + Â Â Â Â Â Â Â err = -EFAULT;
> + Â Â Â Â Â Â Â goto acmd_done;
> + Â Â Â }
> +
> + Â Â Â if (!sdic.write_flag) {
> + Â Â Â Â Â Â Â if (copy_to_user(sdic_ptr->data_ptr, blocks, data_bytes)) {
> + Â Â Â Â Â Â Â Â Â Â Â err = -EFAULT;
> + Â Â Â Â Â Â Â Â Â Â Â goto acmd_done;
> + Â Â Â Â Â Â Â }
> + Â Â Â }
> +
> +acmd_done:
> + Â Â Â kfree(blocks);
> + Â Â Â mmc_release_host(host);
> + Â Â Â mmc_blk_put(md);
> + Â Â Â return err;
> +}
> +
> +static int mmc_blk_ioctl(struct block_device *bdev, fmode_t mode,
> + Â Â Â unsigned int cmd, unsigned long arg)
> +{
> + Â Â Â int ret = -EINVAL;
> + Â Â Â mutex_lock(&block_mutex);
> + Â Â Â if (cmd == SD_IOC_ACMD)
> + Â Â Â Â Â Â Â ret = mmc_blk_ioctl_acmd(bdev, (struct sd_ioc_cmd __user *)arg);
> + Â Â Â mutex_unlock(&block_mutex);
> + Â Â Â return ret;
> +}
> +
> +#ifdef CONFIG_COMPAT
> +struct sd_ioc_cmd32 {
> + Â Â Â u32 write_flag;
> + Â Â Â u32 opcode;
> + Â Â Â u32 arg;
> + Â Â Â u32 response[4];
> + Â Â Â u32 flags;
> + Â Â Â u32 blksz;
> + Â Â Â u32 blocks;
> + Â Â Â u32 postsleep_us;
> + Â Â Â u32 force_timeout_ns;
> + Â Â Â compat_uptr_t data_ptr;
> +};
> +#define SD_IOC_ACMD32 _IOWR(MMC_BLOCK_MAJOR, 0, struct sd_ioc_cmd32)
[...]

Since your implementing a new ioctl you can make the structure the
same for 64 and 32-bit archs and avoid all this compat crap.

Best Regards,
MichaÅ MirosÅaw
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux