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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ