linux-kernel - Re: [PATCH 2/2] fsi: sbefifo: implement FSI_SBEFIFO_READ

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] [thread-next>] [day] [month] [year] [list]

Message-Id: <6db73ea9-96e8-42cd-97a5-0667de8d0097@www.fastmail.com>
Date:   Wed, 15 Dec 2021 16:13:10 +1030
From:   "Andrew Jeffery" <andrew@...id.au>
To:     "Amitay Isaacs" <amitay@...abs.org>, linux-kernel@...r.kernel.org,
        linux-fsi@...ts.ozlabs.org, "Jeremy Kerr" <jk@...abs.org>,
        "Joel Stanley" <joel@....id.au>,
        "Alistair Popple" <alistair@...ple.id.au>,
        "Eddie James" <eajames@...ux.ibm.com>
Subject: Re: [PATCH 2/2] fsi: sbefifo: implement FSI_SBEFIFO_READ_TIMEOUT ioctl

Hi Amitay,

On Wed, 15 Dec 2021, at 11:28, Amitay Isaacs wrote:
> FSI_SBEFIFO_READ_TIMEOUT ioctl sets the read timeout (in seconds) for
> the response to *the next* chip-op sent to sbe.  The timeout value is
> reset to default after the chip-op.

For the user? Why reset it automatically? To avoid unexpected surprises 
in existing code?

>  The timeout affects only the read()
> operation on sbefifo device fd.
>
> Signed-off-by: Amitay Isaacs <amitay@...abs.org>
> ---
>  drivers/fsi/fsi-sbefifo.c | 42 +++++++++++++++++++++++++++++++++++++++
>  include/uapi/linux/fsi.h  |  6 ++++++
>  2 files changed, 48 insertions(+)
>
> diff --git a/drivers/fsi/fsi-sbefifo.c b/drivers/fsi/fsi-sbefifo.c
> index 9188161f440c..b2654b143b85 100644
> --- a/drivers/fsi/fsi-sbefifo.c
> +++ b/drivers/fsi/fsi-sbefifo.c
> @@ -32,6 +32,8 @@
>  #include <linux/vmalloc.h>
>  #include <linux/mm.h>
> 
> +#include <uapi/linux/fsi.h>
> +
>  /*
>   * The SBEFIFO is a pipe-like FSI device for communicating with
>   * the self boot engine on POWER processors.
> @@ -134,6 +136,7 @@ struct sbefifo_user {
>  	void			*cmd_page;
>  	void			*pending_cmd;
>  	size_t			pending_len;
> +	uint32_t		read_timeout_ms;
>  };
> 
>  static DEFINE_MUTEX(sbefifo_ffdc_mutex);
> @@ -796,6 +799,7 @@ static int sbefifo_user_open(struct inode *inode, 
> struct file *file)
>  		return -ENOMEM;
>  	}
>  	mutex_init(&user->file_lock);
> +	user->read_timeout_ms = SBEFIFO_TIMEOUT_START_RSP;
> 
>  	return 0;
>  }
> @@ -838,7 +842,11 @@ static ssize_t sbefifo_user_read(struct file 
> *file, char __user *buf,
>  	rc = mutex_lock_interruptible(&sbefifo->lock);
>  	if (rc)
>  		goto bail;
> +	sbefifo->timeout_start_rsp_ms = user->read_timeout_ms;
>  	rc = __sbefifo_submit(sbefifo, user->pending_cmd, cmd_len, 
> &resp_iter);
> +	/* Reset the read timeout after a single chip-op */
> +	sbefifo->timeout_start_rsp_ms = SBEFIFO_TIMEOUT_START_RSP;
> +	user->read_timeout_ms = SBEFIFO_TIMEOUT_START_RSP;

I guess I was querying this one

>  	mutex_unlock(&sbefifo->lock);
>  	if (rc < 0)
>  		goto bail;
> @@ -847,6 +855,7 @@ static ssize_t sbefifo_user_read(struct file *file, 
> char __user *buf,
>  	rc = len - iov_iter_count(&resp_iter);
>   bail:
>  	sbefifo_release_command(user);
> +	user->read_timeout_ms = 0;
>  	mutex_unlock(&user->file_lock);
>  	return rc;
>  }
> @@ -928,12 +937,45 @@ static int sbefifo_user_release(struct inode 
> *inode, struct file *file)
>  	return 0;
>  }
> 
> +static int sbefifo_read_timeout(struct sbefifo_user *user, void __user 
> **argp)
> +{
> +	uint32_t timeout;
> +
> +	if (get_user(timeout, (__u32 __user *)argp))

Hmm

> +		return -EFAULT;
> +	if (timeout < 10 || timeout > 120)
> +		return -EINVAL;
> +
> +	user->read_timeout_ms = timeout * 1000; /* user timeout is in sec */
> +	return 0;
> +}
> +
> +static long sbefifo_user_ioctl(struct file *file, unsigned int cmd, 
> unsigned long arg)
> +{
> +	struct sbefifo_user *user = file->private_data;
> +	void __user **argp = (void __user *)arg;

Why are we doing strange things with the pointer types?

Andrew

> +	int rc = -ENOTTY;
> +
> +	if (!user)
> +		return -EINVAL;
> +
> +	mutex_lock(&user->file_lock);
> +	switch (cmd) {
> +	case FSI_SBEFIFO_READ_TIMEOUT:
> +		rc = sbefifo_read_timeout(user, argp);
> +		break;
> +	}
> +	mutex_unlock(&user->file_lock);
> +	return rc;
> +}
> +
>  static const struct file_operations sbefifo_fops = {
>  	.owner		= THIS_MODULE,
>  	.open		= sbefifo_user_open,
>  	.read		= sbefifo_user_read,
>  	.write		= sbefifo_user_write,
>  	.release	= sbefifo_user_release,
> +	.unlocked_ioctl = sbefifo_user_ioctl,
>  };
> 
>  static void sbefifo_free(struct device *dev)
> diff --git a/include/uapi/linux/fsi.h b/include/uapi/linux/fsi.h
> index da577ecd90e7..3e00874ace22 100644
> --- a/include/uapi/linux/fsi.h
> +++ b/include/uapi/linux/fsi.h
> @@ -55,4 +55,10 @@ struct scom_access {
>  #define FSI_SCOM_WRITE	_IOWR('s', 0x02, struct scom_access)
>  #define FSI_SCOM_RESET	_IOW('s', 0x03, __u32)
> 
> +/*
> + * /dev/sbefifo* ioctl interface
> + */
> +
> +#define FSI_SBEFIFO_READ_TIMEOUT	_IOW('s', 0x00, __u32)
> +
>  #endif /* _UAPI_LINUX_FSI_H */
> -- 
> 2.33.1