All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Nick Desaulniers <ndesaulniers@google.com>
Cc: Sami Tolvanen <samitolvanen@google.com>,
	James Morris <jamorris@linux.microsoft.com>,
	David Howells <dhowells@redhat.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	KP Singh <kpsingh@google.com>,
	Casey Schaufler <casey@schaufler-ca.com>,
	Thomas Cedeno <thomascedeno@google.com>,
	Anders Roxell <anders.roxell@linaro.org>,
	LKML <linux-kernel@vger.kernel.org>,
	clang-built-linux <clang-built-linux@googlegroups.com>
Subject: Re: [PATCH] security: fix the key_permission LSM hook function type
Date: Mon, 15 Jun 2020 11:47:21 -0700	[thread overview]
Message-ID: <202006151144.C9E5EA2C76@keescook> (raw)
In-Reply-To: <CAKwvOdkdy10K+6Jw=Sd4PxrvQgc=HssoJqJN9q8NVWkWiuZtRQ@mail.gmail.com>

On Mon, Jun 15, 2020 at 11:23:44AM -0700, Nick Desaulniers wrote:
> On Mon, Jun 15, 2020 at 11:21 AM Kees Cook <keescook@chromium.org> wrote:
> >
> > On Mon, Jun 15, 2020 at 11:12:32AM -0700, Sami Tolvanen wrote:
> > > Commit 8c0637e950d6 ("keys: Make the KEY_NEED_* perms an enum rather than
> > > a mask") changed the type of the key_permission callback functions, but
> > > didn't change the type of the hook, which trips indirect call checking with
> > > Control-Flow Integrity (CFI). This change fixes the issue by changing the
> > > hook type to match the functions.
> > >
> > > Fixes: 8c0637e950d6 ("keys: Make the KEY_NEED_* perms an enum rather than a mask")
> > > Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
> >
> > Thanks for fixing this!
> >
> > Acked-by: Kees Cook <keescook@chromium.org>
> >
> > I wonder if there is any compiler option we can turn on to catch the
> > implicit enum/int casting that would help for these kinds of things
> > without absolutely exploding the build warnings.
> >
> > I see -Wenum-conversion, but that seems to be between enums, not between
> > int.
> >
> > I see this, but it's external:
> > https://noamlewis.wordpress.com/2017/10/05/type-safe-enums-in-c-using-a-clang-plugin/
> 
> Unfortunately, using a looser integral type is the typical workaround
> for -Wenum-conversion warnings (which is on by default, GCC recently
> added that flag, too).  For warning on enum to int, the kernel would
> probably blow up with warnings. I don't know of any such existing
> warning flag.

Yeah, I couldn't find anything either. The closest I could find to avoid
one of the common classes of enum -> int conversion is the bitwise
operations, which is covered by __attribute__((flag_enum)):
https://clang.llvm.org/docs/AttributeReference.html#flag-enum

Ah well. We'll let CFI find them. ;)

-- 
Kees Cook

  reply	other threads:[~2020-06-15 18:47 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-15 18:12 [PATCH] security: fix the key_permission LSM hook function type Sami Tolvanen
2020-06-15 18:21 ` Kees Cook
2020-06-15 18:23   ` Nick Desaulniers
2020-06-15 18:47     ` Kees Cook [this message]
2020-06-21  5:54 ` Kees Cook
2020-06-22 17:38 ` James Morris

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=202006151144.C9E5EA2C76@keescook \
    --to=keescook@chromium.org \
    --cc=anders.roxell@linaro.org \
    --cc=casey@schaufler-ca.com \
    --cc=clang-built-linux@googlegroups.com \
    --cc=dhowells@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=jamorris@linux.microsoft.com \
    --cc=kpsingh@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=samitolvanen@google.com \
    --cc=thomascedeno@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.