Re: move stack-protector availability out of Kconfig

[Kees Cook]

On Tue, Feb 13, 2018 at 7:27 AM, tedheadster  wrote:
> Kees,
>   I have a question about this patch. When I configure a kernel for
> ARCH=i386 it sets these Kconfig variables this way:
>
> HAVE_CC_STACKPROTECTOR=y
> CC_STACKPROTECTOR_AUTO=y
>
> CC_STACKPROTECTOR_NONE=n
> CC_STACKPROTECTOR_REGULAR=n
> CC_STACKPROTECTOR_STRONG=n
>
> It seems to me that at least _one_ of the last _three_ variables
> should be set to 'y' with the defaults that are being set, probably
> CC_STACKPOINTER_NONE=y. All of them being 'n' doesn't make sense to
> me.

The last three are a defined state and map to specific flags. _AUTO
just tries its best to find any working flag. After some redesign to
Kconfig, this may improve so that Kconfig maps directly to things that
right now only the Makefile can determine. That's under development
now.

> As a side note, these defaults set X86_32_LAZY_GS=n (depends on X86_32
> [=y] && CC_STACKPROTECTOR_NONE [=n]) which causes the x86_32 kernels
> to hang. I'll discuss  that in a different email thread, but just
> wanted to say how I came upon this.

I'd tested this combination, but I must have missed something. I'll go
read the other email...

-Kees

-- 
Kees Cook
Pixel Security

Re: move stack-protector availability out of Kconfig

[Kees Cook]

On Tue, Feb 13, 2018 at 7:27 AM, tedheadster  wrote:
> Kees,
>   I have a question about this patch. When I configure a kernel for
> ARCH=i386 it sets these Kconfig variables this way:
>
> HAVE_CC_STACKPROTECTOR=y
> CC_STACKPROTECTOR_AUTO=y
>
> CC_STACKPROTECTOR_NONE=n
> CC_STACKPROTECTOR_REGULAR=n
> CC_STACKPROTECTOR_STRONG=n
>
> It seems to me that at least _one_ of the last _three_ variables
> should be set to 'y' with the defaults that are being set, probably
> CC_STACKPOINTER_NONE=y. All of them being 'n' doesn't make sense to
> me.

The last three are a defined state and map to specific flags. _AUTO
just tries its best to find any working flag. After some redesign to
Kconfig, this may improve so that Kconfig maps directly to things that
right now only the Makefile can determine. That's under development
now.

> As a side note, these defaults set X86_32_LAZY_GS=n (depends on X86_32
> [=y] && CC_STACKPROTECTOR_NONE [=n]) which causes the x86_32 kernels
> to hang. I'll discuss  that in a different email thread, but just
> wanted to say how I came upon this.

I'd tested this combination, but I must have missed something. I'll go
read the other email...

-Kees

-- 
Kees Cook
Pixel Security

Re: move stack-protector availability out of Kconfig

[tedheadster]

Kees,
  I have a question about this patch. When I configure a kernel for
ARCH=i386 it sets these Kconfig variables this way:

HAVE_CC_STACKPROTECTOR=y
CC_STACKPROTECTOR_AUTO=y

CC_STACKPROTECTOR_NONE=n
CC_STACKPROTECTOR_REGULAR=n
CC_STACKPROTECTOR_STRONG=n

It seems to me that at least _one_ of the last _three_ variables
should be set to 'y' with the defaults that are being set, probably
CC_STACKPOINTER_NONE=y. All of them being 'n' doesn't make sense to
me.

As a side note, these defaults set X86_32_LAZY_GS=n (depends on X86_32
[=y] && CC_STACKPROTECTOR_NONE [=n]) which causes the x86_32 kernels
to hang. I'll discuss  that in a different email thread, but just
wanted to say how I came upon this.

- Matthew Whitehead

Re: move stack-protector availability out of Kconfig

[tedheadster]

Kees,
  I have a question about this patch. When I configure a kernel for
ARCH=i386 it sets these Kconfig variables this way:

HAVE_CC_STACKPROTECTOR=y
CC_STACKPROTECTOR_AUTO=y

CC_STACKPROTECTOR_NONE=n
CC_STACKPROTECTOR_REGULAR=n
CC_STACKPROTECTOR_STRONG=n

It seems to me that at least _one_ of the last _three_ variables
should be set to 'y' with the defaults that are being set, probably
CC_STACKPOINTER_NONE=y. All of them being 'n' doesn't make sense to
me.

As a side note, these defaults set X86_32_LAZY_GS=n (depends on X86_32
[=y] && CC_STACKPROTECTOR_NONE [=n]) which causes the x86_32 kernels
to hang. I'll discuss  that in a different email thread, but just
wanted to say how I came upon this.

- Matthew Whitehead