linux-kernel - Re: [PATCH] x86 : Ensure X86_FLAGS

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]

Message-ID: <alpine.DEB.2.02.1409292144340.22082@ionos.tec.linutronix.de>
Date:	Mon, 29 Sep 2014 21:51:59 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Sebastian Lackner <sebastian@...-team.de>
cc:	Andy Lutomirski <luto@...capital.net>,
	Anish Bhatt <anish@...lsio.com>, linux-kernel@...r.kernel.org,
	x86@...nel.org, mingo@...hat.com, hpa@...or.com
Subject: Re: [PATCH] x86 : Ensure X86_FLAGS_NT is cleared on syscall entry

On Mon, 29 Sep 2014, Sebastian Lackner wrote:
> I see several issues here:
> 
> * At first the behaviour is not consistent between several system
> call and return instructions. For example calling syscalls by using
> 'int' doesn't have this issue, as it clears the NT flag before
> entering kernel code. Return instructions also don't show this issue
> all the time, just when it hits one of the problematic pieces of
> code.

And why should we care? The use of NT is not supported. Period. So it
does not matter whether A explodes and B does not.

> * The kernel might execute all kind of other code (for example
> inside of drivers) and start additional threads. I didn't find any
> good example yet, but its not that unlikely, that the exception can
> also happen in a completely unrelated thread, where the kernel can
> not just kill the corresponding usermode app...

The thread can execute whatever it wants in kernel context. The
exception is going to hit on return to user space and not in some
random kernel context. The threads it creates are going to die as
well.

> I'm fine with all kind of solutions, either it should be allowed to
> set NT, or the kernel should at least throw a proper exception, so
> that usermode has a chance to catch and handle it. At the moment the
> segfault is deadly, as the segfault handler immediately segfaults
> again - no chance to recover from such an error.

# gdb ./crap core

(gdb) info registers

eflags         0x4296	[ PF AF SF IF NT ]

Tells you very much that there is state which is not supported.

Thanks,

	tglx
--
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/