Re: [Xen-devel] Linux 4.4 MW: Boot under Xen fails with CONFIG_DEBUG_WX enabled: RIP: ptdump_walk_pgd_level_core
On 11/04/2015 01:28 PM, Sander Eikelenboom wrote: On 2015-11-04 16:52, Stephen Smalley wrote: On 11/04/2015 06:55 AM, Sander Eikelenboom wrote: Hi All, I just tried to boot with the current linus mergewindow tree under Xen. It fails with a kernel panic at boot with the new "CONFIG_DEBUG_WX" option enabled. Disabling it makes the kernel boot fine. The splat: [ 18.424241] Freeing unused kernel memory: 1104K (822fc000 - 8241) [ 18.430314] Write protecting the kernel read-only data: 18432k [ 18.441054] Freeing unused kernel memory: 1144K (880001ae2000 - 880001c0) [ 18.447966] Freeing unused kernel memory: 1560K (88000207a000 - 88000220) [ 18.453947] BUG: unable to handle kernel paging request at 88055c883000 [ 18.459943] IP: [] ptdump_walk_pgd_level_core+0x20e/0x440 [ 18.465847] PGD 2212067 PUD 0 [ 18.471564] Oops: [#1] SMP [ 18.477248] Modules linked in: [ 18.482918] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.3.0-mw-20151104-linus-doflr+ #1 [ 18.488804] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS V1.8B1 09/13/2010 [ 18.494778] task: 880059b9 ti: 880059b98000 task.ti: 880059b98000 [ 18.500852] RIP: e030:[] [] ptdump_walk_pgd_level_core+0x20e/0x440 [ 18.507102] RSP: e02b:880059b9be48 EFLAGS: 00010296 [ 18.513351] RAX: 88055c883000 RBX: 81ae2000 RCX: 8800 [ 18.519733] RDX: 0067 RSI: 880059b9be98 RDI: 88001000 [ 18.526129] RBP: 880059b9bf00 R08: R09: [ 18.532522] R10: 88005fd0e790 R11: 0001 R12: 88008000 [ 18.538891] R13: cfff R14: 880059b9be98 R15: [ 18.545247] FS: () GS:88005f68() knlGS: [ 18.551708] CS: e033 DS: ES: CR0: 8005003b [ 18.558153] CR2: 88055c883000 CR3: 02211000 CR4: 0660 [ 18.564686] Stack: [ 18.571106] 000159b9be50 82211000 88055c884000 0800 [ 18.577704] 8000 88055c883000 0007 88005fd0e790 [ 18.584291] 880059b9bed8 81156ace 0001 [ 18.590916] Call Trace: [ 18.597458] [] ? free_reserved_area+0x11e/0x120 [ 18.604180] [] ptdump_walk_pgd_level_checkwx+0x12/0x20 [ 18.611014] [] mark_rodata_ro+0xe9/0xf0 [ 18.617819] [] ? rest_init+0x80/0x80 [ 18.624512] [] kernel_init+0x18/0xe0 [ 18.631095] [] ret_from_fork+0x3f/0x70 [ 18.637650] [] ? rest_init+0x80/0x80 [ 18.644178] Code: 70 ff ff ff 48 3b 85 58 ff ff ff 0f 84 c0 fe ff ff 48 8b 85 68 ff ff ff 48 c1 e0 10 48 c1 f8 10 48 89 45 b0 48 8b 85 70 ff ff ff <48> 8b 38 48 85 ff 0f 85 4e ff ff ff b9 02 00 00 00 31 d2 4c 89 [ 18.658246] RIP [] ptdump_walk_pgd_level_core+0x20e/0x440 [ 18.665211] RSP [ 18.672073] CR2: 88055c883000 [ 18.678852] ---[ end trace d84e34461c40637a ]--- [ 18.685641] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0009 [ 18.685641] [ 18.699520] Kernel Offset: disable What's your .config? Does cat /sys/kernel/debug/kernel_page_tables produce a similar fault even with CONFIG_DEBUG_WX=n? .config is attached Hmm that sysfs file doesn't seem to exist then: # cat /sys/kernel/debug/kernel_page_tables cat: /sys/kernel/debug/kernel_page_tables: No such file or directory Needs CONFIG_X86_PTDUMP=y. Also assumes you have debugfs mounted there. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Linux 4.4 MW: Boot under Xen fails with CONFIG_DEBUG_WX enabled: RIP: ptdump_walk_pgd_level_core
On 11/04/2015 06:55 AM, Sander Eikelenboom wrote: Hi All, I just tried to boot with the current linus mergewindow tree under Xen. It fails with a kernel panic at boot with the new "CONFIG_DEBUG_WX" option enabled. Disabling it makes the kernel boot fine. The splat: [ 18.424241] Freeing unused kernel memory: 1104K (822fc000 - 8241) [ 18.430314] Write protecting the kernel read-only data: 18432k [ 18.441054] Freeing unused kernel memory: 1144K (880001ae2000 - 880001c0) [ 18.447966] Freeing unused kernel memory: 1560K (88000207a000 - 88000220) [ 18.453947] BUG: unable to handle kernel paging request at 88055c883000 [ 18.459943] IP: [] ptdump_walk_pgd_level_core+0x20e/0x440 [ 18.465847] PGD 2212067 PUD 0 [ 18.471564] Oops: [#1] SMP [ 18.477248] Modules linked in: [ 18.482918] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.3.0-mw-20151104-linus-doflr+ #1 [ 18.488804] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS V1.8B1 09/13/2010 [ 18.494778] task: 880059b9 ti: 880059b98000 task.ti: 880059b98000 [ 18.500852] RIP: e030:[] [] ptdump_walk_pgd_level_core+0x20e/0x440 [ 18.507102] RSP: e02b:880059b9be48 EFLAGS: 00010296 [ 18.513351] RAX: 88055c883000 RBX: 81ae2000 RCX: 8800 [ 18.519733] RDX: 0067 RSI: 880059b9be98 RDI: 88001000 [ 18.526129] RBP: 880059b9bf00 R08: R09: [ 18.532522] R10: 88005fd0e790 R11: 0001 R12: 88008000 [ 18.538891] R13: cfff R14: 880059b9be98 R15: [ 18.545247] FS: () GS:88005f68() knlGS: [ 18.551708] CS: e033 DS: ES: CR0: 8005003b [ 18.558153] CR2: 88055c883000 CR3: 02211000 CR4: 0660 [ 18.564686] Stack: [ 18.571106] 000159b9be50 82211000 88055c884000 0800 [ 18.577704] 8000 88055c883000 0007 88005fd0e790 [ 18.584291] 880059b9bed8 81156ace 0001 [ 18.590916] Call Trace: [ 18.597458] [] ? free_reserved_area+0x11e/0x120 [ 18.604180] [] ptdump_walk_pgd_level_checkwx+0x12/0x20 [ 18.611014] [] mark_rodata_ro+0xe9/0xf0 [ 18.617819] [] ? rest_init+0x80/0x80 [ 18.624512] [] kernel_init+0x18/0xe0 [ 18.631095] [] ret_from_fork+0x3f/0x70 [ 18.637650] [] ? rest_init+0x80/0x80 [ 18.644178] Code: 70 ff ff ff 48 3b 85 58 ff ff ff 0f 84 c0 fe ff ff 48 8b 85 68 ff ff ff 48 c1 e0 10 48 c1 f8 10 48 89 45 b0 48 8b 85 70 ff ff ff <48> 8b 38 48 85 ff 0f 85 4e ff ff ff b9 02 00 00 00 31 d2 4c 89 [ 18.658246] RIP [] ptdump_walk_pgd_level_core+0x20e/0x440 [ 18.665211] RSP [ 18.672073] CR2: 88055c883000 [ 18.678852] ---[ end trace d84e34461c40637a ]--- [ 18.685641] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0009 [ 18.685641] [ 18.699520] Kernel Offset: disable What's your .config? Does cat /sys/kernel/debug/kernel_page_tables produce a similar fault even with CONFIG_DEBUG_WX=n? ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 0/3] Xen/FLASK policy updates for device contexts
On 03/17/2015 04:43 PM, Daniel De Graaf wrote: > In order to support assigning security lables to ARM device tree nodes > in Xen's XSM policy, a new ocontext type is needed in the security > policy. > > In addition to adding the new ocontext, the existing I/O memory range > ocontext is expanded to 64 bits in order to support hardware with more > than 44 bits of physical address space (32-bit count of 4K pages). > > Changes from v2: > - Clean up printf format strings for 32-bit builds > > Changes from v1: > - Use policy version 30 instead of forking the version numbers for Xen; >this removes the need for v1's patch 3. > - Report an error when attempting to use an I/O memory range that >requires a 64-bit representation with an old policy output version >that cannot support this > - Fix a few incorrect references to PCIDEVICECON > - Reorder patches to clarify the allowed characterset of device tree >paths > > [PATCH 1/3] checkpolicy: Expand allowed character set in paths > [PATCH 2/3] libsepol, checkpolicy: widen Xen IOMEM ocontext entries > [PATCH 3/3] libsepol, checkpolicy: add device tree ocontext nodes to Thanks, applied all three. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/4] checkpolicy: add output for Xen policy version support
On 03/12/2015 01:12 PM, Daniel De Graaf wrote:
> When invoked as "checkpolicy -t Xen -V", report the range of supported
> versions for the Xen policy instead of the supported versions for the
> SELinux policy.
>
> This also changes the default maximum policy version to depend on the
> policy type, so that running "checkpolicy -t Xen" without -c does not
> fail due to the Xen policy having a different maximum version number.
There is a bit of wrinkle here with regard to splitting the Xen and
SELinux policy version number space that I'm afraid I didn't think about
earlier. You'll find that there are various tests of policyvers >= some
version in the policydb_read code path and the policydb_write code path
to decide whether or not to read or write the corresponding fields or
structures, and none of that logic currently checks the target_platform.
Also, certain language features in the source policy language have been
documented to depend on specific policy version numbers, so reusing the
same version numbers for Xen and SELinux to mean different things could
be confusing to users.
So on second thought, I'd suggest that you update Xen to support the
latest upstream policy version just so you can fully support all of the
language features and just define a new version for this change (i.e.
policy 30). Sorry!
>
> Signed-off-by: Daniel De Graaf
> ---
> checkpolicy/checkpolicy.c | 59
> ++
> libsepol/include/sepol/policydb/policydb.h | 9 +++--
> 2 files changed, 49 insertions(+), 19 deletions(-)
>
> diff --git a/checkpolicy/checkpolicy.c b/checkpolicy/checkpolicy.c
> index 61a2e89..e836bcb 100644
> --- a/checkpolicy/checkpolicy.c
> +++ b/checkpolicy/checkpolicy.c
> @@ -99,7 +99,7 @@ static int handle_unknown = SEPOL_DENY_UNKNOWN;
> static const char *txtfile = "policy.conf";
> static const char *binfile = "policy";
>
> -unsigned int policyvers = POLICYDB_VERSION_MAX;
> +unsigned int policyvers = 0;
>
> void usage(char *progname)
> {
> @@ -466,17 +466,7 @@ int main(int argc, char **argv)
> usage(argv[0]);
> exit(1);
> }
> - if (n < POLICYDB_VERSION_MIN
> - || n > POLICYDB_VERSION_MAX) {
> - fprintf(stderr,
> - "policyvers value %ld not in
> range %d-%d\n",
> - n, POLICYDB_VERSION_MIN,
> - POLICYDB_VERSION_MAX);
> - usage(argv[0]);
> - exit(1);
> - }
> - if (policyvers != n)
> - policyvers = n;
> + policyvers = n;
> break;
> }
> case 'h':
> @@ -485,10 +475,47 @@ int main(int argc, char **argv)
> }
> }
>
> - if (show_version) {
> - printf("%d (compatibility range %d-%d)\n", policyvers,
> -POLICYDB_VERSION_MAX, POLICYDB_VERSION_MIN);
> - exit(0);
> + switch (target) {
> + case SEPOL_TARGET_SELINUX:
> + if (policyvers == 0) {
> + policyvers = POLICYDB_VERSION_MAX;
> + } else if (policyvers < POLICYDB_VERSION_MIN
> + || policyvers > POLICYDB_VERSION_MAX) {
> + fprintf(stderr,
> + "policyvers value %d not in range %d-%d\n",
> + policyvers, POLICYDB_VERSION_MIN,
> + POLICYDB_VERSION_MAX);
> + usage(argv[0]);
> + exit(1);
> + }
> + if (show_version) {
> + printf("%d (compatibility range %d-%d)\n", policyvers,
> +POLICYDB_VERSION_MAX, POLICYDB_VERSION_MIN);
> + exit(0);
> + }
> + break;
> + case SEPOL_TARGET_XEN:
> + if (policyvers == 0) {
> + policyvers = POLICYDB_XEN_VERSION_MAX;
> + } else if (policyvers < POLICYDB_XEN_VERSION_MIN
> + || policyvers > POLICYDB_XEN_VERSION_MAX) {
> + fprintf(stderr,
> + "policyvers value %d not in range %d-%d\n",
> + policyvers, POLICYDB_XEN_VERSION_MIN,
> + POLICYDB_XEN_VERSION_MAX);
> + usage(argv[0]);
> + exit(1);
> + }
> + if (show_version) {
> + printf("Xen policy compatibility range: %d %d\n",
> + POLICYDB_XEN_VE
