2017-07-06 0:56 GMT+03:00 Linus Torvalds :
> On Wed, Jul 5, 2017 at 2:48 PM, Arnd Bergmann wrote:
>>
>> This particular example should be handled by
>> scripts/gcc-plugins/structleak_plugin.c, right?
>
> .. probably. But we have a ton of other uses that just pass in
> "result" pointers (not struct
On Wed, Jul 5, 2017 at 3:27 PM, Ard Biesheuvel
wrote:
>
> The compiler already keeps track of which auto variables have their
> address taken, so it shouldn't be /that/ hard to come up with a plugin
> that zero initializes such variables before their address is taken if
> no such initialization is
On 5 July 2017 at 22:56, Linus Torvalds wrote:
> On Wed, Jul 5, 2017 at 2:48 PM, Arnd Bergmann wrote:
>>
>> This particular example should be handled by
>> scripts/gcc-plugins/structleak_plugin.c, right?
>
> .. probably. But we have a ton of other uses that just pass in
> "result" pointers (not s
On Wed, Jul 5, 2017 at 2:48 PM, Arnd Bergmann wrote:
>
> This particular example should be handled by
> scripts/gcc-plugins/structleak_plugin.c, right?
.. probably. But we have a ton of other uses that just pass in
"result" pointers (not structs), which admittedly don't have the
padding issue, bu
On Wed, Jul 5, 2017 at 2:48 PM, Arnd Bergmann wrote:
> On Wed, Jul 5, 2017 at 11:35 PM, Linus Torvalds
> wrote:
>
>> So the issue I think would be good to fix is perhaps best explained by
>> pseudo-code
>>
>> int testfn(struct somestruct __user *p)
>> {
>> struct somestruct a;
>>
>>
On Wed, Jul 5, 2017 at 12:07 PM, Linus Torvalds
wrote:
> Hmm. Completely unrelated comment, and this may not be a gcc 'plugin'
> issue as much as a more general gcc question, but I suspect a plugin
> could do it.
>
> For the kernel, we already really ignore some of the more idiotic C
> standard ru
On Wed, Jul 5, 2017 at 11:35 PM, Linus Torvalds
wrote:
> So the issue I think would be good to fix is perhaps best explained by
> pseudo-code
>
> int testfn(struct somestruct __user *p)
> {
> struct somestruct a;
>
> initialize_struct(&a);
> if (copy_to_user(p, &a, siz
On Wed, Jul 5, 2017 at 1:40 PM, Ard Biesheuvel
wrote:
>
> So while I think it may be useful for robustness, to avoid erratic
> behavior or exploitable interactions between different parts of the
> code, my estimation is that it wouldn't make a great deal of
> difference, given that the logic that
On Wed, Jul 5, 2017 at 9:07 PM, Linus Torvalds
wrote:
> And maybe I'm wrong, and maybe it would generate a lot of really bad
> extra zeroing and wouldn't be acceptable for most people, but I
> *think* this might be one of those things where we might get some
> extra belt and suspenders kind of har
On 5 July 2017 at 20:07, Linus Torvalds wrote:
> Hmm. Completely unrelated comment, and this may not be a gcc 'plugin'
> issue as much as a more general gcc question, but I suspect a plugin
> could do it.
>
> For the kernel, we already really ignore some of the more idiotic C
> standard rules that
Hmm. Completely unrelated comment, and this may not be a gcc 'plugin'
issue as much as a more general gcc question, but I suspect a plugin
could do it.
For the kernel, we already really ignore some of the more idiotic C
standard rules that introduce pointless undefined behavior: things
like the st
Hi,
Please pull these gcc-plugins changes for v4.13-rc1. The big part is
the randstruct plugin infrastructure. This is the first of two expected
pull requests for randstruct since there are dependencies in other
trees that would be easier to merge once those have landed. Notably,
the IPC allocatio
12 matches
Mail list logo
