RE: [PATCH v3 02/11] mm: Hardened usercopy
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: David Laight <David.Laight@xxxxxxxxxx>, "'Josh Poimboeuf'" <jpoimboe@xxxxxxxxxx>, Kees Cook <keescook@xxxxxxxxxxxx>
- Subject: RE: [PATCH v3 02/11] mm: Hardened usercopy
- From: Michael Ellerman <mpe@xxxxxxxxxxxxxx>
- Date: Tue, 26 Jul 2016 12:09:14 +1000
- Cc: "linux-ia64\@vger.kernel.org" <linux-ia64@xxxxxxxxxxxxxxx>, "kernel-hardening\@lists.openwall.com" <kernel-hardening@xxxxxxxxxxxxxxxxxx>, Catalin Marinas <catalin.marinas@xxxxxxx>, Will Deacon <will.deacon@xxxxxxx>, Linux-MM <linux-mm@xxxxxxxxx>, sparclinux <sparclinux@xxxxxxxxxxxxxxx>, Jan Kara <jack@xxxxxxx>, Christoph Lameter <cl@xxxxxxxxx>, Andrea Arcangeli <aarcange@xxxxxxxxxx>, "x86\@kernel.org" <x86@xxxxxxxxxx>, Russell King <linux@xxxxxxxxxxxxxxx>, Dmitry Vyukov <dvyukov@xxxxxxxxxx>, David Rientjes <rientjes@xxxxxxxxxx>, PaX Team <pageexec@xxxxxxxxxxx>, Borislav Petkov <bp@xxxxxxx>, Mathias Krause <minipli@xxxxxxxxxxxxxx>, linux-arch <linux-arch@xxxxxxxxxxxxxxx>, Rik van Riel <riel@xxxxxxxxxx>, Brad Spengler <spender@xxxxxxxxxxxxxx>, Andy Lutomirski <luto@xxxxxxxxxx>, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>, "linux-arm-kernel\@lists.infradead.org" <linux-arm-kernel@xxxxxxxxxxxxxxxxxxx>, Laura Abbott <labbott@xxxxxxxxxxxxxxxxx>, Tony Luck <tony.luck@xxxxxxxxx>, Ard Biesh euvel <ard.biesheuvel@xxxxxxxxxx>, LKML <linux-kernel@xxxxxxxxxxxxxxx>, Fenghua Yu <fenghua.yu@xxxxxxxxx>, Pekka Enberg <penberg@xxxxxxxxxx>, Daniel Micay <danielmicay@xxxxxxxxx>, Casey Schaufler <casey@xxxxxxxxxxxxxxxx>, Joonsoo Kim <iamjoonsoo.kim@xxxxxxx>, "linuxppc-dev\@lists.ozlabs.org" <linuxppc-dev@xxxxxxxxxxxxxxxx>, "David S. Miller" <davem@xxxxxxxxxxxxx>
- In-reply-to: <063D6719AE5E284EB5DD2968C1650D6D5F502102@AcuExch.aculab.com>
- List-id: <linux-ia64.vger.kernel.org>
- References: <1468619065-3222-1-git-send-email-keescook@chromium.org> <1468619065-3222-3-git-send-email-keescook@chromium.org> <5790711f.2350420a.b4287.2cc0SMTPIN_ADDED_BROKEN@mx.google.com> <CAGXu5jLCu1Vv0uugKZrsjSEsoABgXJSOJ8GkKmrHbvj9jkC2YA@mail.gmail.com> <20160722174551.jddle6mf7zlq6xmb@treble> <063D6719AE5E284EB5DD2968C1650D6D5F502102@AcuExch.aculab.com>
- User-agent: Notmuch/0.21 (https://notmuchmail.org)
David Laight <David.Laight@xxxxxxxxxx> 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
through.
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.
cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Index of Archives]
[Linux Kernel]
[Sparc Linux]
[DCCP]
[Linux ARM]
[Yosemite News]
[Linux SCSI]
[Linux x86_64]
[Linux for Ham Radio]