All of lore.kernel.org
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: Kees Cook <keescook@chromium.org>
Cc: Daniel Borkmann <dborkman@redhat.com>,
	"David S. Miller" <davem@davemloft.net>,
	shemminger@networkplumber.org,
	Florian Weimer <fweimer@redhat.com>,
	netdev@vger.kernel.org, Eric Dumazet <eric.dumazet@gmail.com>,
	linux-wireless@vger.kernel.org
Subject: Re: [PATCH] random: seed random_int_secret at least poorly at core_initcall time
Date: Fri, 15 Nov 2013 16:05:20 -0500	[thread overview]
Message-ID: <20131115210520.GA16722@thunk.org> (raw)
In-Reply-To: <CAGXu5j+ySEdQBXKkspYC=svfekBja2Z_2tcWSAOEbvyiMLf=aA@mail.gmail.com>

On Fri, Nov 15, 2013 at 10:33:04AM -0800, Kees Cook wrote:
> 
> When the static stack canary was mentioned during the ARM summit, I
> dug around a little bit and saw that at very early boot, yes, it was
> always the same, but after boot finished, it was different from boot
> to boot. I didn't get far enough to figure out what was changing it
> later on.

I've been in Seoul this past week, so I haven't had a chance look more
closely at this, but what's not clear to me what the impact will be of
having a static statck canary during early boot.  Does that mean the
stack canary for the certain kernel threads and the pid 1 are always
constant, since their stacks are getting set up before we're actually
able to initialize the stack canary with something random?

     		       	     	    	 - Ted

WARNING: multiple messages have this Message-ID (diff)
From: Theodore Ts'o <tytso-3s7WtUTddSA@public.gmane.org>
To: Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Cc: Daniel Borkmann
	<dborkman-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	"David S. Miller" <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>,
	shemminger-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org,
	Florian Weimer <fweimer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Eric Dumazet
	<eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH] random: seed random_int_secret at least poorly at core_initcall time
Date: Fri, 15 Nov 2013 16:05:20 -0500	[thread overview]
Message-ID: <20131115210520.GA16722@thunk.org> (raw)
In-Reply-To: <CAGXu5j+ySEdQBXKkspYC=svfekBja2Z_2tcWSAOEbvyiMLf=aA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On Fri, Nov 15, 2013 at 10:33:04AM -0800, Kees Cook wrote:
> 
> When the static stack canary was mentioned during the ARM summit, I
> dug around a little bit and saw that at very early boot, yes, it was
> always the same, but after boot finished, it was different from boot
> to boot. I didn't get far enough to figure out what was changing it
> later on.

I've been in Seoul this past week, so I haven't had a chance look more
closely at this, but what's not clear to me what the impact will be of
having a static statck canary during early boot.  Does that mean the
stack canary for the certain kernel threads and the pid 1 are always
constant, since their stacks are getting set up before we're actually
able to initialize the stack canary with something random?

     		       	     	    	 - Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2013-11-15 21:05 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-11 11:20 [PATCH net-next 0/6] prandom fixes/improvements Daniel Borkmann
2013-11-11 11:20 ` [PATCH net-next 1/6] random32: fix off-by-one in seeding requirement Daniel Borkmann
2013-11-11 11:20 ` [PATCH net-next 2/6] random32: add periodic reseeding Daniel Borkmann
2013-11-11 11:20 ` [PATCH net-next 3/6] random32: add prandom_reseed_late() and call when nonblocking pool becomes initialized Daniel Borkmann
2013-11-11 13:43   ` Theodore Ts'o
2013-11-12  0:03     ` Hannes Frederic Sowa
2013-11-12  0:37       ` Karl Beldan
2013-11-12  0:37         ` Karl Beldan
2013-11-12  8:36         ` Johannes Berg
2013-11-12  8:36           ` Johannes Berg
2013-11-12 11:13           ` Karl Beldan
2013-11-12 11:13             ` Karl Beldan
2013-11-12 13:09             ` Hannes Frederic Sowa
2013-11-12 11:53       ` Theodore Ts'o
2013-11-12 12:04         ` Johannes Berg
2013-11-12 13:16         ` Hannes Frederic Sowa
2013-11-12 13:16           ` Hannes Frederic Sowa
2013-11-12 13:46           ` [PATCH] random: seed random_int_secret at least poorly at core_initcall time Hannes Frederic Sowa
2013-11-12 13:46             ` Hannes Frederic Sowa
2013-11-14  2:54             ` Theodore Ts'o
2013-11-14  2:54               ` Theodore Ts'o
2013-11-14  4:18               ` Hannes Frederic Sowa
2013-11-14  5:05                 ` Hannes Frederic Sowa
2013-11-14  5:05                   ` Hannes Frederic Sowa
2013-11-15 18:42                 ` Kees Cook
2013-11-16  7:40                   ` Hannes Frederic Sowa
2013-11-16  7:40                     ` Hannes Frederic Sowa
2013-11-15 18:33               ` Kees Cook
2013-11-15 18:33                 ` Kees Cook
2013-11-15 18:45                 ` Dave Jones
2013-11-15 18:45                   ` Dave Jones
2013-11-15 19:07                   ` Kees Cook
2013-11-15 21:05                 ` Theodore Ts'o [this message]
2013-11-15 21:05                   ` Theodore Ts'o
2013-11-11 11:20 ` [PATCH net-next 4/6] random32: move rnd_state to linux/random.h Daniel Borkmann
2013-11-11 11:20 ` [PATCH net-next 5/6] random32: upgrade taus88 generator to taus113 from errata paper Daniel Borkmann
2013-11-11 11:20 ` [PATCH net-next 6/6] random32: add test cases for taus113 implementation Daniel Borkmann
2013-11-11 19:33 ` [PATCH net-next 0/6] prandom fixes/improvements David Miller
2013-11-11 19:44   ` Hannes Frederic Sowa
2013-11-11 20:00     ` David Miller

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=20131115210520.GA16722@thunk.org \
    --to=tytso@mit.edu \
    --cc=davem@davemloft.net \
    --cc=dborkman@redhat.com \
    --cc=eric.dumazet@gmail.com \
    --cc=fweimer@redhat.com \
    --cc=keescook@chromium.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=shemminger@networkplumber.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.