From: "PaX Team" <firstname.lastname@example.org> To: Mark Rutland <email@example.com> Cc: firstname.lastname@example.org, Kees Cook <email@example.com>, Emese Revfy <firstname.lastname@example.org>, "AKASHI, Takahiro" <email@example.com>, park jinbum <firstname.lastname@example.org>, Daniel Micay <email@example.com>, firstname.lastname@example.org, email@example.com Subject: Re: [PATCH] gcc-plugins: Add structleak for more stack initialization Date: Mon, 16 Jan 2017 20:30:29 +0100 [thread overview] Message-ID: <587D1F55.2222.8A262A4@pageexec.freemail.hu> (raw) In-Reply-To: <20170116152425.GG5908@leverpostej> On 16 Jan 2017 at 15:24, Mark Rutland wrote: > To me, it seems that the __user annotation can only be an indicator of > an issue by chance. We have structures with __user pointers in structs > that will never be copied to userspace, and conversely we have structs > that don't contain a __user field, but will be copied to userspace. > > Maybe it happens that structs in more complex systems are more likely to > contain some __user pointer. Was that part of the rationale? it's as i explained in an earlier email: we wanted to pattern match a specific bug situation and this was the easiest way (as you can see, the plugin's code is very simple, not much effort went into it). > I wonder if there's any analysis we can do of data passing into > copy_to_user() and friends. I guess we can't follow the data flow across > compilation units, but we might be able to follow it well enough if we > added a new attribute that described whether data was to be copied to > userspace. there're are all kinds of data flow analyses you can do within and even across translation units (summary info a'la size overflow hash tables or LTO). i never went into that direction because i think the security goal can be achieved without the performance impact of forced initialization.
next prev parent reply other threads:[~2017-01-16 19:30 UTC|newest] Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-01-13 22:02 Kees Cook 2017-01-14 10:03 ` PaX Team 2017-01-16 15:24 ` Mark Rutland 2017-01-16 19:08 ` Daniel Micay 2017-01-16 19:30 ` PaX Team [this message] 2017-01-17 17:48 ` Mark Rutland 2017-01-17 18:54 ` PaX Team 2017-01-18 10:48 ` Mark Rutland 2017-01-17 17:48 ` Kees Cook 2017-01-16 11:54 ` Mark Rutland 2017-01-16 12:26 ` [kernel-hardening] " Mark Rutland 2017-01-16 19:22 ` PaX Team 2017-01-17 10:42 ` Dave P Martin [not found] ` <587E4FDD.31940.D47F642@pageexec.freemail.hu> 2017-01-17 18:07 ` Dave P Martin 2017-01-17 19:25 ` PaX Team 2017-01-17 22:04 ` Dave P Martin 2017-01-17 17:56 ` Kees Cook
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=587D1F55.2222.8A262A4@pageexec.freemail.hu \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH] gcc-plugins: Add structleak for more stack initialization' \ /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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).