Il 08/04/2013 23:59, Anthony Liguori ha scritto:
This patch refactors existing virtio-scsi code into VirtIOSCSICommon
in order to allow virtio_scsi_init_common() to be used by both internal
virtio_scsi_init() and external vhost-scsi-pci code.
Changes in Patch-v2:
- Move
Il 09/04/2013 06:33, Nicholas A. Bellinger ha scritto:
Nicholas, where is the latest v3 code. Can you push it to your tree.
Sure. Just pushed to:
http://git.kernel.org/cgit/virt/kvm/nab/qemu-kvm.git/log/?h=vhost-scsi-for-1.4
and should be appearing momentarily.
I'm going to test my
Asias He (3):
tcm_vhost: Introduce tcm_vhost_check_feature()
tcm_vhost: Add helper to check if endpoint is setup
tcm_vhost: Add hotplug/hotunplug support
drivers/vhost/tcm_vhost.c | 236 +-
drivers/vhost/tcm_vhost.h | 10 ++
2 files changed, 242
This helper is useful to check if a feature is supported.
Signed-off-by: Asias He as...@redhat.com
Reviewed-by: Stefan Hajnoczi stefa...@redhat.com
---
drivers/vhost/tcm_vhost.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/vhost/tcm_vhost.c
Signed-off-by: Asias He as...@redhat.com
---
drivers/vhost/tcm_vhost.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/vhost/tcm_vhost.c b/drivers/vhost/tcm_vhost.c
index f0189bc..7069881 100644
--- a/drivers/vhost/tcm_vhost.c
+++ b/drivers/vhost/tcm_vhost.c
@@
In commit 365a7150094 ([SCSI] virtio-scsi: hotplug support for
virtio-scsi), hotplug support is added to virtio-scsi.
This patch adds hotplug and hotunplug support to tcm_vhost.
You can create or delete a LUN in targetcli to hotplug or hotunplug a
LUN in guest.
Changes in v5:
- Switch to int
If we fail to submit the allocated tv_vmd to tcm_vhost_submission_work,
we will leak the tv_vmd. Free tv_vmd on fail path.
Signed-off-by: Asias He as...@redhat.com
---
drivers/vhost/tcm_vhost.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git
H. Peter Anvin h...@zytor.com writes:
On 04/08/2013 03:43 PM, Kees Cook wrote:
This makes the IDT unconditionally read-only. This primarily removes
the IDT from being a target for arbitrary memory write attacks. It has
an added benefit of also not leaking (via the sidt instruction) the
On Mon, 8 Apr 2013, H. Peter Anvin wrote:
On 04/08/2013 03:43 PM, Kees Cook wrote:
This makes the IDT unconditionally read-only. This primarily removes
the IDT from being a target for arbitrary memory write attacks. It has
an added benefit of also not leaking (via the sidt instruction) the
Make a copy of the IDT (as seen via the sidt instruction) read-only.
This primarily removes the IDT from being a target for arbitrary memory
write attacks, and has the added benefit of also not leaking the kernel
base offset, if it has been relocated.
Signed-off-by: Kees Cook
On Tue, Apr 9, 2013 at 2:23 AM, Thomas Gleixner t...@linutronix.de wrote:
On Mon, 8 Apr 2013, H. Peter Anvin wrote:
On 04/08/2013 03:43 PM, Kees Cook wrote:
This makes the IDT unconditionally read-only. This primarily removes
the IDT from being a target for arbitrary memory write attacks.
On 04/09/2013 11:22 AM, Kees Cook wrote:
$ ./sgdt
88001fc04000
# cat /sys/kernel/debug/kernel_page_tables
...
---[ Low Kernel Mapping ]---
...
0x880001e0-0x88001fe0 480M RW PSE GLB NX
pmd
That is the 1:1 memory map area...
-hpa
--
H.
On Tue, Apr 9, 2013 at 11:26 AM, H. Peter Anvin h...@zytor.com wrote:
On 04/09/2013 11:22 AM, Kees Cook wrote:
$ ./sgdt
88001fc04000
# cat /sys/kernel/debug/kernel_page_tables
...
---[ Low Kernel Mapping ]---
...
0x880001e0-0x88001fe0 480M RW PSE
On 04/09/2013 11:31 AM, Kees Cook wrote:
...
0x880001e0-0x88001fe0 480M RW PSE GLB
NX pmd
That is the 1:1 memory map area...
Meaning what?
-Kees
That's the area in which we just map 1:1 to memory. Anything allocated
with e.g. kmalloc() ends up
On Tue, Apr 9, 2013 at 11:39 AM, H. Peter Anvin h...@zytor.com wrote:
On 04/09/2013 11:31 AM, Kees Cook wrote:
...
0x880001e0-0x88001fe0 480M RW PSE GLB
NX pmd
That is the 1:1 memory map area...
Meaning what?
-Kees
That's the area in which we just
On Tue, Apr 9, 2013 at 11:50 AM, H. Peter Anvin h...@zytor.com wrote:
On 04/09/2013 11:46 AM, Kees Cook wrote:
Ah-ha! Yes, I see now when comparing the debug/kernel_page_tables
reports. It's just the High Kernel Mapping that we care about.
Addresses outside that range are less of a leak.
On 04/09/2013 11:46 AM, Kees Cook wrote:
Ah-ha! Yes, I see now when comparing the debug/kernel_page_tables
reports. It's just the High Kernel Mapping that we care about.
Addresses outside that range are less of a leak. Excellent, then GDT
may not be a problem. Whew.
It does beg the
On 04/09/2013 11:54 AM, Eric Northup wrote:
The GDT is a problem if the address returned by 'sgdt' is
kernel-writable - it doesn't necessarily reveal the random offset, but
I'm pretty sure that writing to the GDT could cause privilege
escalation.
That is a pretty safe assumption...
Implement the vringh callback functions in order
to manage host virito rings and handle kicks.
This allows virtio device to request host-virtio-rings.
Signed-off-by: Sjur Brændeland sjur.brandel...@stericsson.com
---
Hi Ohad and Rusty,
This v2 version is simpler, more readable and verbose (+50
On 04/09/2013 11:22 AM, Kees Cook wrote:
Can we create a RO fixed per-cpu area?
Fixed and percpu are mutually exclusive...
-hpa
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
On 04/09/2013 09:39 AM, Kees Cook wrote:
-
static void __cpuinit intel_smp_check(struct cpuinfo_x86 *c)
{
/* calling is from identify_secondary_cpu() ? */
@@ -206,8 +192,7 @@ static void __cpuinit intel_workarounds(struct
cpuinfo_x86 *c)
/*
* All current models of
On Tue, Apr 9, 2013 at 5:14 PM, H. Peter Anvin h...@zytor.com wrote:
On 04/09/2013 09:39 AM, Kees Cook wrote:
-
static void __cpuinit intel_smp_check(struct cpuinfo_x86 *c)
{
/* calling is from identify_secondary_cpu() ? */
@@ -206,8 +192,7 @@ static void __cpuinit
OK, thinking about the GDT here.
The GDT is quite small -- 256 bytes on i386, 128 bytes on x86-64. As
such, we probably don't want to allocate a full page to it for only
that. This means that in order to create a readonly mapping we have to
pack GDTs from different CPUs together in the same
On Tue, 2013-04-09 at 17:43 -0700, H. Peter Anvin wrote:
OK, thinking about the GDT here.
The GDT is quite small -- 256 bytes on i386, 128 bytes on x86-64. As
such, we probably don't want to allocate a full page to it for only
that. This means that in order to create a readonly mapping we
On 04/09/2013 05:53 PM, Steven Rostedt wrote:
On Tue, 2013-04-09 at 17:43 -0700, H. Peter Anvin wrote:
OK, thinking about the GDT here.
The GDT is quite small -- 256 bytes on i386, 128 bytes on x86-64. As
such, we probably don't want to allocate a full page to it for only
that. This means
Asias He (3):
tcm_vhost: Fix tv_cmd leak in vhost_scsi_handle_vq
tcm_vhost: Add vhost_scsi_send_bad_target() helper
tcm_vhost: Send bad target to guest when cmd fails
drivers/vhost/tcm_vhost.c | 44
1 file changed, 28 insertions(+), 16
Share the send bad target code with other use cases.
Signed-off-by: Asias He as...@redhat.com
---
drivers/vhost/tcm_vhost.c | 31 ++-
1 file changed, 18 insertions(+), 13 deletions(-)
diff --git a/drivers/vhost/tcm_vhost.c b/drivers/vhost/tcm_vhost.c
index
Send bad target to guest in case:
1) we can not allocate the cmd
2) fail to submit the cmd
Signed-off-by: Asias He as...@redhat.com
---
drivers/vhost/tcm_vhost.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/vhost/tcm_vhost.c b/drivers/vhost/tcm_vhost.c
On Tue, Apr 09, 2013 at 08:46:42AM -0700, Nicholas A. Bellinger wrote:
On Tue, 2013-04-09 at 17:16 +0800, Asias He wrote:
If we fail to submit the allocated tv_vmd to tcm_vhost_submission_work,
we will leak the tv_vmd. Free tv_vmd on fail path.
Signed-off-by: Asias He as...@redhat.com
29 matches
Mail list logo
