> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, March 17, 2016 3:51 PM
> To: xen-devel
> Cc: Andrew Cooper ; Wu, Feng
> ; Keir Fraser
> Subject: [PATCH v3 0/4] x86: accommodate 32-bit PV guests with SMEP/SMAP
> handling
>
> As has been explained pr
flight 96017 xen-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96017/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt5 libvirt-build fail REGR. vs. 87893
build-amd64-libvi
flight 96006 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96006/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-vhd 6 xen-boot fail REGR. vs. 95849
test-armhf-armhf-
flight 96003 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96003/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 5 libvirt-build fail REGR. vs. 80927
build-i
flight 96002 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96002/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 15 guest-start/debian.repeat fail REGR. vs. 95728
Regressions which
flight 95982 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95982/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail
REGR. vs. 94856
test-
Just a small correction -
Not if (req_end >= field_start && field_end >= req_start)
But if (req_end *>* field_start && field_end *>* req_start)
On Mon, Jun 20, 2016 at 12:23 PM, Andrey Grodzovsky
wrote:
>
>
> On Mon, Jun 20, 2016 at 11:38 AM, Jan Beulich wrote:
>
>> >>> On 20.06.16 at 17:15, w
Hi Juergen,
On 17/06/16 06:26, Juergen Gross wrote:
In order to support reading another vcpu's mapped vcpu_runstate_info
an indicator for an occurring update of the runstate information is
needed.
Add the possibility to activate setting this indicator in the highest
bit of state_entry_time via
> xtf-microvm-suite
+1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
We are in danger of getting stuck on this naming question. I would
like everyone to put forward some suggestions for the name of thisr
toplevel epo on xenbits.
Hopefully we can find one that Andrew likes and that's acceptable to
the committers.
I suggest
xen-microvm-test-framework
xen-microv
On 6/20/16 10:28 AM, Jan Beulich wrote:
On 20.06.16 at 17:11, wrote:
>> On 06/20/2016 10:46 AM, Doug Goldstein wrote:
>>> On 6/20/16 9:04 AM, Daniel De Graaf wrote:
Since enabling XSM is required to enable FLASK, place the option for
FLASK below the one for XSM. In addition, since
Use an array to keep track of warning text, provide a function to add
warning text to track. Print warnings (if any) right before finishing
using the console.
Signed-off-by: Wei Liu
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/setup.c | 3 +++
xen/common/Makefile | 1 +
Originally hvm_fep was guarded by NDEBUG, which means it was only
available to debug builds.
However there is value to have it for non-debug builds as well. User can
use that to run tests in setup that replicates production setup.
Make it clear with a sync_console style warning that this option c
Move the warning text to a static variable and marked that as initconst
data. Call warning_add in console_init_preirq. Finally remove all
unused bits.
Signed-off-by: Wei Liu
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/drivers/char/console.c | 38 ++
1 file
Wei Liu (3):
xen: add warning infrastructure
console: use warning infrastructure for sync console warning
xen: make available hvm_fep to non-debug build as well
docs/misc/xen-command-line.markdown | 8 --
xen/arch/x86/Kconfig| 17 +
xen/arch/x86/hvm/hvm.c
flight 96011 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96011/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12
On Mon, Jun 20, 2016 at 11:38 AM, Jan Beulich wrote:
> >>> On 20.06.16 at 17:15, wrote:
> > On Mon, Jun 20, 2016 at 4:56 AM, Jan Beulich wrote:
> >
> >> >>> On 20.06.16 at 00:03, wrote:
> >> > Follow up on
> >> http://www.gossamer-threads.com/lists/xen/devel/436000#436000
> >> > Using
> >> htt
flight 95987 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95987/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR.
vs. 94748
test-amd64-amd64-
On 06/20/2016 11:14 AM, Jan Beulich wrote:
On 20.06.16 at 17:01, wrote:
>> On 06/20/2016 09:55 AM, Jan Beulich wrote:
>> On 20.06.16 at 15:36, wrote:
On 06/20/2016 09:30 AM, Jan Beulich wrote:
On 20.06.16 at 14:58, wrote:
>> On 06/20/2016 04:56 AM, Jan Beulich wrote:
>
Hi all,
I'm running Xen on NVIDIA Jetson TK1 board. The Xen code is from Ian's
repo.: git://xenbits.xen.org/people/ianc/xen.git with the commit point
c78d51660446d33dac4bb07c3c17e1d14d62ebc2
Right now, I can boot dom0 on Xen on the Jetson board. After the
system boots up, I can boot up a VM1 usin
>>> On 20.06.16 at 17:15, wrote:
Argh - I had started a second reply. This was actually meant to be
part of it.
> On Mon, Jun 20, 2016 at 4:56 AM, Jan Beulich wrote:
>
>> >>> On 20.06.16 at 00:03, wrote:
>> > Follow up on
>> http://www.gossamer-threads.com/lists/xen/devel/436000#436000
>> >
On 20/06/16 16:36, Andrew Cooper wrote:
On 20/06/16 16:03, Julien Grall wrote:
Hi Andrew,
On 20/06/16 15:53, Andrew Cooper wrote:
On 20/06/16 14:37, Julien Grall wrote:
p2m_cache_flush is expecting GFNs in parameter and not MFNs. Rename
the variable to *gfn* and use typesafe to avoid possib
>>> On 20.06.16 at 17:15, wrote:
> On Mon, Jun 20, 2016 at 4:56 AM, Jan Beulich wrote:
>
>> >>> On 20.06.16 at 00:03, wrote:
>> > Follow up on
>> http://www.gossamer-threads.com/lists/xen/devel/436000#436000
>> > Using
>> http://eli.thegreenplace.net/2008/08/15/intersection-of-1d-segments as
>
On 20/06/16 16:03, Julien Grall wrote:
> Hi Andrew,
>
> On 20/06/16 15:53, Andrew Cooper wrote:
>> On 20/06/16 14:37, Julien Grall wrote:
>>> p2m_cache_flush is expecting GFNs in parameter and not MFNs. Rename
>>> the variable to *gfn* and use typesafe to avoid possible misusage.
>>>
>>> Signed-off
>>> On 20.06.16 at 17:11, wrote:
> On 06/20/2016 10:46 AM, Doug Goldstein wrote:
>> On 6/20/16 9:04 AM, Daniel De Graaf wrote:
>>> Since enabling XSM is required to enable FLASK, place the option for
>>> FLASK below the one for XSM. In addition, since it does not make sense
>>> to enable XSM with
>>> On 20.06.16 at 16:48, wrote:
> Daniel De Graaf writes ("Re: [PATCH 02/11] hvmctl: convert
> HVMOP_set_pci_intx_level"):
>> On 06/20/2016 08:53 AM, Jan Beulich wrote:
>> > Note that this adds validation of the "domain" interface structure
>> > field, which previously got ignored.
>> >
>> > Not
>>> On 20.06.16 at 16:32, wrote:
> On 15/06/16 11:28, Jan Beulich wrote:
>> --- a/xen/arch/x86/time.c
>> +++ b/xen/arch/x86/time.c
>> @@ -1358,6 +1358,24 @@ static void time_calibration(void *unuse
>> &r, 1);
>> }
>>
>> +void __init clear_tsc_cap(unsigned int feature)
>> +
>>> On 20.06.16 at 16:20, wrote:
> On 15/06/16 11:28, Jan Beulich wrote:
>> --- a/xen/arch/x86/i8259.c
>> +++ b/xen/arch/x86/i8259.c
>> @@ -359,12 +359,7 @@ void __init init_IRQ(void)
>>
>> apic_intr_init();
>>
>> -/* Set the clock to HZ Hz */
>> -#define CLOCK_TICK_RATE 1193182 /* cr
On 6/20/16 10:07 AM, Daniel De Graaf wrote:
> On 06/20/2016 10:35 AM, Doug Goldstein wrote:
>> On 6/20/16 9:04 AM, Daniel De Graaf wrote:
>>> This operation has no known users, and is primarily useful when an MLS
>>> policy is in use (which has never been shipped with Xen). In addition,
>>> the in
On Mon, Jun 20, 2016 at 4:56 AM, Jan Beulich wrote:
> >>> On 20.06.16 at 00:03, wrote:
> > Follow up on
> http://www.gossamer-threads.com/lists/xen/devel/436000#436000
> > Using
> http://eli.thegreenplace.net/2008/08/15/intersection-of-1d-segments as
> > reference.
> >
> > New value
>
>>> On 20.06.16 at 17:01, wrote:
> On 06/20/2016 09:55 AM, Jan Beulich wrote:
> On 20.06.16 at 15:36, wrote:
>>> On 06/20/2016 09:30 AM, Jan Beulich wrote:
>>> On 20.06.16 at 14:58, wrote:
> On 06/20/2016 04:56 AM, Jan Beulich wrote:
> On 20.06.16 at 00:03, wrote:
>>> Fo
On 06/20/2016 10:46 AM, Doug Goldstein wrote:
On 6/20/16 9:04 AM, Daniel De Graaf wrote:
Since enabling XSM is required to enable FLASK, place the option for
FLASK below the one for XSM. In addition, since it does not make sense
to enable XSM without any XSM providers, and FLASK is the only XSM
From: Christoffer Dall
Support adding xen,xen-bootargs node via --with-xen-bootargs to the
configure script and automatically add the Dom0 node to the DT as well.
Signed-off-by: Christoffer Dall
Signed-off-by: Andre Przywara
---
Makefile.am | 34 +-
configure.
From: Ian Campbell
If Xen is enabled, tell Dom0 to use the 'hvc0' console, and fall back to
the usual ttyAMA0 otherwise.
Signed-off-by: Ian Campbell
Signed-off-by: Christoffer Dall
Signed-off-by: Andre Przywara
---
configure.ac | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --
From: Christoffer Dall
Add support for building a Xen binary which includes a Dom0 image and
the Dom0 command-line.
If the user specifies --with-xen=, where Xen is an appropriate
AArch64 Xen binary, the build system will generate a xen-system.axf
instead of a linux-system.axf.
Original patch fr
From: Christoffer Dall
When doing a make clean, only the output image currently configured to
build is being removed. However, one would expect all build artifacts
to be removed when doing a 'make clean' and when switching between Xen
and Linux builds, it is easy to accidentally run an older bui
These patches allow to include a Xen hypervisor binary into a boot-wrapper
ELF file, so that a Foundation Platform or a Fast Model can boot a Xen
system (including a Dom0 kernel).
This has been floating around for a while, I just updated the patches
to apply on the latest boot-wrapper tree. Also I
On 06/20/2016 10:35 AM, Doug Goldstein wrote:
On 6/20/16 9:04 AM, Daniel De Graaf wrote:
This operation has no known users, and is primarily useful when an MLS
policy is in use (which has never been shipped with Xen). In addition,
the information it provides does not actually depend on hypervis
>>> On 20.06.16 at 15:37, wrote:
> to avoid mixing machine frame with guest frame.
>
> Signed-off-by: Julien Grall
Irrespective whether you address the missing mfn_add() (which
are really benign):
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xe
Hi Andrew,
On 20/06/16 15:53, Andrew Cooper wrote:
On 20/06/16 14:37, Julien Grall wrote:
p2m_cache_flush is expecting GFNs in parameter and not MFNs. Rename
the variable to *gfn* and use typesafe to avoid possible misusage.
Signed-off-by: Julien Grall
On arm32, xen_pfn_t was uint64_t, but
On 06/20/2016 09:55 AM, Jan Beulich wrote:
On 20.06.16 at 15:36, wrote:
>> On 06/20/2016 09:30 AM, Jan Beulich wrote:
>> On 20.06.16 at 14:58, wrote:
On 06/20/2016 04:56 AM, Jan Beulich wrote:
On 20.06.16 at 00:03, wrote:
>> Follow up on
>> http://www.gossamer-thr
On 20/06/16 15:50, Daniel De Graaf wrote:
> On 06/20/2016 10:35 AM, Andrew Cooper wrote:
>> On 20/06/16 15:27, Doug Goldstein wrote:
>>> On 6/20/16 9:04 AM, Daniel De Graaf wrote:
These permissions were initially split because they were in separate
domctls, but this split is very unlikely
On 20/06/16 14:37, Julien Grall wrote:
> p2m_cache_flush is expecting GFNs in parameter and not MFNs. Rename
> the variable to *gfn* and use typesafe to avoid possible misusage.
>
> Signed-off-by: Julien Grall
On arm32, xen_pfn_t was uint64_t, but gfn_t is unsigned long.
Is the truncation ok?
~
On 6/20/16 9:04 AM, Daniel De Graaf wrote:
> This adds a Kconfig option and support for including the XSM policy from
> tools/flask/policy in the hypervisor so that the bootloader does not
> need to provide a policy to get sane behavior from an XSM-enabled
> hypervisor. The policy provided by the
Signed-off-by: Wei Liu
---
v2:
1. Add test to index file
2. Only test hvm32 environment
3. Add more description
---
docs/all-tests.dox | 2 ++
tests/fep/Makefile | 12
tests/fep/main.c | 34 ++
3 files changed, 48 insertions(+)
create mode 100644 t
On 6/20/16 9:04 AM, Daniel De Graaf wrote:
> This operation has no known users, and is primarily useful when an MLS
> policy is in use (which has never been shipped with Xen). In addition,
> the information it provides does not actually depend on hypervisor
> state (only on the XSM policy), so an
flight 95995 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95995/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 95197
Tests which did not succeed, but a
On 06/20/2016 10:35 AM, Andrew Cooper wrote:
On 20/06/16 15:27, Doug Goldstein wrote:
On 6/20/16 9:04 AM, Daniel De Graaf wrote:
These permissions were initially split because they were in separate
domctls, but this split is very unlikely to actually provide security
benefits: it would require
On 20/06/16 15:44, Wei Liu wrote:
> Signed-off-by: Wei Liu
Reviewed-by: Andrew Cooper and committed.
Thanks.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On 6/20/16 9:04 AM, Daniel De Graaf wrote:
> Signed-off-by: Daniel De Graaf
Reviewed-by: Doug Goldstein
> ---
> xen/common/Kconfig | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> index 6a51fd5..8fb5a68 100644
> --- a/xe
On 6/20/16 9:04 AM, Daniel De Graaf wrote:
> The only possible value of original_ops was &dummy_xsm_ops, and
> unregister_xsm was never used.
>
> Signed-off-by: Daniel De Graaf
> Reviewed-by: Andrew Cooper
> Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Doug Goldstein
--
Doug Goldstein
Daniel De Graaf writes ("Re: [PATCH 02/11] hvmctl: convert
HVMOP_set_pci_intx_level"):
> On 06/20/2016 08:53 AM, Jan Beulich wrote:
> > Note that this adds validation of the "domain" interface structure
> > field, which previously got ignored.
> >
> > Note further that this retains the hvmop inter
On 6/20/16 9:04 AM, Daniel De Graaf wrote:
> These functions were only called from __init functions.
>
> Signed-off-by: Daniel De Graaf
> Reviewed-by: Andrew Cooper
Reviewed-by: Doug Goldstein
--
Doug Goldstein
signature.asc
Description: OpenPGP digital signature
_
On 6/20/16 9:04 AM, Daniel De Graaf wrote:
> Since enabling XSM is required to enable FLASK, place the option for
> FLASK below the one for XSM. In addition, since it does not make sense
> to enable XSM without any XSM providers, and FLASK is the only XSM
> provider, hide the option to disable FLA
On 6/20/16 9:41 AM, Doug Goldstein wrote:
> On 6/20/16 9:04 AM, Daniel De Graaf wrote:
>> Since enabling XSM is required to enable FLASK, place the option for
>> FLASK below the one for XSM. In addition, since it does not make sense
>> to enable XSM without any XSM providers, and FLASK is the only
On 6/20/16 9:04 AM, Daniel De Graaf wrote:
> Since enabling XSM is required to enable FLASK, place the option for
> FLASK below the one for XSM. In addition, since it does not make sense
> to enable XSM without any XSM providers, and FLASK is the only XSM
> provider, hide the option to disable FLA
On 6/20/16 9:04 AM, Daniel De Graaf wrote:
> Since FLASK is the only implementation of XSM hooks in Xen, using an
> iterated initcall dispatch for setup is overly complex. Change this to
> a direct function call to a globally visible function; if additional XSM
> hooks are added in the future, a s
On 6/20/16 9:04 AM, Daniel De Graaf wrote:
> When an unknown domctl, sysctl, or other operation is encountered in the
> FLASK security server, use the allow_unknown bit in the security policy
> to decide if the permission should be allowed or denied. This allows
> new operations to be tested witho
On 20/06/16 14:37, Julien Grall wrote:
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index a3add21..2710ce8 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -2214,9 +2214,9 @@ static unsigned int mmio_order(const struct domain *d,
#define MAP_MMIO_MAX_ITER 64 /*
>>> On 20.06.16 at 15:37, wrote:
> The x86 version of the function xenmem_add_to_physmap_one contains
> variable name gpfn and gfn which make the code very confusing.
> I have left unchanged for now.
>
> Also, rename gpfn to gfn in the ARM version as the latter is the correct
> acronym for a gues
On 20/06/16 15:27, Doug Goldstein wrote:
> On 6/20/16 9:04 AM, Daniel De Graaf wrote:
>> These permissions were initially split because they were in separate
>> domctls, but this split is very unlikely to actually provide security
>> benefits: it would require a carefully contrived situation for a
>>> On 20.06.16 at 15:37, wrote:
> Also rename some variables to gfn or mfn when it does not require much
> rework.
>
> Signed-off-by: Julien Grall
Acked-by: Jan Beulich
with one remark:
> @@ -787,39 +792,39 @@ guest_physmap_add_entry(struct domain *d, unsigned long
> gfn,
> /* Then, lo
On 06/20/2016 08:53 AM, Jan Beulich wrote:
Note that this adds validation of the "domain" interface structure
field, which previously got ignored.
Note further that this retains the hvmop interface definitions as those
had (wrongly) been exposed to non-tool stack consumers (albeit the
operation
On 6/20/16 9:04 AM, Daniel De Graaf wrote:
> These callbacks are not used in Xen.
>
> Signed-off-by: Daniel De Graaf
Reviewed-by: Doug Goldstein
--
Doug Goldstein
signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen
On 15/06/16 11:28, Jan Beulich wrote:
> --- a/xen/arch/x86/time.c
> +++ b/xen/arch/x86/time.c
> @@ -1358,6 +1358,24 @@ static void time_calibration(void *unuse
> &r, 1);
> }
>
> +void __init clear_tsc_cap(unsigned int feature)
> +{
> +void (*rendezvous_fn)(void *) = tim
On Mon, Jun 20, 2016 at 02:43:47PM +0100, Andrew Cooper wrote:
> On 17/06/16 15:21, Wei Liu wrote:
> > Signed-off-by: Wei Liu
>
> LGTM, although a couple of comments.
>
> > ---
> > tests/fep/Makefile | 12
> > tests/fep/main.c | 31 +++
>
> Please add
On 6/20/16 9:04 AM, Daniel De Graaf wrote:
> This field was originally used in Linux for a default message code for
> network interfaces. It has never been used in Xen, so remove it.
>
> Signed-off-by: Daniel De Graaf
Reviewed-by: Doug Goldstein
--
Doug Goldstein
signature.asc
Description
On 6/20/16 9:04 AM, Daniel De Graaf wrote:
> These permissions were initially split because they were in separate
> domctls, but this split is very unlikely to actually provide security
> benefits: it would require a carefully contrived situation for a domain
> to both need access to one type of CP
On 20/06/16 15:25, Jan Beulich wrote:
On 20.06.16 at 15:37, wrote:
Those helpers will be useful to do common operations without having to
unbox/box manually the GFNs/MFNs.
Signed-off-by: Julien Grall
Acked-by: Jan Beulich
But - since iirc Andrew asked for it during v1 review - any parti
>>> On 20.06.16 at 15:37, wrote:
> Those helpers will be useful to do common operations without having to
> unbox/box manually the GFNs/MFNs.
>
> Signed-off-by: Julien Grall
Acked-by: Jan Beulich
But - since iirc Andrew asked for it during v1 review - any particular
reason you made these macr
On 15/06/16 11:28, Jan Beulich wrote:
> --- a/xen/arch/x86/i8259.c
> +++ b/xen/arch/x86/i8259.c
> @@ -359,12 +359,7 @@ void __init init_IRQ(void)
>
> apic_intr_init();
>
> -/* Set the clock to HZ Hz */
> -#define CLOCK_TICK_RATE 1193182 /* crystal freq (Hz) */
> -#define LATCH (((CLOCK
>>> On 20.06.16 at 16:04, wrote:
> This operation has no known users, and is primarily useful when an MLS
> policy is in use (which has never been shipped with Xen). In addition,
> the information it provides does not actually depend on hypervisor
> state (only on the XSM policy), so an applicati
This adds the xenstore_t type to the example policy for use by a
xenstore stub domain; see the init-xenstore-domain tool for how this
type needs to be used.
Signed-off-by: Daniel De Graaf
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Doug Goldstein
---
tools/flask/policy/modules/modules.conf
When the all_system_role module is enabled, any domain type can be
created using the system_r role, which was the default. When it is
disabled, domains not using the default types (dom0_t and domU_t) must
use another role such as vm_r.
Signed-off-by: Daniel De Graaf
Reviewed-by: Konrad Rzeszutek
These permissions were initially split because they were in separate
domctls, but this split is very unlikely to actually provide security
benefits: it would require a carefully contrived situation for a domain
to both need access to one type of CPU register and also need to be
prohibited from acce
Since FLASK is the only implementation of XSM hooks in Xen, using an
iterated initcall dispatch for setup is overly complex. Change this to
a direct function call to a globally visible function; if additional XSM
hooks are added in the future, a switching mechanism will be needed
regardless, and t
The access vectors defined here have never been used by xenstore.
Signed-off-by: Daniel De Graaf
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Doug Goldstein
---
tools/flask/policy/policy/access_vectors | 23 ++-
tools/flask/policy/policy/security_classes | 1 -
2 file
The only possible value of original_ops was &dummy_xsm_ops, and
unregister_xsm was never used.
Signed-off-by: Daniel De Graaf
Reviewed-by: Andrew Cooper
Reviewed-by: Konrad Rzeszutek Wilk
---
xen/include/xsm/xsm.h| 1 -
xen/xsm/flask/flask_op.c | 4 +---
xen/xsm/flask/hooks.c| 3 ---
Signed-off-by: Daniel De Graaf
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Doug Goldstein
---
.../policy/policy/support/loadable_module.spt | 166 -
tools/flask/policy/policy/support/misc_macros.spt | 2 +
2 files changed, 2 insertions(+), 166 deletions(-)
delet
>>> On 20.06.16 at 15:58, wrote:
> On 20/06/16 14:49, Jan Beulich wrote:
> On 20.06.16 at 14:54, wrote:
>>> On 20/06/16 13:48, Jan Beulich wrote:
>>> On 20.06.16 at 14:15, wrote:
> On 20/06/16 12:04, Jan Beulich wrote:
>> No point in aligning entry points which aren't supposed to
Changes from v1:
- Change c->context and c->sid from arrays to fields when shrinking
- Keep struct xen_flask_userlist in headers, but guard it with #ifs
- Split off Kconfig changes into their own patches
- Add patch 16 (AVC_STATS in Kconfig)
- Prevent free() of static data in xsm_dt_init
FLAS
This adds a Kconfig option and support for including the XSM policy from
tools/flask/policy in the hypervisor so that the bootloader does not
need to provide a policy to get sane behavior from an XSM-enabled
hypervisor. The policy provided by the bootloader, if present, will
override the built-in
Since enabling XSM is required to enable FLASK, place the option for
FLASK below the one for XSM. In addition, since it does not make sense
to enable XSM without any XSM providers, and FLASK is the only XSM
provider, hide the option to disable FLASK under EXPERT.
Signed-off-by: Daniel De Graaf
-
This operation has no known users, and is primarily useful when an MLS
policy is in use (which has never been shipped with Xen). In addition,
the information it provides does not actually depend on hypervisor
state (only on the XSM policy), so an application that needs it could
compute the results
This also renames the example users created by vm_role.
Signed-off-by: Daniel De Graaf
Reviewed-by: Doug Goldstein
---
docs/misc/xsm-flask.txt| 34 +++---
tools/flask/policy/Makefile| 9 --
tools/flask/policy/modules/all_s
These functions were only called from __init functions.
Signed-off-by: Daniel De Graaf
Reviewed-by: Andrew Cooper
---
xen/xsm/dummy.c| 2 +-
xen/xsm/xsm_core.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 9791ad4..a082b28 100
Signed-off-by: Daniel De Graaf
---
xen/common/Kconfig | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 6a51fd5..8fb5a68 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -134,9 +134,14 @@ config FLASK
config FLASK
This makes it easier to enable or disable parts of the XSM policy.
Signed-off-by: Daniel De Graaf
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Doug Goldstein
---
tools/flask/policy/Makefile| 22 +-
tools/flask/policy/modules/dom0.te | 74 ++
too
These callbacks are not used in Xen.
Signed-off-by: Daniel De Graaf
---
xen/xsm/flask/avc.c | 97 ++---
xen/xsm/flask/include/avc.h | 13 --
2 files changed, 4 insertions(+), 106 deletions(-)
diff --git a/xen/xsm/flask/avc.c b/xen/xsm/flask/av
This field was originally used in Linux for a default message code for
network interfaces. It has never been used in Xen, so remove it.
Signed-off-by: Daniel De Graaf
---
xen/xsm/flask/ss/policydb.c | 21
xen/xsm/flask/ss/policydb.h | 4 ++--
xen/xsm/flask/ss/services.c | 58 +
When an unknown domctl, sysctl, or other operation is encountered in the
FLASK security server, use the allow_unknown bit in the security policy
to decide if the permission should be allowed or denied. This allows
new operations to be tested without needing to immediately add security
checks; howe
On 20/06/16 14:49, Jan Beulich wrote:
On 20.06.16 at 14:54, wrote:
>> On 20/06/16 13:48, Jan Beulich wrote:
>> On 20.06.16 at 14:15, wrote:
On 20/06/16 12:04, Jan Beulich wrote:
> No point in aligning entry points which aren't supposed to be used
> anyway.
>
> Signed
>>> On 20.06.16 at 15:36, wrote:
>
> On 06/20/2016 09:30 AM, Jan Beulich wrote:
> On 20.06.16 at 14:58, wrote:
>>> On 06/20/2016 04:56 AM, Jan Beulich wrote:
>>> On 20.06.16 at 00:03, wrote:
> Follow up on
> http://www.gossamer-threads.com/lists/xen/devel/436000#436000
>
On 20/06/16 14:12, Tim Deegan wrote:
> At 12:54 +0100 on 09 Jun (1465476894), Andrew Cooper wrote:
>> On 08/06/16 14:09, Jan Beulich wrote:
>>> ... to avoid re-doing the same translation later again (in a retry, for
>>> example). This doesn't help very often according to my testing, but
>>> it's pr
On 17/06/16 15:21, Wei Liu wrote:
> Signed-off-by: Wei Liu
LGTM, although a couple of comments.
> ---
> tests/fep/Makefile | 12
> tests/fep/main.c | 31 +++
Please add this to the test index in docs/all-tests.dox
> 2 files changed, 43 insertions(+)
>>> On 20.06.16 at 14:54, wrote:
> On 20/06/16 13:48, Jan Beulich wrote:
> On 20.06.16 at 14:15, wrote:
>>> On 20/06/16 12:04, Jan Beulich wrote:
No point in aligning entry points which aren't supposed to be used
anyway.
Signed-off-by: Jan Beulich
>>> Reviewed-by: Andrew
The x86 version of the function xenmem_add_to_physmap_one contains
variable name gpfn and gfn which make the code very confusing.
I have left unchanged for now.
Also, rename gpfn to gfn in the ARM version as the latter is the correct
acronym for a guest physical frame.
Finally, remove the trailin
Ján Tomko writes ("Re: [libvirt] gnulib and 32-bit libvirt build,
rpl_canonicalize_file_name"):
> This has been fixed in gnulib already:
> http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=246b3b2
> commit 246b3b28808ee5f4664be674dce573af9497fc7a
> Author: Eric Blake
> CommitDat
Hi all
I'm pleased to announce that Xen 4.7 is released. I would like to
thank everyone who involved in the making of 4.7 release (either in
the form of patch, bug report or packaging effort). This release
wouldn't have happened without all these contributions.
You can check out 4.7 release from
The correct acronym for a guest physical frame is gfn. Also use
the typesafe gfn to ensure that a guest frame is effectively used.
Signed-off-by: Julien Grall
---
Changes in v2:
- Remove extra pair of brackets.
---
xen/arch/arm/domain.c | 4 ++--
xen/arch/arm/mm.c
1 - 100 of 202 matches
Mail list logo
