linux-kernel - Re: [RFC] fixing the UML failure root cause

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: <CA+55aFx3-F1LzVwN_gSqXcsU7uWda41bHyJxGxHNODWURu0T_g@mail.gmail.com>
Date:	Sat, 15 Oct 2011 08:10:43 +1200
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Andrew Lutomirski <luto@....edu>
Cc:	Ingo Molnar <mingo@...e.hu>,
	richard -rw- weinberger <richard.weinberger@...il.com>,
	Adrian Bunk <bunk@...sta.de>,
	"H. Peter Anvin" <hpa@...ux.intel.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, x86@...nel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC] fixing the UML failure root cause

On Fri, Oct 14, 2011 at 6:30 PM, Andrew Lutomirski <luto@....edu> wrote:
>
> Another idea is to have a flag that asks the fault handlers to call
> force_sig_info for us.  That's just one bit of per-thread state.  Then
> the vsyscall emulation code could check access_ok, force a signal if
> access is not ok, then set the flag and do the syscall.  And maybe
> some processes would want to opt in to that mode anyway -- arguably
> EFAULT is a serious programmer error and should be dealt with more
> harshly than other syscall misuses.

Ok, so I really like that approach. I could easily see some process
saying "I want a SIGSEGV in addition to the EFAULT that I always get".

And yes, it would fix the vsyscall emulation code which could just
save the thread flag, set it, do the accesses, and restore it to the
old valud.

Please make it so,

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