[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5879F900.12283.370F7409@pageexec.freemail.hu>
Date: Sat, 14 Jan 2017 11:10:08 +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 15:15, Kees Cook wrote:
> On Fri, Jan 13, 2017 at 3:09 PM, PaX Team <pageexec@...email.hu> wrote:
> >> 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.
>
> What would an object constructor look like?
as you can see it in the plugin source, it has a specific TREE_CODE.
> When I had it report the times it skipped forced initialization, the
> code mostly looked like designated initializers. All I found in the
> gimple were SSAs. Nothing jumped out at me as being an initializer.
while the gimple dumps are human readable, they omit lots of information
so it's better to look at the data structures at compile time. that said,
a constructor should appear as an assignment like this:
s1 = {};
a designated initializer is modeled as a constructor and per-field assignments
by the compiler (both are subject to optimizations so you won't necessarily see
all of them in the dumps of later passes).
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.
