All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: joao@overdrivepizza.com
Cc: linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org,
	peterz@infradead.org, jpoimboe@redhat.com,
	andrew.cooper3@citrix.com, samitolvanen@google.com,
	mark.rutland@arm.com, hjl.tools@gmail.com,
	alyssa.milburn@linux.intel.com, ndesaulniers@google.com,
	gabriel.gomes@linux.intel.com, rick.p.edgecombe@intel.com
Subject: Re: [RFC PATCH 11/11] driver/int3400_thermal: Fix prototype matching
Date: Tue, 19 Apr 2022 19:55:19 -0700	[thread overview]
Message-ID: <202204191946.2843CF71@keescook> (raw)
In-Reply-To: <20220420004241.2093-12-joao@overdrivepizza.com>

On Tue, Apr 19, 2022 at 05:42:41PM -0700, joao@overdrivepizza.com wrote:
> From: Joao Moreira <joao@overdrivepizza.com>
> 
> The function attr_dev_show directly invokes functions from drivers
> expecting an specific prototype. The driver for int3400_thermal
> implements the given show function using a different prototype than what
> is expected. This violates the prototype-based fine-grained CFI policy.
> 
> Make the function prototype compliant and cast the respective assignement
> so it can be properly user together with fine-grained CFI.

Does this trip on regular CFI? See below, but this all looks correct to
me in the original code.

> (FWIIW, there should be a less ugly patch for this, but I don't know
> enough about the touched source code).
> 
> Signed-off-by: Joao Moreira <joao@overdrivepizza.com>
> ---
>  .../thermal/intel/int340x_thermal/int3400_thermal.c    | 10 +++++++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/thermal/intel/int340x_thermal/int3400_thermal.c b/drivers/thermal/intel/int340x_thermal/int3400_thermal.c
> index 4954800b9850..4bd95a2016b7 100644
> --- a/drivers/thermal/intel/int340x_thermal/int3400_thermal.c
> +++ b/drivers/thermal/intel/int340x_thermal/int3400_thermal.c
> @@ -311,12 +311,13 @@ static int int3400_thermal_get_uuids(struct int3400_thermal_priv *priv)
>  	return result;
>  }
>  
> -static ssize_t odvp_show(struct kobject *kobj, struct kobj_attribute *attr,
> +static ssize_t odvp_show(struct device *kobj, struct device_attribute *attr,
>  			 char *buf)
>  {
> +	struct kobj_attribute *kattr = (struct kobj_attribute *) attr;
>  	struct odvp_attr *odvp_attr;
>  
> -	odvp_attr = container_of(attr, struct odvp_attr, attr);
> +	odvp_attr = container_of(kattr, struct odvp_attr, attr);
>  
>  	return sprintf(buf, "%d\n", odvp_attr->priv->odvp[odvp_attr->odvp]);
>  }
> @@ -388,7 +389,10 @@ static int evaluate_odvp(struct int3400_thermal_priv *priv)
>  				goto out_err;
>  			}
>  			odvp->attr.attr.mode = 0444;

Eww, this function has a masked "odvp" variable here. One should be
likely renamed.

But anyway, odvp is:

struct odvp_attr {
        int odvp;
        struct int3400_thermal_priv *priv;
        struct kobj_attribute attr;
};

The original code looks correct to me (besides the masked variable
name). kobj_attribute is part of odvp, the odvp_show callback has the
correct prototype, and performs the correct container_of() to get
odvp_attr.

Where/why is the mismatch happening?

-Kees

> -			odvp->attr.show = odvp_show;
> +			odvp->attr.show = (ssize_t (*)
> +					(struct kobject *,
> +					 struct kobj_attribute *,
> +					 char *)) odvp_show;
>  			odvp->attr.store = NULL;
>  			ret = sysfs_create_file(&priv->pdev->dev.kobj,
>  						&odvp->attr.attr);
> -- 
> 2.35.1
> 

-- 
Kees Cook

  reply	other threads:[~2022-04-20  2:55 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-20  0:42 [RFC PATCH 00/11] Kernel FineIBT Support joao
2022-04-20  0:42 ` [RFC PATCH 01/11] x86: kernel FineIBT joao
2022-04-29  1:37   ` Josh Poimboeuf
2022-05-02 17:17     ` Joao Moreira
2022-05-03 22:02       ` Josh Poimboeuf
2022-05-04  2:19         ` Joao Moreira
2022-05-04 10:20         ` Peter Zijlstra
2022-05-04 17:04           ` Peter Collingbourne
2022-05-04 18:16             ` Peter Zijlstra
2022-05-05  0:28               ` Sami Tolvanen
2022-05-05  7:36                 ` Peter Zijlstra
2022-05-08  8:29               ` Kees Cook
2022-05-09 11:22                 ` Peter Zijlstra
2022-04-20  0:42 ` [RFC PATCH 02/11] kbuild: Support FineIBT build joao
2022-04-20  0:42 ` [RFC PATCH 03/11] objtool: Support FineIBT offset fixes joao
2022-04-20  8:23   ` kernel test robot
2022-04-20  0:42 ` [RFC PATCH 04/11] x86/module: Support FineIBT in modules joao
2022-04-20  0:42 ` [RFC PATCH 05/11] x86/text-patching: Support FineIBT text-patching joao
2022-04-20  0:42 ` [RFC PATCH 06/11] x86/bpf: Support FineIBT joao
2022-04-20  0:42 ` [RFC PATCH 07/11] x86/lib: Prevent UACCESS call warning from objtool joao
2022-04-20  0:42 ` [RFC PATCH 08/11] x86/ibt: Add CET_TEST module for IBT testing joao
2022-04-20  0:42 ` [RFC PATCH 09/11] x86/FineIBT: Add FINEIBT_TEST module joao
2022-04-20  0:42 ` [RFC PATCH 10/11] linux/interrupt: Fix prototype matching property joao
2022-04-20  2:45   ` Kees Cook
2022-04-20 22:14     ` Joao Moreira
2022-04-20  0:42 ` [RFC PATCH 11/11] driver/int3400_thermal: Fix prototype matching joao
2022-04-20  2:55   ` Kees Cook [this message]
2022-04-20 22:28     ` Joao Moreira
2022-04-20 23:04       ` Kees Cook
2022-04-20 23:12         ` Joao Moreira
2022-04-20 23:25           ` Kees Cook
2022-04-21  0:28             ` Joao Moreira
2022-04-20  2:42 ` [RFC PATCH 00/11] Kernel FineIBT Support Kees Cook
2022-04-20 22:50   ` Joao Moreira
2022-04-20  7:40 ` Peter Zijlstra
2022-04-20 15:17   ` Josh Poimboeuf
2022-04-20 17:12     ` Nick Desaulniers
2022-04-20 22:40       ` Joao Moreira
2022-04-21  7:49         ` Peter Zijlstra
2022-04-21 15:23           ` Joao Moreira
2022-04-21 15:35             ` H.J. Lu
2022-04-21 22:11               ` Fangrui Song
2022-04-21 22:26                 ` H.J. Lu
2022-04-20 23:34 ` Edgecombe, Rick P

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=202204191946.2843CF71@keescook \
    --to=keescook@chromium.org \
    --cc=alyssa.milburn@linux.intel.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=gabriel.gomes@linux.intel.com \
    --cc=hjl.tools@gmail.com \
    --cc=joao@overdrivepizza.com \
    --cc=jpoimboe@redhat.com \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=ndesaulniers@google.com \
    --cc=peterz@infradead.org \
    --cc=rick.p.edgecombe@intel.com \
    --cc=samitolvanen@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.