linux-kernel - Re: [PATCH 1/4] firmware: add firmware signing

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:   Tue, 30 May 2017 17:07:17 +0100
From:   Alan Cox <alan@...ux.intel.com>
To:     AKASHI Takahiro <takahiro.akashi@...aro.org>, mcgrof@...nel.org
Cc:     rusty@...tcorp.com.au, dhowells@...hat.com, ming.lei@...onical.com,
        seth.forshee@...onical.com, kyle@...nel.org,
        David.Woodhouse@...el.com, linux-kernel@...r.kernel.org,
        "Luis R . Rodriguez" <mcgrof@...e.com>
Subject: Re: [PATCH 1/4] firmware: add firmware signing

On Fri, 2017-05-26 at 12:06 +0900, AKASHI Takahiro wrote:
> There is one driver data option, DRIVER_DATA_REQ_NO_SIG_CHECK,
> which will skip signature verification check at load time
> even in enforcing mode.
> This option is solely for non security-sensitive data.

It's also for firmware that is already signed and checked by the
hardware. In the x86 world almost all modern era firmware is already
signed and the signature checked by the device.

> +static ssize_t firmware_sig_data_write(struct file *filp, struct
> kobject *kobj,
> +				       struct bin_attribute
> *bin_attr,
> +				       char *buffer, loff_t offset,
> +				       size_t count)
> +{
> +	struct device *dev = kobj_to_dev(kobj);
> +	struct firmware_priv *fw_priv = to_firmware_priv(dev);
> +	struct firmware_buf *buf;
> +	void *buf_tmp;
> +	size_t new_size;
> +	ssize_t ret_count;
> +
> +	if (!capable(CAP_SYS_RAWIO))
> +		return -EPERM;
> +
> +	mutex_lock(&fw_lock);
> +	buf = fw_priv->buf;
> +	if (!buf || fw_state_is_done(&buf->fw_st)) {
> +		ret_count = -ENODEV;
> +		goto out;
> +	}
> +
> +	if (buf->sig_data && (offset + count > buf->sig_size)) {

If I do a ridiculously long amount of I/O what stops offset + count
overflowing ? It's no big deal as its CAP_SYS_RAWIO anyway but I'm just
wondering if there is a test missing ?

Alan