lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 3 Dec 2014 16:01:30 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Richard Weinberger <richard@....at>,
	David Miller <davem@...emloft.net>,
	Thomas Gleixner <tglx@...utronix.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-arch <linux-arch@...r.kernel.org>,
	Al Viro <viro@...iv.linux.org.uk>,
	richard -rw- weinberger <richard.weinberger@...il.com>,
	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...nel.org>,
	Kees Cook <keescook@...omium.org>
Subject: Re: [PATCH v2] all arches, signal: Move restart_block to struct task_struct

On Wed, Dec 3, 2014 at 3:53 PM, Andrew Morton <akpm@...ux-foundation.org> wrote:
> On Wed, 3 Dec 2014 15:38:29 -0800 Andy Lutomirski <luto@...capital.net> wrote:
>
>> Yes, exactly.
>>
>> >
>> > Spelling this out in the changelog would be useful for the ignorant and
>> > the forgetful ;)
>>
>> Want a new version, or will you fix it up yourself?
>>
>
> I think I can work that out.
>
> A couple of linux-next things to check:
>
> - arch/arm/include/asm/thread_info.h:arm_restart_block has
>   disappeared from the thread_info.
>
> - the reference to ti->restart_block in arch/arm/kernel/traps.c has
>   vanished.  I couldn't find anywhere where it was moved to.

This looks like it's:

commit 3f4aa45ceea5789a4aade536acc27f2e0d3da5e1
Author: Vladimir Murzin <vladimir.murzin@....com>
Date:   Thu Nov 27 11:39:04 2014 +0100

    ARM: 8226/1: cacheflush: get rid of restarting block

    We cannot restart cacheflush safely if a process provides user-defined
    signal handler and signal is pending. In this case -EINTR is returned
    and it is expected that process re-invokes syscall. However, there are
    a few problems with that:
     * looks like nobody bothers checking return value from cacheflush
     * but if it did, we don't provide the restart address for that, so the
       process has to use the same range again
     * ...and again, what might lead to looping forever

    So, remove cacheflush restarting code and terminate cache flushing
    as early as fatal signal is pending.

If you haven't already done the obvious fixup (just drop the offending
hunk), I can send a new version.

-- 
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ