Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 14 Jan 2017 00:09:34 +0100
From: "PaX Team" <pageexec@...email.hu>
To: Kees Cook <keescook@...omium.org>
CC: "AKASHI, Takahiro" <takahiro.akashi@...aro.org>,
        Mark Rutland <mark.rutland@....com>,
        park jinbum <jinb.park7@...il.com>,
        "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>
Subject: Re: Introduction

On 13 Jan 2017 at 11:26, Kees Cook wrote:

> I did notice too that it seems like it doesn't notice static initializers:
> 
> security/tomoyo/common.c: In function ‘tomoyo_load_builtin_policy’:
> security/tomoyo/common.c:2745:27: note: userspace variable will be
> forcibly initialized
>    struct tomoyo_io_buffer head = { };

in this case the variable (and its initializer) is in a loop scope (not
the function scope), so it's not matched. as i said, the plugin was written
to match a specific situation, not everything under the sun ;). now it's
possible to extend the coverage to loops as well, but then you'll have to
be careful with performance impact as more and more code will match and
inside a loop the impact can quickly add up...

> fs/read_write.c: In function ‘new_sync_write’:
> fs/read_write.c:490:15: note: userspace variable will be forcibly initialized
>   struct iovec iov = { .iov_base = (void __user *)buf, .iov_len = len };

this is a designated initializer which doesn't match the object constructor
the plugin looks for.

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.