[kernel-hardening] [PATCH] arm: Always use REFCOUNT_FULL

[kernel-hardening] [PATCH] arm: Always use REFCOUNT_FULL

[Jinbum Park]

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(+)

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

Re: [kernel-hardening] [PATCH] arm: Always use REFCOUNT_FULL

[Kees Cook]

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
>



-- 
Kees Cook
Pixel Security

Re: [kernel-hardening] [PATCH] arm: Always use REFCOUNT_FULL

[Russell King - ARM Linux]

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 ?

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

Re: [kernel-hardening] [PATCH] arm: Always use REFCOUNT_FULL

[Kees Cook]

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

-- 
Kees Cook
Pixel Security

Re: [kernel-hardening] [PATCH] arm: Always use REFCOUNT_FULL

[Russell King - ARM Linux]

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.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up