Re: [Xen-devel] [PATCH] xsplice: Use ld-embedded build-ids
On Fri, Aug 14, 2015 at 9:57 AM, Martin Pohlackwrote: > On 14.08.2015 15:54, Jan Beulich wrote: > On 14.08.15 at 14:59, wrote: >>> On 11.08.2015 16:12, Jan Beulich wrote: >>> On 05.08.15 at 16:09, wrote: > Todo: > * Should be moved to sysctl to only allow Dom0 access Because of? >>> >>> The discussion in this thread: >>> >>> [Xen-devel] [RFC PATCH v3.1 2/2] xsplice: Add hook for build_id >>> >>> was: >>> -- > Martin Pohlack: > We should not expose the build_id to normal guests, but only to Dom0. > > A build_id uniquely identifies a specific build and I don't see how that > information would be required from DomU. It might actually help an > attacker to build his return-oriented programming exploit against a > specific build. > > The normal version numbers should be enough to know about capabilities > and API. Andrew Cooper: It will need its own XSM hook, but need not be strictly limited to just dom0. >>> -- >> >> So I'm confused - I asked "why Dom0 only" and then you point me to >> Andrew saying it doesn't need to be Dom0 only? > > Sorry about that, my (not expressed) thinking was that we should > restrict that to Dom0 for the XSM-disabled case. > That may make this more complex. If we want to restrict it to this we may as well just stick this in sysctl and have it be part of the xsplice ops. Let me do that. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xsplice: Use ld-embedded build-ids
On 14.08.2015 15:54, Jan Beulich wrote: On 14.08.15 at 14:59, mpohl...@amazon.com wrote: On 11.08.2015 16:12, Jan Beulich wrote: On 05.08.15 at 16:09, mpohl...@amazon.de wrote: Todo: * Should be moved to sysctl to only allow Dom0 access Because of? The discussion in this thread: [Xen-devel] [RFC PATCH v3.1 2/2] xsplice: Add hook for build_id was: -- Martin Pohlack: We should not expose the build_id to normal guests, but only to Dom0. A build_id uniquely identifies a specific build and I don't see how that information would be required from DomU. It might actually help an attacker to build his return-oriented programming exploit against a specific build. The normal version numbers should be enough to know about capabilities and API. Andrew Cooper: It will need its own XSM hook, but need not be strictly limited to just dom0. -- So I'm confused - I asked why Dom0 only and then you point me to Andrew saying it doesn't need to be Dom0 only? Sorry about that, my (not expressed) thinking was that we should restrict that to Dom0 for the XSM-disabled case. @@ -360,11 +366,30 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) case XENVER_build_id: { -xen_build_id_t build_id; +xen_build_id_t ascii_id; +Elf_Note * n = (Elf_Note *)__note_gnu_build_id_start; +char * binary_id; +int i; + +memset(ascii_id, 0, sizeof(ascii_id)); + +/* check if we really have a build-id */ +if ( NT_GNU_BUILD_ID != n-type ) +return 0; This needs to signal an error. Yes, ENOSYS, (or ENOENT, ENODATA)? Definitely not ENOSYS. ENODATA or EOPNOTSUPP. Jan Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger Ust-ID: DE289237879 Eingetragen am Amtsgericht Charlottenburg HRB 149173 B ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xsplice: Use ld-embedded build-ids
On 14.08.15 at 14:59, mpohl...@amazon.com wrote: On 11.08.2015 16:12, Jan Beulich wrote: On 05.08.15 at 16:09, mpohl...@amazon.de wrote: Todo: * Should be moved to sysctl to only allow Dom0 access Because of? The discussion in this thread: [Xen-devel] [RFC PATCH v3.1 2/2] xsplice: Add hook for build_id was: -- Martin Pohlack: We should not expose the build_id to normal guests, but only to Dom0. A build_id uniquely identifies a specific build and I don't see how that information would be required from DomU. It might actually help an attacker to build his return-oriented programming exploit against a specific build. The normal version numbers should be enough to know about capabilities and API. Andrew Cooper: It will need its own XSM hook, but need not be strictly limited to just dom0. -- So I'm confused - I asked why Dom0 only and then you point me to Andrew saying it doesn't need to be Dom0 only? @@ -360,11 +366,30 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) case XENVER_build_id: { -xen_build_id_t build_id; +xen_build_id_t ascii_id; +Elf_Note * n = (Elf_Note *)__note_gnu_build_id_start; +char * binary_id; +int i; + +memset(ascii_id, 0, sizeof(ascii_id)); + +/* check if we really have a build-id */ +if ( NT_GNU_BUILD_ID != n-type ) +return 0; This needs to signal an error. Yes, ENOSYS, (or ENOENT, ENODATA)? Definitely not ENOSYS. ENODATA or EOPNOTSUPP. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xsplice: Use ld-embedded build-ids
On 11.08.2015 16:12, Jan Beulich wrote: On 05.08.15 at 16:09, mpohl...@amazon.de wrote: Todo: * Should be moved to sysctl to only allow Dom0 access Because of? The discussion in this thread: [Xen-devel] [RFC PATCH v3.1 2/2] xsplice: Add hook for build_id was: -- Martin Pohlack: We should not expose the build_id to normal guests, but only to Dom0. A build_id uniquely identifies a specific build and I don't see how that information would be required from DomU. It might actually help an attacker to build his return-oriented programming exploit against a specific build. The normal version numbers should be enough to know about capabilities and API. Andrew Cooper: It will need its own XSM hook, but need not be strictly limited to just dom0. -- * Maybe convert to binary transport to userland instead of printable form Indeed. @@ -360,11 +366,30 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) case XENVER_build_id: { -xen_build_id_t build_id; +xen_build_id_t ascii_id; +Elf_Note * n = (Elf_Note *)__note_gnu_build_id_start; +char * binary_id; +int i; + +memset(ascii_id, 0, sizeof(ascii_id)); + +/* check if we really have a build-id */ +if ( NT_GNU_BUILD_ID != n-type ) +return 0; This needs to signal an error. Yes, ENOSYS, (or ENOENT, ENODATA)? + +/* sanity check, name should be GNU for ld-generated build-id */ +if ( 0 != strncmp(ELFNOTE_NAME(n), GNU, n-namesz)) +return 0; Same here. +binary_id = (char *)ELFNOTE_DESC(n); + +/* convert to printable format */ +for (i = 0; i n-descsz (i + 1) * 2 sizeof(xen_build_id_t); i++) +{ +snprintf(ascii_id[i * 2], 3, %02hhx, binary_id[i]); +} No need for the braces, and no need for thehh modifier. Jan Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger Ust-ID: DE289237879 Eingetragen am Amtsgericht Charlottenburg HRB 149173 B ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xsplice: Use ld-embedded build-ids
On 05.08.15 at 16:09, mpohl...@amazon.de wrote: Todo: * Should be moved to sysctl to only allow Dom0 access Because of? * Maybe convert to binary transport to userland instead of printable form Indeed. @@ -360,11 +366,30 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) case XENVER_build_id: { -xen_build_id_t build_id; +xen_build_id_t ascii_id; +Elf_Note * n = (Elf_Note *)__note_gnu_build_id_start; +char * binary_id; +int i; + +memset(ascii_id, 0, sizeof(ascii_id)); + +/* check if we really have a build-id */ +if ( NT_GNU_BUILD_ID != n-type ) +return 0; This needs to signal an error. + +/* sanity check, name should be GNU for ld-generated build-id */ +if ( 0 != strncmp(ELFNOTE_NAME(n), GNU, n-namesz)) +return 0; Same here. +binary_id = (char *)ELFNOTE_DESC(n); + +/* convert to printable format */ +for (i = 0; i n-descsz (i + 1) * 2 sizeof(xen_build_id_t); i++) +{ +snprintf(ascii_id[i * 2], 3, %02hhx, binary_id[i]); +} No need for the braces, and no need for thehh modifier. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel