Following up with my previous threads on KVM assisted Anti rootkit
protections.
The current version doesn't address the attacks involving pages
remapping. It is still design in progress, nevertheless, it will be in
my later patch sets.
Signed-off-by: Ahmed Abd El Mawgood
---
Here is change log from V3 To V4:
- Fixing spelling/grammar mistakes suggested by Randy Dunlap
- Changing the hypercall interface to be able to process multiple pages
per one hypercall also suggested by Randy Dunlap. It turns out that
this will save lots of vmexist/memory slot flushes when
This patch introduces a hypercall implemented for X86 that can assist
against subset of kernel rootkits, it works by place readonly protection in
shadow PTE. The end result protection is also kept in a bitmap for each
kvm_memory_slot and is used as reference when updating SPTEs. The whole
goal is
This will help sharing data into the slot_level_handler callback. In my
case I need to a share a counter for the pages traversed to use it in some
bitmap. Being able to send arbitrary memory pointer into the
slot_level_handler callback made it easy.
Signed-off-by: Ahmed Abd El Mawgood
---
flight 125428 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125428/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 123814
build-i386-libvirt
Add --replace-escape, -e option to xenconsoled, which replaces ESC with
'.' in console output written to log file. This makes it slightly safer
to do tail -f on a console output of untrusted guest.
The pty output is unaffected by this option.
Signed-off-by: Marek Marczykowski-Górecki
---
Is
On Mon, 16 Jul 2018 13:50:58 +0200 Michal Hocko wrote:
> From: Michal Hocko
>
> There are several blockable mmu notifiers which might sleep in
> mmu_notifier_invalidate_range_start and that is a problem for the
> oom_reaper because it needs to guarantee a forward progress so it cannot
> depend
flight 125416 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125416/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stopfail REGR. vs. 124248
On Tue, 17 Jul 2018 10:12:01 +0200 Michal Hocko wrote:
> > Any suggestions regarding how the driver developers can test this code
> > path? I don't think we presently have a way to fake an oom-killing
> > event? Perhaps we should add such a thing, given the problems we're
> > having with that
flight 125478 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125478/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf f3702a5d29e94814991988bf8747341e18a2e8f5
baseline version:
xtf
Exclude named output files from the Xen tree setup.
The linkfarm.stamp content will differ between top level "make"
and "make install" invocations, due to the introduction of these
output files that are produced during the "make" build.
Filter these out to prevent an unnecessary rebuild of the
flight 125410 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125410/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl 10 debian-install fail REGR. vs. 125169
Tests which are
flight 125401 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125401/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm 12 guest-start fail REGR. vs. 123554
On 07/20/2018 08:18 PM, George Dunlap wrote:
> Furthermore, imagine the following scenario:
>
> * dom0 enables altp2m on domain A
> * dom0 switches altp2m to view 1 on domain A
> * dom0 enables #VE on domain A
> * domain A has a vmexit
> -> At this point, EPTP_INDEX is 0, so the vmexit code
On 07/20/2018 05:29 PM, Razvan Cojocaru wrote:
> On 07/20/2018 06:07 PM, George Dunlap wrote:
>> On 06/28/2018 03:35 PM, Razvan Cojocaru wrote:
>>> A VM exit handler executed immediately after enabling #VE might
>>> find a stale __vmsave()d EPTP_INDEX, stored by calling
>>> altp2m_vcpu_destroy()
On 07/20/2018 05:33 PM, Vitaly Kuznetsov wrote:
Commit f599c64fdf7d ("xen-netfront: Fix race between device setup and
open") changed the initialization order: xennet_create_queues() now
happens before we do register_netdev() so using netdev->name in
xennet_init_queue() is incorrect, we end up
Commit f599c64fdf7d ("xen-netfront: Fix race between device setup and
open") changed the initialization order: xennet_create_queues() now
happens before we do register_netdev() so using netdev->name in
xennet_init_queue() is incorrect, we end up with the following in
/proc/interrupts:
60:
On 07/20/2018 06:07 PM, George Dunlap wrote:
> On 06/28/2018 03:35 PM, Razvan Cojocaru wrote:
>> A VM exit handler executed immediately after enabling #VE might
>> find a stale __vmsave()d EPTP_INDEX, stored by calling
>> altp2m_vcpu_destroy() when SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS
>> had been
On 06/28/2018 03:35 PM, Razvan Cojocaru wrote:
> A VM exit handler executed immediately after enabling #VE might
> find a stale __vmsave()d EPTP_INDEX, stored by calling
> altp2m_vcpu_destroy() when SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS
> had been enabled by altp2m_vcpu_update_vmfunc_ve().
>
>
This series of patches is for enabling SSBD via the LS_CFG MSR for
family 15h-17h. The first patch make it so that the information is
correctly displayed on boot. The last two patches are for further
enablement for Xen switching SSBD on or off internally, or for further
control of SSBD for
In preparation for adding switchable SSBD, add some defines and
variables.
Signed-off-by: Brian Woods
---
xen/arch/x86/spec_ctrl.c| 10 ++
xen/include/asm-x86/spec_ctrl.h | 3 +++
2 files changed, 13 insertions(+)
diff --git a/xen/arch/x86/spec_ctrl.c
Edit the initialization code for AMD's SSBD via the LS_CFG MSR and
enable it to pass the status to the initial spec-ctrl print_details at
boot.
Signed-off-by: Brian Woods
---
xen/arch/x86/cpu/amd.c| 13 ++---
xen/arch/x86/spec_ctrl.c | 9 +++--
Adds support for modifying the LS_CFG MSR to enable SSBD on supporting
AMD CPUs. There needs to be locking logic for family 17h with SMT
enabled since both threads share the same MSR. Otherwise, a core just
needs to write to the LS_CFG MSR. For more information see:
flight 125473 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125473/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On 07/20/2018 05:01 AM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> This work is in response to my previous attempt to introduce Xen/DRM
> zero-copy driver [1] to enable Linux dma-buf API [2] for Xen based
> frontends/backends. There is also an existing hyper_dmabuf
> I will absolutely nack any interface where if the caller says,
> "Please
> remove read permission", the hypervisor says, "OK!" but then allows
> read
> permission anyway -- particularly in one which is allegedly designed
> for
> security tools.
>
> If it's not practical / more work than it's
flight 125467 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125467/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-freebsd 7 freebsd-buildfail REGR. vs. 125317
Tests which did
flight 125463 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125463/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 125432
Tests which
On 20/07/18 11:13, Roger Pau Monné wrote:
> On Fri, Jul 20, 2018 at 02:29:34AM -0700, Zhenzhong Duan wrote:
>> No functional change.
>>
>> Signed-off-by: Zhenzhong Duan
>> ---
>> xen/arch/x86/irq.c |2 --
>> 1 files changed, 0 insertions(+), 2 deletions(-)
>>
>> diff --git
On Fri, Jul 20, 2018 at 02:29:34AM -0700, Zhenzhong Duan wrote:
> No functional change.
>
> Signed-off-by: Zhenzhong Duan
> ---
> xen/arch/x86/irq.c |2 --
> 1 files changed, 0 insertions(+), 2 deletions(-)
>
> diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
> index 87ef2e8..5253fd1
On 20/07/18 10:58, Olaf Hering wrote:
> Am Fri, 20 Jul 2018 10:38:30 +0100
> schrieb Andrew Cooper :
>
>> On 20/07/18 10:21, Olaf Hering wrote:
>>> Is the loss of cpuflags intentional?
>> Yes, but they've got nothing to do with Spectre.
> Thank you, Andrew. After a few more reboots I figured
On 07/19/2018 09:18 AM, Isaila Alexandru wrote:
> On Mi, 2018-07-18 at 15:33 +, George Dunlap wrote:
>>
>>>
>>> On Jul 2, 2018, at 8:42 AM, Alexandru Isaila >> om> wrote:
>>>
>>> From: Isaila Alexandru
>>>
>>> This patch adds access rights for the NPT pages. The access rights
>>> are
>>>
Am Fri, 20 Jul 2018 10:38:30 +0100
schrieb Andrew Cooper :
> On 20/07/18 10:21, Olaf Hering wrote:
> > Is the loss of cpuflags intentional?
> Yes, but they've got nothing to do with Spectre.
Thank you, Andrew. After a few more reboots I figured that booting without any
cmdline option makes no
On 20/07/18 10:21, Olaf Hering wrote:
> On a host that is booted with the following command line, certain cpu flags
> disappear in xen-4.9 and later:
>
> (XEN) Command line: loglvl=all guest_loglvl=all console=com1 com1=57600
> cpuid=ibrsb,stibp,ibpb,ssbd
On Fri, Jul 20, 2018 at 10:19:44AM +0100, Paul Durrant wrote:
> > >
> > > I think this flag currently serves two purposes: one is to indicate
> > > whether there are resources allocated within xen, the other it indicate
> > > whether it is in use (as suggested in the comment).
> > >
> > > Suppose
No functional change.
Signed-off-by: Zhenzhong Duan
---
xen/arch/x86/irq.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
index 87ef2e8..5253fd1 100644
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -2701,8 +2701,6 @@ int
flight 74991 distros-debian-jessie real [real]
http://osstest.xensource.com/osstest/logs/74991/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-armhf-jessie-netboot-pygrub 10 debian-di-install fail like
74964
baseline version:
flight
flight 125342 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125342/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 125183
Tests which are
On Fri, Jul 20, 2018 at 11:17:18AM +0200, Juergen Gross wrote:
> On 20/07/18 11:00, Wei Liu wrote:
> > On Fri, Jul 20, 2018 at 10:32:42AM +0200, Roger Pau Monne wrote:
> >> Remove local definition of MIN and instead include the kernel.h header
> >> for the hypervisor build. Fixes the following
On a host that is booted with the following command line, certain cpu flags
disappear in xen-4.9 and later:
(XEN) Command line: loglvl=all guest_loglvl=all console=com1 com1=57600
cpuid=ibrsb,stibp,ibpb,ssbd spec-ctrl=ibrs,ibpb,ssbd,bti-thunk=retpoline
xpti=yes
On my test system the
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Paul Durrant
> Sent: 20 July 2018 10:05
> To: Wei Liu
> Cc: Stefano Stabellini ; Wei Liu
> ; Andrew Cooper ; Tim
> (Xen.org) ; George Dunlap ;
> Julien Grall ; Jan Beulich ; Ian
> Jackson
On 20/07/18 11:00, Wei Liu wrote:
> On Fri, Jul 20, 2018 at 10:32:42AM +0200, Roger Pau Monne wrote:
>> Remove local definition of MIN and instead include the kernel.h header
>> for the hypervisor build. Fixes the following error on the tools build:
>>
>> In file included from
On 07/19/2018 02:08 PM, Isaila Alexandru wrote:
> On Jo, 2018-07-19 at 04:02 -0600, Jan Beulich wrote:
>>>
>
> On 19.07.18 at 10:43, wrote:
>>> On 07/19/2018 11:30 AM, Jan Beulich wrote:
>
>>
>>>
>>> On 19.07.18 at 10:18, wrote:
> On Mi, 2018-07-18 at 15:33
flight 125345 qemu-upstream-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125345/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 124797
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: 20 July 2018 09:59
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Jan Beulich ;
> Andrew Cooper ; George Dunlap
> ; Ian Jackson ; Julien
> Grall ; Konrad Rzeszutek Wilk
> ; Stefano Stabellini ; Tim
>
From: Oleksandr Andrushchenko
This is in preparation for adding support of DMA buffer
functionality: make map/unmap related code and structures, used
privately by gntdev, ready for dma-buf extension, which will re-use
these. Rename corresponding structures as those become non-private
to gntdev
From: Oleksandr Andrushchenko
Extend grant table module API to allow allocating buffers that can
be used for DMA operations and mapping foreign grant references
on top of those.
The resulting buffer is similar to the one allocated by the balloon
driver in that proper memory reservation is made
From: Oleksandr Andrushchenko
Make set/clear page private code shared and accessible to
other kernel modules which can re-use these instead of open-coding.
Signed-off-by: Oleksandr Andrushchenko
Reviewed-by: Boris Ostrovsky
---
drivers/xen/grant-table.c | 54
From: Oleksandr Andrushchenko
1. Import a dma-buf with the file descriptor provided and export
granted references to the pages of that dma-buf into the array
of grant references.
2. Add API to close all references to an imported buffer, so it can be
released by the owner. This is only
From: Oleksandr Andrushchenko
This work is in response to my previous attempt to introduce Xen/DRM
zero-copy driver [1] to enable Linux dma-buf API [2] for Xen based
frontends/backends. There is also an existing hyper_dmabuf approach
available [3] which, if reworked to utilize the proposed
From: Oleksandr Andrushchenko
1. Create a dma-buf from grant references provided by the foreign
domain. By default dma-buf is backed by system memory pages, but
by providing GNTDEV_DMA_FLAG_XXX flags it can also be created
as a DMA write-combine/coherent buffer, e.g. allocated with
From: Oleksandr Andrushchenko
Add UAPI and IOCTLs for dma-buf grant device driver extension:
the extension allows userspace processes and kernel modules to
use Xen backed dma-buf implementation. With this extension grant
references to the pages of an imported dma-buf can be exported
for other
From: Oleksandr Andrushchenko
Memory {increase|decrease}_reservation and VA mappings update/reset
code used in balloon driver can be made common, so other drivers can
also re-use the same functionality without open-coding.
Create a dedicated file for the shared code and export corresponding
On Fri, Jul 20, 2018 at 10:32:42AM +0200, Roger Pau Monne wrote:
> Remove local definition of MIN and instead include the kernel.h header
> for the hypervisor build. Fixes the following error on the tools build:
>
> In file included from xc_dom_decompress_unsafe_lzma.c:8:0:
>
On Tue, Jul 17, 2018 at 02:38:13PM +0100, Paul Durrant wrote:
> +static int iommu_op_enable_modification(void)
> +{
> +struct domain *currd = current->domain;
> +struct domain_iommu *iommu = dom_iommu(currd);
> +const struct iommu_ops *ops = iommu->platform_ops;
> +
> +/* Has
The subject should be 'lzma: fix tools build'.
Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Remove local definition of MIN and instead include the kernel.h header
for the hypervisor build. Fixes the following error on the tools build:
In file included from xc_dom_decompress_unsafe_lzma.c:8:0:
../../xen/common/unlzma.c:33:0: error: "MIN" redefined [-Werror]
#define MIN(a, b) (((a) <
This run is configured for baseline tests only.
flight 74990 ovmf real [real]
http://osstest.xensource.com/osstest/logs/74990/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail
flight 125458 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125458/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 125432
Tests which
flight 125454 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125454/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf da417eb8ed4bbaf149c31d197eb56fc8a5abbf68
baseline version:
ovmf
60 matches
Mail list logo
