From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:54966 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755551AbcIRSpj (ORCPT ); Sun, 18 Sep 2016 14:45:39 -0400 Date: Sun, 18 Sep 2016 19:45:07 +0100 From: Ben Hutchings To: Jann Horn Cc: Alexander Viro , Roland McGrath , Oleg Nesterov , John Johansen , James Morris , "Serge E. Hallyn" , Paul Moore , Stephen Smalley , Eric Paris , Casey Schaufler , Kees Cook , Andrew Morton , Janis Danisevskis , Seth Forshee , "Eric . Biederman" , Thomas Gleixner , Benjamin LaHaise , linux-fsdevel@vger.kernel.org, linux-security-module@vger.kernel.org, security@kernel.org Message-ID: <20160918184507.GT10601@decadent.org.uk> References: <1474211117-16674-1-git-send-email-jann@thejh.net> <1474211117-16674-3-git-send-email-jann@thejh.net> <1474222407.2428.2.camel@decadent.org.uk> <20160918183137.GA17170@pc.thejh.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="J9YdZykiGPT3Jhx7" Content-Disposition: inline In-Reply-To: <20160918183137.GA17170@pc.thejh.net> Subject: Re: [PATCH 2/9] exec: turn self_exec_id into self_privunit_id Sender: linux-fsdevel-owner@vger.kernel.org List-ID: --J9YdZykiGPT3Jhx7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 18, 2016 at 08:31:37PM +0200, Jann Horn wrote: > On Sun, Sep 18, 2016 at 07:13:27PM +0100, Ben Hutchings wrote: > > On Sun, 2016-09-18 at 17:05 +0200, Jann Horn wrote: > > > This ensures that self_privunit_id ("privilege unit ID") is only shar= ed by > > > processes that share the mm_struct and the signal_struct; not just > > > spatially, but also temporally. In other words, if you do execve() or > > > clone() without CLONE_THREAD, you get a new privunit_id that has neve= r been > > > used before. > > [...] > > > +void increment_privunit_counter(void) > > > +{ > > > + BUILD_BUG_ON(NR_CPUS > (1 << 16)); > > > + current->self_privunit_id =3D this_cpu_add_return(exec_counter, NR_= CPUS); > > > +} > > [...] > >=20 > > This will wrap incorrectly if NR_CPUS is not a power of 2 (which is > > unusual but allowed). >=20 > If this wraps, hell breaks loose permission-wise - processes that have > no relationship whatsoever with each other will suddenly be able to ptrace > each other. >=20 > The idea is that it never wraps. That's what I suspected, but wasn't sure. In that case you can initialise each counter to U64_MAX/NR_CPUS*cpu and increment by 1 each time, which might be more efficient on some architectures. > It wraps after (2^64)/NR_CPUS execs or > forks on one CPU core. NR_CPUS is bounded to <=3D2^16, so in the worst ca= se, > it wraps after 2^48 execs or forks. >=20 > On my system with 3.7GHz per core, 2^16 minimal sequential non-thread clo= ne() > calls need 1 second system time (and 2 seconds wall clock time, but let's > disregard that), so 2^48 non-thread clone() calls should need over 100 ye= ars. >=20 > But I guess both the kernel and machines get faster - if you think the ma= rgin > might not be future-proof enough (or if you think I measured wrong and it= 's > actually much faster), I guess I could bump this to a 128bit number. Sequential execution speed isn't likely to get significantly faster so with those current numbers this seems to be quite safe. Ben. --=20 Ben Hutchings Reality is just a crutch for people who can't handle science fiction. --J9YdZykiGPT3Jhx7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBV97gs+e/yOyVhhEJAQr2uA//SGhkHHCiXzqxMvkAkYf2p6fmPCgDUJRL /3yfdTK5NfcXE1EAq8zYWlwmJrDtX+C8ga3pstKRAE+EExBf4mvImOFl+yUbzXX8 cETUYnWmJfgeJOA6/QWVSv4eaaoCKUxatbyo7v8TWeZ4Ar8PZ7FBGZaxp3mfE0wQ YDGla61+aNdgYFTeG7fexx5WscwykpztaxfhOzkxOfF+IkLCiDIiiSsFg3tqR5Wf iX18kiLKoX13ewjvkpkuyAKxh+9u1W8nyw6bcYJWwjgHJNNvx16IZcbtjhhq5AWF gwC9XRG6k1p6S3r4+dCe6fad1eYic1gcEapLWXU5OWKbeGvbERp2ei6yLtQaOSpP 3qE+Afd4VpKASCMcFZaVaxM4f6joMmUOiNptdmzs2LwJ6gsu4EJNcVhdMgNPwoR9 z9gJFsKyxhuCZNatwSTW7RSu8x0SK0YwFX2RoAMLgffoZGTgUJMrALDm/Fq5hXZ4 iuozbxLNxHqgPQkkdGVEjhA7kU1xiH4aJC+ECQHQCdYpmpQHpP6VpYplMRtzYTiV ZLE0HlTipRBJlgYaAz9I46VV6z8qAHHGUnRR2Ifyd3sqpWLSsa2b2mcx6jZe+2jD Ctljv7rF76wghfq8lGYEUwTB+QU3jiRG2yM/gs7FGfEaySXecbpdog2JsTcLk3oc JeibiieG9JI= =S9wy -----END PGP SIGNATURE----- --J9YdZykiGPT3Jhx7--