david.vra...@citrix.com
Cc: Borislav Petkov b...@suse.de
Cc: David Vrabel david.vra...@citrix.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@redhat.com
Cc: H. Peter Anvin h...@zytor.com
Cc: x...@kernel.org
Cc: Andy Lutomirski l...@amacapital.net
Cc: Steven Rostedt rost
This is a dramatic simplification and speedup of the vdso pvclock read
code. Is it correct?
Andy Lutomirski (2):
x86, vdso: Use asm volatile in __getcpu
x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader
arch/x86/include/asm/vgtod.h | 6 ++--
arch/x86/vdso
,vdso: Use LSL unconditionally for vgetcpu
but I don't trust GCC enough to expect the problem to stay fixed.
There should be no correctness issue, because the __getcpu calls in
__vdso_vlock_gettime were never necessary in the first place.
Signed-off-by: Andy Lutomirski l...@amacapital.net
On Mon, Dec 22, 2014 at 11:21 PM, Paolo Bonzini pbonz...@redhat.com wrote:
On 23/12/2014 01:39, Andy Lutomirski wrote:
This is a dramatic simplification and speedup of the vdso pvclock read
code. Is it correct?
Andy Lutomirski (2):
x86, vdso: Use asm volatile in __getcpu
x86, vdso
On Thu, Feb 5, 2015 at 4:41 AM, David Vrabel david.vra...@citrix.com wrote:
Hypercalls submitted by user space tools via the privcmd driver can
take a long time (potentially many 10s of seconds) if the hypercall
has many sub-operations.
+
+void xen_maybe_preempt_hcall(void)
I think this
Suggested-by: Andy Lutomirski l...@amacapital.net
Cc: Andy Lutomirski l...@amacapital.net
Cc: Borislav Petkov b...@suse.de
Cc: David Vrabel david.vra...@citrix.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@redhat.com
Cc: H. Peter Anvin h...@zytor.com
Cc: x...@kernel.org
by: Andrew Cooper andrew.coop...@citrix.com
Cc: Andy Lutomirski l...@amacapital.net
Cc: Borislav Petkov b...@suse.de
Cc: David Vrabel david.vra...@citrix.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@redhat.com
Cc: H. Peter Anvin h...@zytor.com
Cc: x...@kernel.org
Cc: Steven
On Thu, Jan 22, 2015 at 4:29 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
From: Luis R. Rodriguez mcg...@suse.com
On kernels with voluntary or no preemption we can run
into situations where a hypercall issued through userspace
will linger around as it addresses sub-operatiosn in
://bugzilla.novell.com/show_bug.cgi?id=861093
[2]
http://ftp.suse.com/pub/people/mcgrof/xen/emulate-long-xen-hypercalls.patch
Based on original work by: David Vrabel david.vra...@citrix.com
Suggested-by: Andy Lutomirski l...@amacapital.net
Cc: Andy Lutomirski l...@amacapital.net
Cc: Borislav Petkov
On Thu, Jan 22, 2015 at 11:30 AM, Luis R. Rodriguez mcg...@suse.com wrote:
On Wed, Jan 21, 2015 at 07:07:36PM -0800, Andy Lutomirski wrote:
On Wed, Jan 21, 2015 at 6:17 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
From: Luis R. Rodriguez mcg...@suse.com
On kernels with voluntary
.
IMHO it may be more useful if we knew exactly what hypercalls were
being preempted but perhaps all that can be left as a secondary
exercise and for now I'll just nuke the print.
--
Andy Lutomirski
AMA Capital Management, LLC
___
Xen-devel mailing
On Thu, Jan 22, 2015 at 12:37 PM, Steven Rostedt rost...@goodmis.org wrote:
On Thu, 22 Jan 2015 12:24:47 -0800
Andy Lutomirski l...@amacapital.net wrote:
Also, please remove the notrace, because function tracing goes an
extra step to not require RCU being visible. The only thing you get
On Thu, Jan 22, 2015 at 1:16 PM, Steven Rostedt rost...@goodmis.org wrote:
On Thu, 22 Jan 2015 12:58:00 -0800
Andy Lutomirski l...@amacapital.net wrote:
On Thu, Jan 22, 2015 at 12:37 PM, Steven Rostedt rost...@goodmis.org wrote:
On Thu, 22 Jan 2015 12:24:47 -0800
Andy Lutomirski l
On Mon, Jan 5, 2015 at 11:17 AM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Mon, Jan 05, 2015 at 10:56:07AM -0800, Andy Lutomirski wrote:
On Mon, Jan 5, 2015 at 7:25 AM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Mon, Dec 22, 2014 at 04:39:57PM -0800, Andy Lutomirski wrote:
The pvclock
On Mon, Jan 5, 2015 at 2:48 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Mon, Jan 05, 2015 at 02:38:46PM -0800, Andy Lutomirski wrote:
On Mon, Jan 5, 2015 at 11:17 AM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Mon, Jan 05, 2015 at 10:56:07AM -0800, Andy Lutomirski wrote:
On Mon, Jan
On Tue, Jan 6, 2015 at 10:45 AM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Tue, Jan 06, 2015 at 10:26:22AM -0800, Andy Lutomirski wrote:
On Tue, Jan 6, 2015 at 10:13 AM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Tue, Jan 06, 2015 at 08:56:40AM -0800, Andy Lutomirski wrote:
On Jan 6
On Tue, Jan 6, 2015 at 9:38 PM, Paolo Bonzini pbonz...@redhat.com wrote:
On 06/01/2015 17:56, Andy Lutomirski wrote:
Still no good. We can migrate a bunch of times so we see the same CPU
all three times
There are no three times. The CPU you see here:
// ... compute nanoseconds
On Mon, Jan 5, 2015 at 7:25 AM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Mon, Dec 22, 2014 at 04:39:57PM -0800, Andy Lutomirski wrote:
The pvclock vdso code was too abstracted to understand easily and
excessively paranoid. Simplify it for a huge speedup.
This opens the door
On Tue, Jan 6, 2015 at 10:13 AM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Tue, Jan 06, 2015 at 08:56:40AM -0800, Andy Lutomirski wrote:
On Jan 6, 2015 4:01 AM, Paolo Bonzini pbonz...@redhat.com wrote:
On 06/01/2015 09:42, Paolo Bonzini wrote:
Still confused. So we can freeze
On Jan 6, 2015 4:01 AM, Paolo Bonzini pbonz...@redhat.com wrote:
On 06/01/2015 09:42, Paolo Bonzini wrote:
Still confused. So we can freeze all vCPUs in the host, then update
pvti 1, then resume vCPU 1, then update pvti 0? In that case, we have
a problem, because vCPU 1 can
On Fri, Mar 20, 2015 at 4:17 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
From: Luis R. Rodriguez mcg...@suse.com
When a system has PAT support enabled you don't need to be
using MTRRs. Andy had added arch_phys_wc_add() long ago to
help with this but not all drivers were converted
venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean
On Fri, Mar 20, 2015 at 4:17 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
From: Luis R. Rodriguez mcg...@suse.com
Ideally on systems using PAT we can expect a swift
transition away from MTRR. There can be a few exceptions
to this, one is where device drivers are known to exist
on
...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc
...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
() */
x86_64_start_reservations((char *)__pa_symbol(boot_params));
#endif
}
--
1.7.1
--
Andy Lutomirski
AMA Capital Management, LLC
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Thu, Jan 8, 2015 at 2:43 PM, Andy Lutomirski l...@amacapital.net wrote:
On Thu, Jan 8, 2015 at 2:31 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Tue, Jan 06, 2015 at 11:49:09AM -0800, Andy Lutomirski wrote:
On Tue, Jan 6, 2015 at 10:45 AM, Marcelo Tosatti mtosa...@redhat.com
wrote
On Fri, Mar 27, 2015 at 12:53 PM, Luis R. Rodriguez mcg...@suse.com wrote:
On Fri, Mar 20, 2015 at 04:48:46PM -0700, Andy Lutomirski wrote:
On Fri, Mar 20, 2015 at 4:17 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
From: Luis R. Rodriguez mcg...@suse.com
Ideally on systems using
On Fri, Mar 27, 2015 at 1:12 PM, Luis R. Rodriguez mcg...@suse.com wrote:
On Fri, Mar 20, 2015 at 04:52:18PM -0700, Andy Lutomirski wrote:
On Fri, Mar 20, 2015 at 4:17 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
diff --git a/drivers/video/fbdev/aty/atyfb_base.c
b/drivers/video
On Fri, Mar 27, 2015 at 2:56 PM, Ville Syrjälä syrj...@sci.fi wrote:
On Fri, Mar 27, 2015 at 08:57:59PM +0100, Luis R. Rodriguez wrote:
On Fri, Mar 27, 2015 at 12:43:55PM -0700, Andy Lutomirski wrote:
On Fri, Mar 27, 2015 at 12:38 PM, Luis R. Rodriguez mcg...@suse.com
wrote:
On Sat, Mar
On Fri, Mar 27, 2015 at 4:04 PM, Luis R. Rodriguez mcg...@suse.com wrote:
On Fri, Mar 27, 2015 at 02:23:16PM -0700, Andy Lutomirski wrote:
On Fri, Mar 27, 2015 at 1:30 PM, Luis R. Rodriguez mcg...@suse.com wrote:
On Fri, Mar 27, 2015 at 12:58:02PM -0700, Andy Lutomirski wrote:
On Fri, Mar 27
On Mar 26, 2015 6:32 AM, Boris Ostrovsky boris.ostrov...@oracle.com wrote:
On 03/06/2015 08:50 PM, Andy Lutomirski wrote:
I broke 32-bit kernels. The implementation of sp0 was correct as
far as I can tell, but sp0 was much weirder on x86_32 than I
realized. It has the following issues
On Wed, Apr 1, 2015 at 4:52 PM, Luis R. Rodriguez mcg...@suse.com wrote:
On Sat, Mar 28, 2015 at 02:23:34PM +0200, Ville Syrjälä wrote:
On Sat, Mar 28, 2015 at 01:28:18AM +0100, Luis R. Rodriguez wrote:
On Fri, Mar 27, 2015 at 03:02:10PM -0700, Andy Lutomirski wrote:
On Fri, Mar 27, 2015
On Thu, Apr 2, 2015 at 12:45 PM, Luis R. Rodriguez mcg...@suse.com wrote:
On Wed, Apr 01, 2015 at 05:04:08PM -0700, Andy Lutomirski wrote:
On Wed, Apr 1, 2015 at 4:52 PM, Luis R. Rodriguez mcg...@suse.com wrote:
On Sat, Mar 28, 2015 at 02:23:34PM +0200, Ville Syrjälä wrote:
On Sat, Mar 28
On 04/20/2015 10:09 AM, Andrew Cooper wrote:
There appears to be no formal statement of what pv_irq_ops.save_fl() is
supposed to return precisely. Native returns the full flags, while lguest and
Xen only return the Interrupt Flag, and both have comments by the
implementations stating that only
--
Andy Lutomirski
AMA Capital Management, LLC
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
measurements, I'd worry about the use popf to
clear IF case.
Fair enough. Maybe I'll benchmark this some day.
--Andy
Linus
--
Andy Lutomirski
AMA Capital Management, LLC
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http
On Thu, Apr 30, 2015 at 9:52 AM, Luis R. Rodriguez mcg...@suse.com wrote:
On Thu, Apr 30, 2015 at 10:59:17AM -0500, Bjorn Helgaas wrote:
[+cc linux-pci]
Hi Luis,
On Wed, Apr 29, 2015 at 02:36:08PM -0700, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
This allows
On Thu, Apr 30, 2015 at 12:30 PM, Boris Ostrovsky
boris.ostrov...@oracle.com wrote:
On 04/30/2015 03:17 PM, Andy Lutomirski wrote:
On Thu, Apr 30, 2015 at 12:08 PM, Boris Ostrovsky
boris.ostrov...@oracle.com wrote:
Commit 61f01dd941ba (x86_64, asm: Work around AMD SYSRET SS descriptor
On Thu, Apr 30, 2015 at 12:08 PM, Boris Ostrovsky
boris.ostrov...@oracle.com wrote:
Commit 61f01dd941ba (x86_64, asm: Work around AMD SYSRET SS descriptor
attribute issue) makes AMD processors set SS to __KERNEL_DS in
__switch_to() to deal with cases when SS is NULL.
This breaks Xen PV guests
On Mon, May 4, 2015 at 8:02 AM, Boris Ostrovsky
boris.ostrov...@oracle.com wrote:
Commit 61f01dd941ba (x86_64, asm: Work around AMD SYSRET SS descriptor
attribute issue) makes AMD processors set SS to __KERNEL_DS in
__switch_to() to deal with cases when SS is NULL.
This breaks Xen PV guests
On Mon, Apr 6, 2015 at 11:30 AM, Boris Ostrovsky
boris.ostrov...@oracle.com wrote:
On 04/06/2015 01:44 PM, Andrew Cooper wrote:
On 06/04/2015 16:29, Andy Lutomirski wrote:
On Mon, Apr 6, 2015 at 7:10 AM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com wrote:
On Fri, Apr 03, 2015 at 03:52
On Mon, Apr 6, 2015 at 7:10 AM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com wrote:
On Fri, Apr 03, 2015 at 03:52:30PM -0700, Andy Lutomirski wrote:
[cc: Boris and Konrad. Whoops]
On Fri, Apr 3, 2015 at 3:51 PM, Andy Lutomirski l...@kernel.org wrote:
We don't use irq_enable_sysexit on 64
On Jun 12, 2015 12:59 AM, Jan Beulich jbeul...@suse.com wrote:
On 12.06.15 at 01:23, toshi.k...@hp.com wrote:
There are two usages on MTRRs:
1) MTRR entries set by firmware
2) MTRR entries set by OS drivers
We can obsolete 2), but we have no control over 1). As UEFI firmwares
Let me try to summarize a proposal:
Add a feature flag that indicates IOMMU support.
New kernels acknowledge that flag on any device that advertises it.
New kernels always respect the IOMMU (except on PowerPC). New kernels
optionally refuse to talk to devices that don't have that feature flag
On Tue, Jul 28, 2015 at 10:10 AM, Boris Ostrovsky
boris.ostrov...@oracle.com wrote:
On 07/28/2015 01:07 PM, Andy Lutomirski wrote:
On Tue, Jul 28, 2015 at 9:30 AM, Andrew Cooper
andrew.coop...@citrix.com wrote:
I suspect that the set_ldt(NULL, 0) call hasn't reached Xen before
xen_free_ldt
On Tue, Jul 28, 2015 at 5:36 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Tue, 2015-07-28 at 16:33 -0700, Andy Lutomirski wrote:
On Tue, Jul 28, 2015 at 4:21 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Tue, 2015-07-28 at 15:43 -0700, Andy Lutomirski wrote
On Wed, Jul 29, 2015 at 2:37 PM, Andrew Cooper
andrew.coop...@citrix.com wrote:
On 29/07/2015 22:26, Andy Lutomirski wrote:
On Wed, Jul 29, 2015 at 2:23 PM, Boris Ostrovsky
boris.ostrov...@oracle.com wrote:
On 07/29/2015 03:03 PM, Andrew Cooper wrote:
On 29/07/15 15:43, Boris Ostrovsky wrote
On Wed, Jul 29, 2015 at 2:23 PM, Boris Ostrovsky
boris.ostrov...@oracle.com wrote:
On 07/29/2015 03:03 PM, Andrew Cooper wrote:
On 29/07/15 15:43, Boris Ostrovsky wrote:
FYI, I have got a repro now and am investigating.
Good and bad news. This bug has nothing to do with LDTs themselves.
On Thu, Jul 30, 2015 at 11:35 AM, Boris Ostrovsky
boris.ostrov...@oracle.com wrote:
On 07/30/2015 02:14 PM, Andy Lutomirski wrote:
On Thu, Jul 30, 2015 at 10:56 AM, Boris Ostrovsky
boris.ostrov...@oracle.com wrote:
On 07/28/2015 01:29 AM, Andy Lutomirski wrote:
+
+static inline void
this
patch, the test can OOPS, but it's much less likely to happen. The
Xen maintainers should have a fix for that issue shortly.
Cc: sta...@vger.kernel.org
Reviewed-by: Borislav Petkov b...@suse.de
Signed-off-by: Andy Lutomirski l...@kernel.org
---
arch/x86/include/asm/desc.h| 15
The modify_ldt syscall exposes a large attack surface and is
unnecessary for modern userspace. Make it optional.
Reviewed-by: Kees Cook keesc...@chromium.org
Signed-off-by: Andy Lutomirski l...@kernel.org
---
arch/x86/Kconfig | 17 +
arch/x86/include/asm/mmu.h
case is new.
- Fixed a missing allocation failure check.
- Fixed a use-after-free on fork().
Andy Lutomirski (4):
x86/xen: Probe target addresses in set_aliased_prot before the
hypercall
x86/ldt: Make modify_ldt synchronous
selftests/x86, x86/ldt: Add a selftest for modify_ldt
x86/ldt
. This code should probably be
changed to use something like set_memory_ro.
Cc: sta...@vger.kernel.org
Cc: Andrew Cooper andrew.coop...@citrix.com
Cc: Boris Ostrovsky boris.ostrov...@oracle.com
Cc: David Vrabel dvra...@cantab.net
Signed-off-by: Andy Lutomirski l...@kernel.org
---
arch/x86/xen
On Thu, Jul 30, 2015 at 1:01 PM, Boris Ostrovsky
boris.ostrov...@oracle.com wrote:
On 07/30/2015 02:54 PM, Andrew Cooper wrote:
On 30/07/15 19:30, Andy Lutomirski wrote:
On Wed, Jul 29, 2015 at 5:29 PM, Andrew Cooper
andrew.coop...@citrix.com wrote:
On 30/07/2015 00:13, Andy Lutomirski
On Thu, Jul 30, 2015 at 3:50 PM, Andrew Cooper
andrew.coop...@citrix.com wrote:
On 30/07/2015 22:31, Andy Lutomirski wrote:
Note to -stable maintainers: by itself, this patch makes a
pre-existing Xen bug much easier to trigger; on a 32-bit Xen guest,
the new ldt_gdt selftest is likely to OOPS
On Jul 28, 2015 3:30 AM, Andrew Cooper andrew.coop...@citrix.com wrote:
On 28/07/15 04:16, Andy Lutomirski wrote:
On Mon, Jul 27, 2015 at 7:20 PM, Andy Lutomirski l...@amacapital.net
wrote:
On Mon, Jul 27, 2015 at 9:18 AM, Boris Ostrovsky
boris.ostrov...@oracle.com wrote:
On 07/27
On Tue, Jul 28, 2015 at 9:44 AM, Jan Kiszka jan.kis...@siemens.com wrote:
The ability to have virtio on systems with IOMMU in place makes testing
much more efficient for us. Ideally, we would have it in non-identity
mapping scenarios as well, e.g. to start secondary Linux instances in
the test
. I'm pretty
sure that set_ldt really is clearing at least LDT entry zero.
Nonetheless the free_ldt call still oopses.
--Andy
~Andrew
--
Andy Lutomirski
AMA Capital Management, LLC
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http
On Tue, Jul 28, 2015 at 10:17 AM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2015-07-28 19:10, Andy Lutomirski wrote:
The trouble is that this is really a property of the bus and not of
the device. If you build a virtio device that physically plugs into a
PCIe slot, the device has no concept
On Tue, Jul 28, 2015 at 12:06 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2015-07-28 20:22, Andy Lutomirski wrote:
On Tue, Jul 28, 2015 at 10:17 AM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2015-07-28 19:10, Andy Lutomirski wrote:
The trouble is that this is really a property of the bus
On Tue, Jul 28, 2015 at 12:33 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2015-07-28 21:24, Andy Lutomirski wrote:
On Tue, Jul 28, 2015 at 12:06 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2015-07-28 20:22, Andy Lutomirski wrote:
On Tue, Jul 28, 2015 at 10:17 AM, Jan Kiszka jan.kis
On Mon, Aug 3, 2015 at 11:23 AM, Willy Tarreau w...@1wt.eu wrote:
The new function is proc_dointvec_minmax_negperm(), it refuses to change
the value if the current one is already negative. This will be used to
lock down some settings such as sensitive system calls.
Signed-off-by: Willy
, and proposes to temporarily disable it by default. This can be
a safe alternative. A message is logged if an attempt was stopped so that
it's easy to spot if/when it is needed.
Cc: Andy Lutomirski l...@kernel.org
Cc: Kees Cook keesc...@chromium.org
Signed-off-by: Willy Tarreau w...@1wt.eu
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 non
On Wed, Jul 29, 2015 at 5:29 PM, Andrew Cooper
andrew.coop...@citrix.com wrote:
On 30/07/2015 00:13, Andy Lutomirski wrote:
On Wed, Jul 29, 2015 at 4:02 PM, Andrew Cooper
andrew.coop...@citrix.com wrote:
On 29/07/2015 23:49, Boris Ostrovsky wrote:
On 07/29/2015 06:46 PM, David Vrabel wrote
On Wed, Jul 29, 2015 at 4:02 PM, Andrew Cooper
andrew.coop...@citrix.com wrote:
On 29/07/2015 23:49, Boris Ostrovsky wrote:
On 07/29/2015 06:46 PM, David Vrabel wrote:
On 29/07/2015 23:11, Andrew Cooper wrote:
On 29/07/2015 23:05, Andy Lutomirski wrote:
On Wed, Jul 29, 2015 at 2:37 PM
On Tue, Jul 28, 2015 at 4:21 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Tue, 2015-07-28 at 15:43 -0700, Andy Lutomirski wrote:
Let me try to summarize a proposal:
Add a feature flag that indicates IOMMU support.
New kernels acknowledge that flag on any device
On Thu, Aug 13, 2015 at 5:44 PM, gre...@linuxfoundation.org wrote:
This is a note to let you know that I've just added the patch titled
x86/ldt: Make modify_ldt synchronous
This needs:
On Mon, Aug 10, 2015 at 3:12 AM, Ben Hutchings b...@decadent.org.uk wrote:
3.2.71-rc1 review patch. If anyone has any objections, please let me know.
--
From: Andy Lutomirski l...@kernel.org
commit 37868fe113ff2ba814b3b4eb12df214df555f8dc upstream.
Unfortunately
On Mon, Jul 27, 2015 at 8:36 AM, Boris Ostrovsky
boris.ostrov...@oracle.com wrote:
On 07/25/2015 01:36 AM, Andy Lutomirski wrote:
Here's v3. It fixes the dazed and confused issue, I hope. It's also
probably a good general attack surface reduction, and it replaces some
scary code with IMO
On Mon, Jul 27, 2015 at 9:18 AM, Boris Ostrovsky
boris.ostrov...@oracle.com wrote:
On 07/27/2015 11:53 AM, Andy Lutomirski wrote:
On Mon, Jul 27, 2015 at 8:36 AM, Boris Ostrovsky
boris.ostrov...@oracle.com wrote:
On 07/25/2015 01:36 AM, Andy Lutomirski wrote:
Here's v3. It fixes the dazed
On Mon, Sep 1, 2014 at 10:39 AM, Andy Lutomirski l...@amacapital.net wrote:
This fixes virtio on Xen guests as well as on any other platform
that uses virtio_pci on which physical addresses don't match bus
addresses.
This can be tested with:
virtme-run --xen xen --kimg arch/x86/boot
The modify_ldt syscall exposes a large attack surface and is
unnecessary for modern userspace. Make it optional.
Signed-off-by: Andy Lutomirski l...@kernel.org
---
arch/x86/Kconfig | 17 +
arch/x86/include/asm/mmu.h | 2 ++
arch/x86/include/asm
This tests general modify_ldt behavior (only writes, so far) as
well as synchronous updates via IPI. It fails on old kernels.
I called this ldt_gdt because I'll add set_thread_area tests to
it at some point.
Signed-off-by: Andy Lutomirski l...@kernel.org
---
tools/testing/selftests/x86
to more
aggressively reallocate the LDT, the OOPSes become much more common
without this fix.
Cc: sta...@vger.kernel.org
Signed-off-by: Andy Lutomirski l...@kernel.org
---
arch/x86/xen/enlighten.c | 12
1 file changed, 12 insertions(+)
diff --git a/arch/x86/xen/enlighten.c b/arch
an in-use LDT. (Xen people, can you check?)
Changes from v1:
- The config option is new.
- The test case is new.
- Fixed a missing allocation failure check.
- Fixed a use-after-free on fork().
Andy Lutomirski (4):
x86/xen: Unmap aliases in xen_alloc_ldt and xen_free_ldt
x86/ldt: Make
that
care about modify_ldt's performance in the first place.
Cc: sta...@vger.kernel.org
Signed-off-by: Andy Lutomirski l...@kernel.org
---
arch/x86/include/asm/desc.h| 15 ---
arch/x86/include/asm/mmu.h | 3 +-
arch/x86/include/asm/mmu_context.h | 53 +++-
arch/x86/kernel/cpu
On Mon, Jul 27, 2015 at 8:16 PM, Andy Lutomirski l...@amacapital.net wrote:
On Mon, Jul 27, 2015 at 7:20 PM, Andy Lutomirski l...@amacapital.net wrote:
On Mon, Jul 27, 2015 at 9:18 AM, Boris Ostrovsky
boris.ostrov...@oracle.com wrote:
On 07/27/2015 11:53 AM, Andy Lutomirski wrote:
On Mon
On Thu, Jul 23, 2015 at 4:36 PM, Kees Cook keesc...@chromium.org wrote:
On Thu, Jul 23, 2015 at 3:24 AM, Willy Tarreau w...@1wt.eu wrote:
#ifdef CONFIG_SMP
static void flush_ldt(void *current_mm)
{
@@ -254,6 +260,9 @@ asmlinkage int sys_modify_ldt(int func, void __user *ptr,
{
that
care about modify_ldt's performance in the first place.
Cc: sta...@vger.kernel.org
Signed-off-by: Andy Lutomirski l...@kernel.org
---
arch/x86/include/asm/desc.h| 15 ---
arch/x86/include/asm/mmu.h | 3 +-
arch/x86/include/asm/mmu_context.h | 53 +++-
arch/x86/kernel/cpu
This tests general modify_ldt behavior (only writes, so far) as
well as synchronous updates via IPI. It fails on old kernels.
I called this ldt_gdt because I'll add set_thread_area tests to
it at some point.
Signed-off-by: Andy Lutomirski l...@kernel.org
---
tools/testing/selftests/x86
option is new.
- The test case is new.
- Fixed a missing allocation failure check.
- Fixed a use-after-free on fork().
Andy Lutomirski (3):
x86/ldt: Make modify_ldt synchronous
x86/ldt: Make modify_ldt optional
selftests/x86, x86/ldt: Add a selftest for modify_ldt
arch/x86/Kconfig
On Sun, Jul 26, 2015 at 12:34 PM, Andrew Cooper
andrew.coop...@citrix.com wrote:
On 23/07/2015 17:49, Andy Lutomirski wrote:
Hi-
Hi. Apologies for the delay. I have been out of the office for a few days.
In entry_64.S, we have:
ENTRY(entry_SYSCALL_64)
/*
* Interrupts are off
an
annoying corner case in which an IRQ can be delivered with a
hardware frame that overlaps current_pt_regs.
Signed-off-by: Andy Lutomirski l...@kernel.org
---
arch/x86/entry/entry_64.S| 20 ++--
arch/x86/entry/entry_64_compat.S | 10 ++
2 files changed, 20 insertions
Xen's SYSCALL hooks are overcomplicated and add unnecessary places
where RSP is user controlled. Simplify it and get rid of those user
RSP code paths under Xen.
Tested as an Intel KVM guest. Not tested under Xen or on AMD, both
of which are important.
Andy Lutomirski (2):
x86/entry/64
Xen's raw SYSCALL entries are much less weird than native. Rather
than fudging them to look like native entries, use the Xen-provided
stack frame directly.
This lets us eliminate entry_SYSCALL_64_after_swapgs and two uses
of the SWAPGS_UNSAFE_STACK paravirt hook.
Signed-off-by: Andy Lutomirski
On Sun, Jul 26, 2015 at 4:05 PM, Andrew Cooper
andrew.coop...@citrix.com wrote:
On 26/07/2015 23:08, Andy Lutomirski wrote:
If so, can we just
enter later on:
pushq%r11/* pt_regs-flags */
pushq$__USER_CS/* pt_regs-cs */
pushq%rcx
On Tue, Jul 21, 2015 at 5:21 PM, Andrew Cooper
andrew.coop...@citrix.com wrote:
On 22/07/2015 01:07, Andy Lutomirski wrote:
On Tue, Jul 21, 2015 at 4:38 PM, Andrew Cooper
andrew.coop...@citrix.com wrote:
On 21/07/2015 22:53, Boris Ostrovsky wrote:
On 07/21/2015 03:59 PM, Andy Lutomirski wrote
On Tue, Jul 21, 2015 at 5:49 PM, Andrew Cooper
andrew.coop...@citrix.com wrote:
On 22/07/2015 01:28, Andy Lutomirski wrote:
On Tue, Jul 21, 2015 at 5:21 PM, Andrew Cooper
andrew.coop...@citrix.com wrote:
On 22/07/2015 01:07, Andy Lutomirski wrote:
On Tue, Jul 21, 2015 at 4:38 PM, Andrew
On Tue, Jul 21, 2015 at 7:04 PM, Boris Ostrovsky
boris.ostrov...@oracle.com wrote:
On 07/21/2015 08:49 PM, Andrew Cooper wrote:
On 22/07/2015 01:28, Andy Lutomirski wrote:
On Tue, Jul 21, 2015 at 5:21 PM, Andrew Cooper
andrew.coop...@citrix.com wrote:
On 22/07/2015 01:07, Andy Lutomirski
On Sat, Jul 25, 2015 at 9:33 AM, Willy Tarreau w...@1wt.eu wrote:
On Sat, Jul 25, 2015 at 09:08:39AM -0700, Andy Lutomirski wrote:
There's one thing that I think is incomplete here. Currently, espfix
triggers if SS points to the LDT. It's possible for SS to point to
the LDT even
On Sat, Jul 25, 2015 at 2:15 AM, Borislav Petkov b...@alien8.de wrote:
On Fri, Jul 24, 2015 at 10:36:45PM -0700, Andy Lutomirski wrote:
The modify_ldt syscall exposes a large attack surface and is
unnecessary for modern userspace. Make it optional.
Signed-off-by: Andy Lutomirski l
On Sat, Jul 25, 2015 at 6:03 AM, Willy Tarreau w...@1wt.eu wrote:
On Sat, Jul 25, 2015 at 09:50:52AM +0200, Willy Tarreau wrote:
On Fri, Jul 24, 2015 at 11:44:52PM -0700, Andy Lutomirski wrote:
I'm all for it, but I think it should be hard-disablable in config,
too, for the -tiny people.
I
On Fri, Jul 24, 2015 at 11:23 PM, Willy Tarreau w...@1wt.eu wrote:
On Fri, Jul 24, 2015 at 10:36:45PM -0700, Andy Lutomirski wrote:
The modify_ldt syscall exposes a large attack surface and is
unnecessary for modern userspace. Make it optional.
Andy, you didn't respond whether you think
On Tue, Jul 21, 2015 at 4:38 PM, Andrew Cooper
andrew.coop...@citrix.com wrote:
On 21/07/2015 22:53, Boris Ostrovsky wrote:
On 07/21/2015 03:59 PM, Andy Lutomirski wrote:
--- a/arch/x86/include/asm/mmu_context.h
+++ b/arch/x86/include/asm/mmu_context.h
@@ -34,6 +34,44 @@ static inline void
On Fri, Jul 24, 2015 at 8:29 AM, Borislav Petkov b...@alien8.de wrote:
Let it stick out:
if (!cpumask_equal(mm_cpumask(current_mm),
cpumask_of(smp_processor_id(
smp_call_function(flush_ldt, current_mm, 1);
I see your wide terminal and raise you a complete rewrite
On Fri, Jul 24, 2015 at 9:13 PM, Boris Ostrovsky
boris.ostrov...@oracle.com wrote:
On 07/22/2015 06:20 PM, Boris Ostrovsky wrote:
On 07/22/2015 03:23 PM, Andy Lutomirski wrote:
+error = -ENOMEM;
+new_ldt = alloc_ldt_struct(newsize);
+if (!new_ldt)
goto out_unlock
The modify_ldt syscall exposes a large attack surface and is
unnecessary for modern userspace. Make it optional.
Signed-off-by: Andy Lutomirski l...@kernel.org
---
arch/x86/Kconfig | 17 +
arch/x86/include/asm/mmu.h | 2 ++
arch/x86/include/asm
that
care about modify_ldt's performance in the first place.
Cc: sta...@vger.kernel.org
Signed-off-by: Andy Lutomirski l...@kernel.org
---
arch/x86/include/asm/desc.h| 15 ---
arch/x86/include/asm/mmu.h | 3 +-
arch/x86/include/asm/mmu_context.h | 53 +++-
arch/x86/kernel/cpu
1 - 100 of 345 matches
Mail list logo
