All machines: Pointer guard testing update (Bug 15754, CVE-2013-4788).

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

All machines: Pointer guard testing update (Bug 15754, CVE-2013-4788).

Carlos O'Donell-6
All machines,

The fix for CVE-2013-4788 (bug 15754) contains a regression
test to ensure that the pointer guard is both random and
changes between processes.

In order to create the test it was necessary to add a new
accessor macro POINTER_CHK_GUARD to allow the regression
test to locate and read the pointer guard value from outside
of the library.

I have added a POINTER_CHK_GUARD implementation for *all*
machines. You need not do any work at this point. However,
for some machines I wrote the implementation without testing
it e.g. stack guard was just before pointer guard so
POINTER_CHK_GUARD is the same code with a different offset.

My request is that you run the testsuite and verify that
tst-ptrguard1 and tst-ptrguard1-static pass. If they don't
pass please email me and we can work out what might be
wrong with your POINTER_CHK_GUARD implementation.

Cheers,
Carlos.
Reply | Threaded
Open this post in threaded view
|

Re: All machines: Pointer guard testing update (Bug 15754, CVE-2013-4788).

Will Newton
On 26 September 2013 15:52, Carlos O'Donell <[hidden email]> wrote:

Hi Carlos,

> The fix for CVE-2013-4788 (bug 15754) contains a regression
> test to ensure that the pointer guard is both random and
> changes between processes.
>
> In order to create the test it was necessary to add a new
> accessor macro POINTER_CHK_GUARD to allow the regression
> test to locate and read the pointer guard value from outside
> of the library.
>
> I have added a POINTER_CHK_GUARD implementation for *all*
> machines. You need not do any work at this point. However,
> for some machines I wrote the implementation without testing
> it e.g. stack guard was just before pointer guard so
> POINTER_CHK_GUARD is the same code with a different offset.
>
> My request is that you run the testsuite and verify that
> tst-ptrguard1 and tst-ptrguard1-static pass. If they don't
> pass please email me and we can work out what might be
> wrong with your POINTER_CHK_GUARD implementation.

I noticed that alpha does something strange in this regard.

ports/sysdeps/unix/alpha/sysdep.h:

/* There exists generic C code that assumes that PTR_MANGLE is always
   defined.  When generating code for the static libc, we don't have
   __pointer_chk_guard defined.  Nor is there any place that would
   initialize it if it were defined, so there's little point in doing
   anything more than nothing.  */
# ifndef __ASSEMBLER__
#  define PTR_MANGLE(var)
#  define PTR_DEMANGLE(var)
# endif

This looks like in the static case alpha will not benefit from the new
fix. I don't have an alpha toolchain or any particular knowledge of
alpha to verify that though.

--
Will Newton
Toolchain Working Group, Linaro
Reply | Threaded
Open this post in threaded view
|

Re: All machines: Pointer guard testing update (Bug 15754, CVE-2013-4788).

Richard Henderson
On 09/26/2013 08:39 AM, Will Newton wrote:

> On 26 September 2013 15:52, Carlos O'Donell <[hidden email]> wrote:
>
> Hi Carlos,
>
>> The fix for CVE-2013-4788 (bug 15754) contains a regression
>> test to ensure that the pointer guard is both random and
>> changes between processes.
>>
>> In order to create the test it was necessary to add a new
>> accessor macro POINTER_CHK_GUARD to allow the regression
>> test to locate and read the pointer guard value from outside
>> of the library.
>>
>> I have added a POINTER_CHK_GUARD implementation for *all*
>> machines. You need not do any work at this point. However,
>> for some machines I wrote the implementation without testing
>> it e.g. stack guard was just before pointer guard so
>> POINTER_CHK_GUARD is the same code with a different offset.
>>
>> My request is that you run the testsuite and verify that
>> tst-ptrguard1 and tst-ptrguard1-static pass. If they don't
>> pass please email me and we can work out what might be
>> wrong with your POINTER_CHK_GUARD implementation.
>
> I noticed that alpha does something strange in this regard.
>
> ports/sysdeps/unix/alpha/sysdep.h:
>
> /* There exists generic C code that assumes that PTR_MANGLE is always
>    defined.  When generating code for the static libc, we don't have
>    __pointer_chk_guard defined.  Nor is there any place that would
>    initialize it if it were defined, so there's little point in doing
>    anything more than nothing.  */
> # ifndef __ASSEMBLER__
> #  define PTR_MANGLE(var)
> #  define PTR_DEMANGLE(var)
> # endif
>
> This looks like in the static case alpha will not benefit from the new
> fix. I don't have an alpha toolchain or any particular knowledge of
> alpha to verify that though.
>

It looks like Carlos will have just allowed that to be fixed in his patch,
since __pointer_chk_guard_local is now defined if THREAD_SET_POINTER_GUARD isn't.


r~
Reply | Threaded
Open this post in threaded view
|

Re: All machines: Pointer guard testing update (Bug 15754, CVE-2013-4788).

Kaz Kojima
In reply to this post by Carlos O'Donell-6
Hi,

"Carlos O'Donell" <[hidden email]> wrote:
> My request is that you run the testsuite and verify that
> tst-ptrguard1 and tst-ptrguard1-static pass. If they don't
> pass please email me and we can work out what might be
> wrong with your POINTER_CHK_GUARD implementation.

New ptrguard tests fail on SH because the target uses generic
stackguard-macros.h but defines THREAD_SET_POINTER_GUARD.
The attached patch works for me.

Regards,
        kaz
--
        * sysdeps/sh/stackguard-macros.h: New file.

diff --git a/sysdeps/sh/stackguard-macros.h b/sysdeps/sh/stackguard-macros.h
new file mode 100644
index 0000000..55a5771
--- /dev/null
+++ b/sysdeps/sh/stackguard-macros.h
@@ -0,0 +1,6 @@
+#include <stdint.h>
+
+extern uintptr_t __stack_chk_guard;
+#define STACK_CHK_GUARD __stack_chk_guard
+
+#define POINTER_CHK_GUARD THREAD_GET_POINTER_GUARD()

Reply | Threaded
Open this post in threaded view
|

Re: All machines: Pointer guard testing update (Bug 15754, CVE-2013-4788).

Carlos O'Donell-6
On 09/26/2013 09:06 PM, Kaz Kojima wrote:

> Hi,
>
> "Carlos O'Donell" <[hidden email]> wrote:
>> My request is that you run the testsuite and verify that
>> tst-ptrguard1 and tst-ptrguard1-static pass. If they don't
>> pass please email me and we can work out what might be
>> wrong with your POINTER_CHK_GUARD implementation.
>
> New ptrguard tests fail on SH because the target uses generic
> stackguard-macros.h but defines THREAD_SET_POINTER_GUARD.
> The attached patch works for me.
>
> Regards,
> kaz
> --
> * sysdeps/sh/stackguard-macros.h: New file.
>
> diff --git a/sysdeps/sh/stackguard-macros.h b/sysdeps/sh/stackguard-macros.h
> new file mode 100644
> index 0000000..55a5771
> --- /dev/null
> +++ b/sysdeps/sh/stackguard-macros.h
> @@ -0,0 +1,6 @@
> +#include <stdint.h>
> +
> +extern uintptr_t __stack_chk_guard;
> +#define STACK_CHK_GUARD __stack_chk_guard
> +
> +#define POINTER_CHK_GUARD THREAD_GET_POINTER_GUARD()
>

Kaz,

That looks good to me. I will admit that's not a
combination I thought about. Thanks for fixing it.

Cheers,
Carlos.
Reply | Threaded
Open this post in threaded view
|

Re: All machines: Pointer guard testing update (Bug 15754, CVE-2013-4788).

Kaz Kojima
"Carlos O'Donell" <[hidden email]> wrote:
> That looks good to me. I will admit that's not a
> combination I thought about. Thanks for fixing it.

Thanks for your comment.  I've committed it with the ChangeLog
entry below.

Regards,
        kaz
--
2013-09-27  Kaz Kojima  <[hidden email]>

        * sysdeps/sh/stackguard-macros.h: New file.