On Tue, Aug 04, 2015 at 05:54:51AM +0200, Borislav Petkov wrote:
On Mon, Aug 03, 2015 at 11:45:24AM -0700, Andy Lutomirski wrote:
P.P.P.S. Who thought that IRET faults unmasking NMIs made any sense
whatsoever when NMIs run on an IST stack? Seriously, people?
What happened with asking
On Mon, Aug 03, 2015 at 03:35:15PM -0700, Kees Cook wrote:
Yay for perm disable! Thank you! :)
Andy would like to see this evolve towards something possibly
more complete and/or generic. I think this needs more thoughts
and that we should possibly stick to 0/1 for now and decide how
we want to
On Mon, Aug 3, 2015 at 4:19 PM, Willy Tarreau w...@1wt.eu wrote:
On Mon, Aug 03, 2015 at 03:35:15PM -0700, Kees Cook wrote:
Yay for perm disable! Thank you! :)
Andy would like to see this evolve towards something possibly
more complete and/or generic. I think this needs more thoughts
and
On Mon, Aug 3, 2015 at 11:23 AM, Willy Tarreau w...@1wt.eu wrote:
For distros who prefer not to take the risk of completely disabling the
modify_ldt syscall using CONFIG_MODIFY_LDT_SYSCALL, this patch adds a
sysctl to enable, temporarily disable, or permanently disable it at
runtime, and
On Mon, Aug 03, 2015 at 11:45:24AM -0700, Andy Lutomirski wrote:
P.P.P.S. Who thought that IRET faults unmasking NMIs made any sense
whatsoever when NMIs run on an IST stack? Seriously, people?
What happened with asking Intel for a sane IRET-NG?
Should be relatively easy - take the current
On Mon, Aug 3, 2015 at 11:23 AM, Willy Tarreau w...@1wt.eu wrote:
For distros who prefer not to take the risk of completely disabling the
modify_ldt syscall using CONFIG_MODIFY_LDT_SYSCALL, this patch adds a
sysctl to enable, temporarily disable, or permanently disable it at
runtime, and
On Mon, Aug 03, 2015 at 12:06:12PM -0700, Andy Lutomirski wrote:
On Mon, Aug 3, 2015 at 12:01 PM, Willy Tarreau w...@1wt.eu wrote:
(...)
I feel like it's probably part of a larger project then. Do you think
we should step back and only support 0/1 for now ? I also have the
patch available.
On Mon, Aug 03, 2015 at 11:45:24AM -0700, Andy Lutomirski wrote:
I'm not entirely convinced that the lock bit should work this way. At
some point, we might want a setting for 32-bit only or even 32-bit,
present, not non-conforming only (like we do unconditionally for
set_thread_area). When
On Mon, Aug 3, 2015 at 12:01 PM, Willy Tarreau w...@1wt.eu wrote:
On Mon, Aug 03, 2015 at 11:45:24AM -0700, Andy Lutomirski wrote:
I'm not entirely convinced that the lock bit should work this way. At
some point, we might want a setting for 32-bit only or even 32-bit,
present, not
