linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave P Martin <Dave.Martin@arm.com>
To: PaX Team <pageexec@freemail.hu>
Cc: Kees Cook <keescook@chromium.org>,
	Mark Rutland <mark.rutland@arm.com>,
	<kernel-hardening@lists.openwall.com>,
	Emese Revfy <re.emese@gmail.com>,
	"AKASHI, Takahiro" <takahiro.akashi@linaro.org>,
	park jinbum <jinb.park7@gmail.com>,
	Daniel Micay <danielmicay@gmail.com>,
	<linux-kernel@vger.kernel.org>, <spender@grsecurity.net>
Subject: Re: [PATCH] gcc-plugins: Add structleak for more stack initialization
Date: Tue, 17 Jan 2017 10:42:39 +0000	[thread overview]
Message-ID: <20170117104239.GG18838@e103592.cambridge.arm.com> (raw)
In-Reply-To: <587D1D70.26193.89AFE10@pageexec.freemail.hu>

On Mon, Jan 16, 2017 at 08:22:24PM +0100, PaX Team wrote:
> On 16 Jan 2017 at 11:54, Mark Rutland wrote:

[...]

> > I assume that this is only guaranteed to initialise fields in a struct,
> > and not padding, is that correct? I ask due to the issue described in:
> >
> > https://lwn.net/Articles/417989/
>
> the 'issue' is that before C11 the standard didn't make it clear that in
> case of a partial initializer list the compiler has to initialize not only
> the remaining fields but also padding as well.

Which version of the C11 spec clarifies this?

The one I'm looking at (n1570, Apr 12 2011) says:

"6.7.9 21 If there are fewer initializers in a brace-enclosed list than
there are elements or members of an aggregate, or fewer characters in a
string literal used to initialize an array of known size than there are
elements in the array, the remainder of the aggregate shall be
initialized implicitly the same as objects that have static storage
duration."

What is meant by "the remainder of the object" is unclear.  Is this
just the tail of the object, or all unitialised members --
which may be sparse in the case of an initialiser with designators?
And is padding (and if so, which padding) considered to be part of (the
remainder of) the object for the purpose of this paragraph?

This can be read with the interpretation you suggest, but the wording
doesn't seem rock-solid.  For the kernel, I guess it's sufficient if
GCC commits to this interpretation though.


A related, perhaps more interesting issue is that C11 still explicitly
states that padding is undefined after assignment:

"6.2.6.1 6 When a value is stored in an object of structure or union
type, including in a member object, the bytes of the object
representation that correspond to any padding bytes take unspecified
values.  51)"

"51) Thus, for example, structure assignment need not copy any padding
bits."

which means that in:

{
        struct foo foo1 = FOO1_INTIALIZER;
        struct foo foo2;

        foo2 = foo1;
}

the contents of padding in foo2 is unspecified.

Similarly, piecemeal initialisation of an object by assigning to every
member leaves the padding unspecified, e.g.:

{
        struct timeval tv;

        tv.tv_sec = secs;
        tv.tv_usec = usecs;
}

(On most or all arches struct timeval contains no padding, but relying
implicitly on this is still a bit iffy.)


It's highly likely that the kernel passes objects resulting from one of
the above to put_user() and friends.  It would be good if we had a way
to catch at least some of these.

(I don't know whether that falls naturally under this plugin.)

Cheers
---Dave
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

  reply	other threads:[~2017-01-17 10:43 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
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 [this message]
     [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=20170117104239.GG18838@e103592.cambridge.arm.com \
    --to=dave.martin@arm.com \
    --cc=danielmicay@gmail.com \
    --cc=jinb.park7@gmail.com \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=pageexec@freemail.hu \
    --cc=re.emese@gmail.com \
    --cc=spender@grsecurity.net \
    --cc=takahiro.akashi@linaro.org \
    --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).