linux-kernel - Re: [PATCH 1/3] arm/syscalls: Move address limit check in loop

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, 26 Jul 2017 19:25:34 +0100
From:   Russell King - ARM Linux <linux@...linux.org.uk>
To:     Thomas Garnier <thgarnie@...gle.com>
Cc:     Will Deacon <will.deacon@....com>,
        Leonard Crestez <leonard.crestez@....com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Catalin Marinas <catalin.marinas@....com>,
        Dave Martin <Dave.Martin@....com>,
        Chris Metcalf <cmetcalf@...lanox.com>,
        Pratyush Anand <panand@...hat.com>,
        linux-arm-kernel@...ts.infradead.org,
        LKML <linux-kernel@...r.kernel.org>,
        Kernel Hardening <kernel-hardening@...ts.openwall.com>
Subject: Re: [PATCH 1/3] arm/syscalls: Move address limit check in loop

On Wed, Jul 26, 2017 at 07:20:22AM -0700, Thomas Garnier wrote:
> On Wed, Jul 26, 2017 at 5:02 AM, Will Deacon <will.deacon@....com> wrote:
> > I looked to see what you've done for x86, but it looks like you check/clear
> > the flag before the work pending loop (exit_to_usermode_loop), which
> > subsequently re-enables interrupts and exits when
> > EXIT_TO_USERMODE_LOOP_FLAGS are all clear. Since TIF_FSCHECK isn't included
> > in those flags, what stops it being set again by an irq and remaining set
> > for the return to userspace?
> 
> Nothing, I plan to improve the x86 logic later. I focused on ARM/ARM64
> right now based on Leonard report.

Hmm.  In this case, I'd suggest concentrating on x86 and getting the
implementation correct there before porting it to other architectures.

If x86 were to check TIF_FSCHECK in the loop, and repeat until clear,
would x86 also end up in these infinite loops that have been reported
on ARM as well?

I strongly suggest testing the behaviour with kprobes/tracing enabled
for a function called from the work pending loop, and checking how
that behaves.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.