lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.02.1309191313440.4111@pianoman.cluster.toy>
Date:	Thu, 19 Sep 2013 13:40:43 -0400 (EDT)
From:	Vince Weaver <vince@...ter.net>
To:	Ingo Molnar <mingo@...nel.org>
cc:	Adrian Hunter <adrian.hunter@...el.com>,
	Peter Zijlstra <peterz@...radead.org>, hpa@...or.com,
	linux-kernel@...r.kernel.org, tglx@...utronix.de,
	linux-tip-commits@...r.kernel.org, eranian@...glemail.com
Subject: Re: [PATCH, v4] perf: Fix capabilities bitfield compatibility in
 'struct perf_event_mmap_page'

On Thu, 19 Sep 2013, Ingo Molnar wrote:

> To solve all that make this change explicit, detectable and self-contained,
> by iterating the ABI the following way:
> 
>  - Always clear bit 0, and rename it to usrpage->cap_bit0, to at least not
>    confuse old user-space binaries. RDPMC will be marked as unavailable
>    to old binaries but that's within the ABI, this is a capability bit.
> 
>  - Rename bit 1 to ->cap_bit0_is_deprecated and always set it to 1, so new
>    libraries can reliably detect that bit 0 is deprecated and perma-zero
>    without having to check the kernel version.
> 
>  - Use bits 2, 3, 4 for the newly defined, correct functionality:
> 
> 	cap_user_rdpmc		: 1, /* The RDPMC instruction can be used to read counts */
> 	cap_user_time		: 1, /* The time_* fields are used */
> 	cap_user_time_zero	: 1, /* The time_zero field is used */
> 

So let me think through the possible combinations:

OLD-KERNEL OLD-HEADER
   + cap_usr_rdpmc and cap_usr_time map to the same bit
   + In general for kernels from 3.4 to 3.11 the bit will be set
     for all x86

NEW-KERNEL OLD-HEADER
   + cap_usr_rdpmc (cap_bit0) and cap_usr_time (cap_bit0) both are 0
   + code detecting cap_usr_rdpmc will probably fall back to non-rdpmc
     even through rdpmc code is probably there and functioning

OLD-KERNEL NEW-HEADER
   + cap_user_rdpmc and cap_user_time both set to 0
   + cap_bit0_is_deprecated can be read; if it is 0 you can
     read cap_bit0, and if it is 1, assume rdpmc is available
     with the same likelyhood you could with the old header

NEW-KERNEL NEW-HEADER
   + Use cap_user_rdpmc and cap_user_time and everything is OK


>  - Rename all the bitfield names in perf_event.h to be different from the
>    old names, to make sure it's not possible to mis-compile it
>    accidentally with old assumptions.

Well this breaks that API, though I guess there are no guarantees there.
I guess that's intentional since it will force 
users to fix their code, but a pain if you aren't expecting it and 
suddenly your project doesn't compile anymore after a kernel-headers 
update.  Most of my code carries around its own perf_event.h so I guess
I'll be unaffected.

In any case this seems to be about as reasonable a solution to this 
problem as we can get.

Vince
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ