Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 26 Jul 2016 12:09:14 +1000
From: Michael Ellerman <>
To: David Laight <David.Laight@...LAB.COM>, 'Josh Poimboeuf' <>, Kees Cook <>
Cc: "linux-ia64\" <>, "kernel-hardening\" <>, Catalin Marinas <>, Will Deacon <>, Linux-MM <>, sparclinux <>, Jan Kara <>, Christoph Lameter <>, Andrea Arcangeli <>, "x86\" <>, Russell King <>, Dmitry Vyukov <>, David Rientjes <>, PaX Team <>, Borislav Petkov <>, Mathias Krause <>, linux-arch <>, Rik van Riel <>, Brad Spengler <>, Andy Lutomirski <>, Andrew Morton <>, "linux-arm-kernel\" <>, Laura Abbott <>, Tony Luck <>, Ard Biesh
 euvel <>, LKML <>, Fenghua Yu <>, Pekka Enberg <>, Daniel Micay <>, Casey Schaufler <>, Joonsoo Kim <>, "linuxppc-dev\" <>, "David S. Miller" <>
Subject: RE: [PATCH v3 02/11] mm: Hardened usercopy

David Laight <David.Laight@...LAB.COM> writes:

> From: Josh Poimboeuf
>> Sent: 22 July 2016 18:46
>> >
>> > e.g. then if the pointer was in the thread_info, the second test would
>> > fail, triggering the protection.
>> FWIW, this won't work right on x86 after Andy's
>> CONFIG_THREAD_INFO_IN_TASK patches get merged.
> What ends up in the 'thread_info' area?

It depends on the arch.

> If it contains the fp save area then programs like gdb may end up requesting
> copy_in/out directly from that area.

On the arches I've seen thread_info doesn't usually contain register save areas,
but if it did then it would be up to the arch helper to allow that copy to go

However given thread_info generally contains lots of low level flags that would
be a good target for an attacker, the best way to cope with ptrace wanting to
copy to/from it would be to use a temporary, and prohibit copying directly
to/from thread_info - IMHO.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.