Message ID | 20180104122801.GA3038@pjb1027-Latitude-E5410 (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
On Thu, Jan 4, 2018 at 4:28 AM, Jinbum Park <jinb.park7@gmail.com> wrote: > arm prefers to use REFCOUNT_FULL by default. > This enables it for arm. > > Signed-off-by: Jinbum Park <jinb.park7@gmail.com> Acked-by: Kees Cook <keescook@chromium.org> -Kees > --- > arch/arm/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 3d349b4..ec80270 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -100,6 +100,7 @@ config ARM > select OLD_SIGACTION > select OLD_SIGSUSPEND3 > select PERF_USE_VMALLOC > + select REFCOUNT_FULL > select RTC_LIB > select SYS_SUPPORTS_APM_EMULATION > # Above selects are sorted alphabetically; please add new ones > -- > 1.9.1 >
On Thu, Jan 04, 2018 at 10:32:46AM -0800, Kees Cook wrote: > On Thu, Jan 4, 2018 at 4:28 AM, Jinbum Park <jinb.park7@gmail.com> wrote: > > arm prefers to use REFCOUNT_FULL by default. > > This enables it for arm. > > > > Signed-off-by: Jinbum Park <jinb.park7@gmail.com> > > Acked-by: Kees Cook <keescook@chromium.org> I'd help if there was some kind of explanation about this. Not everyone knows what REFCOUNT_FULL is. Also, why does "arm" "prefer" to use this? Where does the preference come from - and why is it a preference but being enforced by the Kconfig ?
On Thu, Jan 4, 2018 at 10:35 AM, Russell King - ARM Linux <linux@armlinux.org.uk> wrote: > On Thu, Jan 04, 2018 at 10:32:46AM -0800, Kees Cook wrote: >> On Thu, Jan 4, 2018 at 4:28 AM, Jinbum Park <jinb.park7@gmail.com> wrote: >> > arm prefers to use REFCOUNT_FULL by default. >> > This enables it for arm. >> > >> > Signed-off-by: Jinbum Park <jinb.park7@gmail.com> >> >> Acked-by: Kees Cook <keescook@chromium.org> > > I'd help if there was some kind of explanation about this. Not > everyone knows what REFCOUNT_FULL is. > > Also, why does "arm" "prefer" to use this? Where does the preference > come from - and why is it a preference but being enforced by the > Kconfig ? This came from discussions with Will Deacon (and others) during the Linux Security Summit. The arm64 side of this is in commit 4adcec1164de ("arm64: Always use REFCOUNT_FULL"). AIUI, Will said he didn't want the specialized "fast but technically incomplete" refcounting as seen with x86's fast refcount infrastructure, but rather to keep refcounts always fully protected by default because no one could point to real-world performance impacts with REFCOUNT_FULL vs unprotected atomic_t infrastructure. I'm fine leaving this choice up to the end user, but I think it makes sense to be always-on. If that's no okay, maybe make it default-y for arm32, and still let people turn it off if they want? -Kees
On Thu, Jan 04, 2018 at 10:42:21AM -0800, Kees Cook wrote: > On Thu, Jan 4, 2018 at 10:35 AM, Russell King - ARM Linux > <linux@armlinux.org.uk> wrote: > > On Thu, Jan 04, 2018 at 10:32:46AM -0800, Kees Cook wrote: > >> On Thu, Jan 4, 2018 at 4:28 AM, Jinbum Park <jinb.park7@gmail.com> wrote: > >> > arm prefers to use REFCOUNT_FULL by default. > >> > This enables it for arm. > >> > > >> > Signed-off-by: Jinbum Park <jinb.park7@gmail.com> > >> > >> Acked-by: Kees Cook <keescook@chromium.org> > > > > I'd help if there was some kind of explanation about this. Not > > everyone knows what REFCOUNT_FULL is. > > > > Also, why does "arm" "prefer" to use this? Where does the preference > > come from - and why is it a preference but being enforced by the > > Kconfig ? > > This came from discussions with Will Deacon (and others) during the > Linux Security Summit. The arm64 side of this is in commit > 4adcec1164de ("arm64: Always use REFCOUNT_FULL"). AIUI, Will said he > didn't want the specialized "fast but technically incomplete" > refcounting as seen with x86's fast refcount infrastructure, but > rather to keep refcounts always fully protected by default because no > one could point to real-world performance impacts with REFCOUNT_FULL > vs unprotected atomic_t infrastructure. > > I'm fine leaving this choice up to the end user, but I think it makes > sense to be always-on. If that's no okay, maybe make it default-y for > arm32, and still let people turn it off if they want? I'm not really asking for changes. I'm basically asking for the commit message to do a better job of explaining this - in years to come, the currently proposed commit message contains very little information about why this commit exists. Commit messages need to say what they're doing and why, and not assume that someone's been to some conference and knows all the inside details that were discussed there. It's also best to avoid referencing papers - conferences and their websites come and go, and links break, at which point information gets lost. If it's all properly explained in the commit message, then it's there forever.
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 3d349b4..ec80270 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -100,6 +100,7 @@ config ARM select OLD_SIGACTION select OLD_SIGSUSPEND3 select PERF_USE_VMALLOC + select REFCOUNT_FULL select RTC_LIB select SYS_SUPPORTS_APM_EMULATION # Above selects are sorted alphabetically; please add new ones
arm prefers to use REFCOUNT_FULL by default. This enables it for arm. Signed-off-by: Jinbum Park <jinb.park7@gmail.com> --- arch/arm/Kconfig | 1 + 1 file changed, 1 insertion(+)