From: Rasmus Villemoes <linux@rasmusvillemoes.dk> To: Kees Cook <keescook@chromium.org> Cc: kernel-hardening@lists.openwall.com, LKML <linux-kernel@vger.kernel.org>, Andrew Morton <akpm@linux-foundation.org> Subject: Re: [RFC 0/6] some compile- and run-time format checking Date: Thu, 9 Nov 2017 15:08:39 +0100 [thread overview] Message-ID: <CAKwiHFjqiK3HM2ZK-HUvKeGtbMdvGf6JQYF+SREZnDtaBqOJ2w@mail.gmail.com> (raw) In-Reply-To: <CAGXu5jKnv_mP1hGEe5FbLV_mYknCknZJjo=-Po0mjnWJSV7+_Q@mail.gmail.com> On 9 November 2017 at 02:11, Kees Cook <keescook@chromium.org> wrote: > On Wed, Nov 8, 2017 at 2:30 PM, Rasmus Villemoes > <linux@rasmusvillemoes.dk> wrote: >> >> Rasmus Villemoes (6): >> plugins: implement format_template attribute >> compiler.h: add __format_template > > Could you split these two off and send separately? This seems like a > fine thing to get in now. Will do. > Probably the second patch should be split up > between adding __format_template, and additions of its usage. Yeah. > Do you have any good ways to find and extract all the dynamic format strings > we need to mark? IIRC, I just did a git grep for designated initializers where the RHS was a string literal containing a % char. Not sure that counts as a good way :) Doing that now finds stuff like drivers/scsi/hisi_sas/hisi_sas_v2_hw.c, where the .msg member cannot be annotated with a single template. Maybe one can work around that by replacing .msg with an anon union of msg_onebit/msg_multibit, with each their own template; I don't know if that will work, or if it will be deemed too much churn (it doesn't provide that much safety, since it would then just rely on accessing the right union member). Maybe the run-time checking is best for that case. Rasmus
WARNING: multiple messages have this Message-ID (diff)
From: Rasmus Villemoes <linux@rasmusvillemoes.dk> To: Kees Cook <keescook@chromium.org> Cc: kernel-hardening@lists.openwall.com, LKML <linux-kernel@vger.kernel.org>, Andrew Morton <akpm@linux-foundation.org> Subject: [kernel-hardening] Re: [RFC 0/6] some compile- and run-time format checking Date: Thu, 9 Nov 2017 15:08:39 +0100 [thread overview] Message-ID: <CAKwiHFjqiK3HM2ZK-HUvKeGtbMdvGf6JQYF+SREZnDtaBqOJ2w@mail.gmail.com> (raw) In-Reply-To: <CAGXu5jKnv_mP1hGEe5FbLV_mYknCknZJjo=-Po0mjnWJSV7+_Q@mail.gmail.com> On 9 November 2017 at 02:11, Kees Cook <keescook@chromium.org> wrote: > On Wed, Nov 8, 2017 at 2:30 PM, Rasmus Villemoes > <linux@rasmusvillemoes.dk> wrote: >> >> Rasmus Villemoes (6): >> plugins: implement format_template attribute >> compiler.h: add __format_template > > Could you split these two off and send separately? This seems like a > fine thing to get in now. Will do. > Probably the second patch should be split up > between adding __format_template, and additions of its usage. Yeah. > Do you have any good ways to find and extract all the dynamic format strings > we need to mark? IIRC, I just did a git grep for designated initializers where the RHS was a string literal containing a % char. Not sure that counts as a good way :) Doing that now finds stuff like drivers/scsi/hisi_sas/hisi_sas_v2_hw.c, where the .msg member cannot be annotated with a single template. Maybe one can work around that by replacing .msg with an anon union of msg_onebit/msg_multibit, with each their own template; I don't know if that will work, or if it will be deemed too much churn (it doesn't provide that much safety, since it would then just rely on accessing the right union member). Maybe the run-time checking is best for that case. Rasmus
next prev parent reply other threads:[~2017-11-09 14:08 UTC|newest] Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-11-08 22:30 [RFC 0/6] some compile- and run-time format checking Rasmus Villemoes 2017-11-08 22:30 ` [kernel-hardening] " Rasmus Villemoes 2017-11-08 22:30 ` [RFC 1/6] plugins: implement format_template attribute Rasmus Villemoes 2017-11-08 22:30 ` [kernel-hardening] " Rasmus Villemoes 2017-11-08 22:30 ` [RFC 2/6] compiler.h: add __format_template Rasmus Villemoes 2017-11-08 22:30 ` [kernel-hardening] " Rasmus Villemoes 2017-11-08 22:30 ` [RFC 3/6] compiler.h: add __attribute__((format_arg)) shorthand Rasmus Villemoes 2017-11-08 22:30 ` [kernel-hardening] " Rasmus Villemoes 2017-11-08 22:30 ` [RFC 4/6] lib/vsprintf.c: add fmtcheck utility Rasmus Villemoes 2017-11-08 22:30 ` [kernel-hardening] " Rasmus Villemoes 2017-11-09 1:08 ` Kees Cook 2017-11-09 1:08 ` [kernel-hardening] " Kees Cook 2017-11-08 22:30 ` [RFC 5/6] kernel.h: implement fmtmatch() wrapper around fmtcheck() Rasmus Villemoes 2017-11-08 22:30 ` [kernel-hardening] " Rasmus Villemoes 2017-11-08 22:30 ` [RFC 6/6] lib/test_printf.c: add a few fmtcheck() test cases Rasmus Villemoes 2017-11-08 22:30 ` [kernel-hardening] " Rasmus Villemoes 2017-11-09 1:11 ` [RFC 0/6] some compile- and run-time format checking Kees Cook 2017-11-09 1:11 ` [kernel-hardening] " Kees Cook 2017-11-09 14:08 ` Rasmus Villemoes [this message] 2017-11-09 14:08 ` Rasmus Villemoes 2018-10-26 23:24 ` [RFC PATCH 0/7] runtime format string checking Rasmus Villemoes 2018-10-26 23:24 ` [RFC PATCH 1/7] compiler_attributes.h: add __attribute__((format_arg)) shorthand Rasmus Villemoes 2018-10-27 12:06 ` Miguel Ojeda 2018-10-29 10:20 ` Rasmus Villemoes 2018-10-29 19:17 ` Miguel Ojeda 2018-11-02 10:36 ` Miguel Ojeda 2018-11-02 10:43 ` Rasmus Villemoes 2019-01-09 10:57 ` Miguel Ojeda 2018-10-26 23:24 ` [RFC PATCH 2/7] lib/vsprintf.c: add fmtcheck utility Rasmus Villemoes 2018-10-26 23:24 ` [RFC PATCH 3/7] kernel.h: implement fmtmatch() wrapper around fmtcheck() Rasmus Villemoes 2018-10-26 23:24 ` [RFC PATCH 4/7] lib/test_printf.c: add a few fmtcheck() test cases Rasmus Villemoes 2018-10-26 23:24 ` [RFC PATCH 5/7] kernel/kthread.c: do runtime check of format string in kthread_create_on_cpu() Rasmus Villemoes 2018-10-26 23:24 ` [RFC PATCH 6/7] nfs: use fmtcheck() in root_nfs_data Rasmus Villemoes 2018-10-26 23:24 ` [RFC PATCH 7/7] drivers: hwmon: add runtime format string checking Rasmus Villemoes 2018-10-27 17:44 ` Guenter Roeck 2018-10-30 20:58 ` [RFC PATCH 0/7] " Kees Cook 2018-11-01 22:06 ` Rasmus Villemoes 2018-11-01 22:57 ` Kees Cook 2018-11-02 20:09 ` Rasmus Villemoes 2018-11-02 20:46 ` Kees Cook 2018-11-05 9:33 ` Rasmus Villemoes
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=CAKwiHFjqiK3HM2ZK-HUvKeGtbMdvGf6JQYF+SREZnDtaBqOJ2w@mail.gmail.com \ --to=linux@rasmusvillemoes.dk \ --cc=akpm@linux-foundation.org \ --cc=keescook@chromium.org \ --cc=kernel-hardening@lists.openwall.com \ --cc=linux-kernel@vger.kernel.org \ /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: linkBe 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.