On Wed, Apr 10, 2013 at 11:23:08AM +0800, Asias He wrote:
> 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 +++
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
> > ---
>
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
---
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
index 1c719ed..4dc
Share the send bad target code with other use cases.
Signed-off-by: Asias He
---
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 e8d1a1f..1c719ed 100644
---
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
---
drivers/vhost/tcm_vhost.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/vhost/tcm_vhost.c b/drivers/vhost/
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 deletions(
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. T
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
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 page
On Tue, Apr 9, 2013 at 5:14 PM, H. Peter Anvin 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 intel_workarounds(stru
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
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
https://lists.linuxfoundation
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
---
Hi Ohad and Rusty,
This v2 version is simpler, more readable and verbose (+50 lines)
compared to the previous
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...
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 q
On Tue, Apr 9, 2013 at 11:46 AM, Kees Cook wrote:
> On Tue, Apr 9, 2013 at 11:39 AM, H. Peter Anvin 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
On Tue, Apr 9, 2013 at 11:50 AM, H. Peter Anvin 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. Excellent,
On Tue, Apr 9, 2013 at 11:39 AM, H. Peter Anvin 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 a
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.
On Tue, Apr 9, 2013 at 11:26 AM, H. Peter Anvin 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: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...
-hp
On Tue, Apr 9, 2013 at 2:23 AM, Thomas Gleixner 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. It has
>>
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
Cc: Eric Northup
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
> ---
> drivers/vhost/tcm_vhost.c | 11 ---
> 1 file changed, 8 insertions(+), 3 d
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" instruct
"H. Peter Anvin" 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
>> kernel
This patch makes vhost_scsi_flush() wait for all the pending requests
issued before the flush operation to be finished.
Changes in v3:
- Rebase
- Drop 'tcm_vhost: Wait for pending requests in
vhost_scsi_clear_endpoint()' in this series, we already did that in
'tcm_vhost: Use vq->private_data t
On Tue, Apr 09, 2013 at 05:16:33PM +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
Another one for 3.9 I think.
Acked-by: Michael S. Tsirkin
> ---
> drivers/vhost
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
---
drivers/vhost/tcm_vhost.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/vhost/tcm_vhost.c b/drivers/vho
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 fro
Signed-off-by: Asias He
---
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
@@ -111,6 +111,24 @@ st
This helper is useful to check if a feature is supported.
Signed-off-by: Asias He
Reviewed-by: Stefan Hajnoczi
---
drivers/vhost/tcm_vhost.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/vhost/tcm_vhost.c b/drivers/vhost/tcm_vhost.c
index c127731..f0189bc 100644
---
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
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 t
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 -
35 matches
Mail list logo
