* [kernel-hardening] Format string gcc-plugin? @ 2017-02-14 18:01 Laura Abbott 2017-02-14 19:07 ` Kees Cook 0 siblings, 1 reply; 6+ messages in thread From: Laura Abbott @ 2017-02-14 18:01 UTC (permalink / raw) To: kernel-hardening Hi, The recent discussions about %pk led me to start playing around with writing a gcc plugin (notes about writing a gcc plugin are forthcoming). My idea was to expand checking of the kernel's additional formats (%pK, %pR etc.) or possibly even change the format strings. The big issue is that most of vsprintf.c would end up in the plugin which would be ugly to maintain. This concept could be used for some of the problems with kernel pointer leaks https://kernsec.org/wiki/index.php/Bug_Classes/Kernel_pointer_leak but I'm interested if anyone else has thoughts or ideas about how better to do this (or even not to do this). Thanks, Laura ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [kernel-hardening] Format string gcc-plugin? 2017-02-14 18:01 [kernel-hardening] Format string gcc-plugin? Laura Abbott @ 2017-02-14 19:07 ` Kees Cook 2017-02-15 17:31 ` Roberts, William C 2017-02-23 23:15 ` [kernel-hardening] " Rasmus Villemoes 0 siblings, 2 replies; 6+ messages in thread From: Kees Cook @ 2017-02-14 19:07 UTC (permalink / raw) To: Laura Abbott; +Cc: kernel-hardening On Tue, Feb 14, 2017 at 10:01 AM, Laura Abbott <labbott@redhat.com> wrote: > Hi, > > The recent discussions about %pk led me to start playing around > with writing a gcc plugin (notes about writing a gcc plugin are > forthcoming). My idea was to expand checking of the kernel's additional > formats (%pK, %pR etc.) or possibly even change the format > strings. The big issue is that most of vsprintf.c would end up > in the plugin which would be ugly to maintain. This concept could > be used for some of the problems with kernel pointer leaks > https://kernsec.org/wiki/index.php/Bug_Classes/Kernel_pointer_leak > but I'm interested if anyone else has thoughts or ideas about > how better to do this (or even not to do this). If we can leverage common code between the plugin and vsprintf.c, it should be doable. I haven't looked at processing format strings at all, though I assume the plugin would need to check the __printf-generated attributes. In my related notes was a hint that looking at how gcc does it normally is gcc/c-family/c-format.c: http://stackoverflow.com/a/16336175 And while not strictly part of format type checking, I talked a bit about dealing with const strings here: http://www.openwall.com/lists/kernel-hardening/2016/12/07/16 -Kees -- Kees Cook Pixel Security ^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: [kernel-hardening] Format string gcc-plugin? 2017-02-14 19:07 ` Kees Cook @ 2017-02-15 17:31 ` Roberts, William C 2017-02-23 23:15 ` [kernel-hardening] " Rasmus Villemoes 1 sibling, 0 replies; 6+ messages in thread From: Roberts, William C @ 2017-02-15 17:31 UTC (permalink / raw) To: Kees Cook, Laura Abbott; +Cc: kernel-hardening, nicolas.iooss_linux > -----Original Message----- > From: keescook@google.com [mailto:keescook@google.com] On Behalf Of Kees > Cook > Sent: Tuesday, February 14, 2017 11:08 AM > To: Laura Abbott <labbott@redhat.com> > Cc: kernel-hardening@lists.openwall.com > Subject: Re: [kernel-hardening] Format string gcc-plugin? > > On Tue, Feb 14, 2017 at 10:01 AM, Laura Abbott <labbott@redhat.com> wrote: > > Hi, > > > > The recent discussions about %pk led me to start playing around with > > writing a gcc plugin (notes about writing a gcc plugin are > > forthcoming). My idea was to expand checking of the kernel's > > additional formats (%pK, %pR etc.) or possibly even change the format > > strings. The big issue is that most of vsprintf.c would end up in the > > plugin which would be ugly to maintain. This concept could be used for > > some of the problems with kernel pointer leaks > > https://kernsec.org/wiki/index.php/Bug_Classes/Kernel_pointer_leak > > but I'm interested if anyone else has thoughts or ideas about how > > better to do this (or even not to do this). > > If we can leverage common code between the plugin and vsprintf.c, it should be > doable. I haven't looked at processing format strings at all, though I assume the > plugin would need to check the __printf-generated attributes. > > In my related notes was a hint that looking at how gcc does it normally is gcc/c- > family/c-format.c: > http://stackoverflow.com/a/16336175 > > And while not strictly part of format type checking, I talked a bit about dealing > with const strings here: > http://www.openwall.com/lists/kernel-hardening/2016/12/07/16 > > -Kees > > -- > Kees Cook > Pixel Security gcc would be nice since it's the compiler most often used for building linux kernel (does clang work fully yet?) Nicolas Iooss was able to use UBSan to find one: commit 901d805c33fc4c029fc6b2d94ee5fb7d30278045 Author: Nicolas Iooss <nicolas.iooss_linux@m4x.org> Date: Tue Aug 2 14:03:10 2016 -0700 UBSAN: fix typo in format string ^ permalink raw reply [flat|nested] 6+ messages in thread
* [kernel-hardening] Re: Format string gcc-plugin? 2017-02-14 19:07 ` Kees Cook 2017-02-15 17:31 ` Roberts, William C @ 2017-02-23 23:15 ` Rasmus Villemoes 2017-08-07 22:06 ` Vaishali Thakkar 1 sibling, 1 reply; 6+ messages in thread From: Rasmus Villemoes @ 2017-02-23 23:15 UTC (permalink / raw) To: Kees Cook; +Cc: Laura Abbott, kernel-hardening On Tue, Feb 14 2017, Kees Cook <keescook@chromium.org> wrote: > On Tue, Feb 14, 2017 at 10:01 AM, Laura Abbott <labbott@redhat.com> wrote: >> Hi, >> >> The recent discussions about %pk led me to start playing around >> with writing a gcc plugin (notes about writing a gcc plugin are >> forthcoming). My idea was to expand checking of the kernel's additional >> formats (%pK, %pR etc.) or possibly even change the format >> strings. The big issue is that most of vsprintf.c would end up >> in the plugin which would be ugly to maintain. This concept could >> be used for some of the problems with kernel pointer leaks >> https://kernsec.org/wiki/index.php/Bug_Classes/Kernel_pointer_leak >> but I'm interested if anyone else has thoughts or ideas about >> how better to do this (or even not to do this). > > If we can leverage common code between the plugin and vsprintf.c, it > should be doable. I haven't looked at processing format strings at > all, though I assume the plugin would need to check the > __printf-generated attributes. > smatch already does type checking of the kernel's %p extensions, plus some additional sanity checks (e.g. passing a signed char to %02x, duplicate KERN_* or KERN_* prefixes not at the beginning, 0x%d, etc.). Maybe Dan Carpenter is the only one actually running it periodically. I never managed to get sparse to grok the printf attribute, so it uses a hardcoded list of printf-like functions. It would be nice to do these checks in a gcc plugin to get wider coverage and piggyback on the actual printf attributes, and it would probably be easier to keep up with the endless stream of new %pX stuff that way. Rasmus ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [kernel-hardening] Re: Format string gcc-plugin? 2017-02-23 23:15 ` [kernel-hardening] " Rasmus Villemoes @ 2017-08-07 22:06 ` Vaishali Thakkar 2017-08-07 22:18 ` Kees Cook 0 siblings, 1 reply; 6+ messages in thread From: Vaishali Thakkar @ 2017-08-07 22:06 UTC (permalink / raw) To: Rasmus Villemoes, Kees Cook; +Cc: Laura Abbott, kernel-hardening On Friday 24 February 2017 04:45 AM, Rasmus Villemoes wrote: > On Tue, Feb 14 2017, Kees Cook <keescook@chromium.org> wrote: > >> On Tue, Feb 14, 2017 at 10:01 AM, Laura Abbott <labbott@redhat.com> wrote: >>> Hi, >>> >>> The recent discussions about %pk led me to start playing around >>> with writing a gcc plugin (notes about writing a gcc plugin are >>> forthcoming). My idea was to expand checking of the kernel's additional >>> formats (%pK, %pR etc.) or possibly even change the format >>> strings. The big issue is that most of vsprintf.c would end up >>> in the plugin which would be ugly to maintain. This concept could >>> be used for some of the problems with kernel pointer leaks >>> https://kernsec.org/wiki/index.php/Bug_Classes/Kernel_pointer_leak >>> but I'm interested if anyone else has thoughts or ideas about >>> how better to do this (or even not to do this). >> >> If we can leverage common code between the plugin and vsprintf.c, it >> should be doable. I haven't looked at processing format strings at >> all, though I assume the plugin would need to check the >> __printf-generated attributes. >> > > smatch already does type checking of the kernel's %p extensions, plus > some additional sanity checks (e.g. passing a signed char to %02x, > duplicate KERN_* or KERN_* prefixes not at the beginning, 0x%d, > etc.). Maybe Dan Carpenter is the only one actually running it > periodically. I never managed to get sparse to grok the printf > attribute, so it uses a hardcoded list of printf-like functions. It > would be nice to do these checks in a gcc plugin to get wider coverage > and piggyback on the actual printf attributes, and it would probably be > easier to keep up with the endless stream of new %pX stuff that way. Hi all, I was recently looking at gcc's -Wformat-security and realized that there is a TODO point on KSPP's wiki page regarding fixing it for const strings. I was wondering that may be we can also try Coccinelle for the type checking of %pX extensions? Is there any work done or is someone working on this after this discussion? I'm not sure what is a preferable way over here [GCC plugin or Coccinelle scripts] but if noone is working on this then I would like to give it a try. Any comments on the same are welcome. Thanks! > Rasmus > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [kernel-hardening] Re: Format string gcc-plugin? 2017-08-07 22:06 ` Vaishali Thakkar @ 2017-08-07 22:18 ` Kees Cook 0 siblings, 0 replies; 6+ messages in thread From: Kees Cook @ 2017-08-07 22:18 UTC (permalink / raw) To: Vaishali Thakkar; +Cc: Rasmus Villemoes, Laura Abbott, kernel-hardening On Mon, Aug 7, 2017 at 3:06 PM, Vaishali Thakkar <vaishali.thakkar@oracle.com> wrote: > I was recently looking at gcc's -Wformat-security and realized that there is > a TODO point on KSPP's wiki page regarding fixing it for const > strings. > > I was wondering that may be we can also try Coccinelle for the type checking > of %pX extensions? Is there any work done or is someone working on this > after this discussion? > > I'm not sure what is a preferable way over here [GCC plugin or Coccinelle > scripts] but if noone is working on this then I would like to give it a try. > Any comments on the same are welcome. I would prefer a gcc plugin just because that could be enabled for the regular build (where as a Coccinelle check is a separate build type). Also I think a gcc plugin would allow for better control of the checks, since it will actually be in the middle of constructing the actual instructions and variables, etc. Coccinelle has to guess sometimes. -Kees -- Kees Cook Pixel Security ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-08-07 22:18 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-02-14 18:01 [kernel-hardening] Format string gcc-plugin? Laura Abbott 2017-02-14 19:07 ` Kees Cook 2017-02-15 17:31 ` Roberts, William C 2017-02-23 23:15 ` [kernel-hardening] " Rasmus Villemoes 2017-08-07 22:06 ` Vaishali Thakkar 2017-08-07 22:18 ` Kees Cook
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.