1. 14 May, 2021 3 commits
    • Connor Davis's avatar
      automation: add container for riscv64 builds · 3fc237b4
      Connor Davis authored
      
      
      Add a container for cross-compiling xen to riscv64.
      This just includes the cross-compiler and necessary packages for
      building xen itself (packages for tools, stubdoms, etc., can be
      added later).
      
      To build xen in the container run the following:
      
      $ make XEN_TARGET_ARCH=riscv64 SUBSYSTEMS=xen
      Signed-off-by: default avatarConnor Davis <connojdavis@gmail.com>
      3fc237b4
    • Connor Davis's avatar
      xen: Add files needed for minimal riscv build · c5d130b0
      Connor Davis authored
      
      
      Add the minimum code required to get xen to build with
      XEN_TARGET_ARCH=riscv64. It is minimal in the sense that every file and
      function added is required for a successful build, given the .config
      generated from riscv64_defconfig. The function implementations are just
      stubs; actual implmentations will need to be added later.
      Signed-off-by: default avatarConnor Davis <connojdavis@gmail.com>
      c5d130b0
    • Connor Davis's avatar
      xen: Fix build when !CONFIG_GRANT_TABLE · 834f7995
      Connor Davis authored
      
      
      Move struct grant_table; in grant_table.h above
      ifdef CONFIG_GRANT_TABLE. This fixes the following:
      
      /build/xen/include/xen/grant_table.h:84:50: error: 'struct grant_table'
      declared inside parameter list will not be visible outside of this
      definition or declaration [-Werror]
         84 | static inline int mem_sharing_gref_to_gfn(struct grant_table *gt,
            |
      Signed-off-by: default avatarConnor Davis <connojdavis@gmail.com>
      834f7995
  2. 12 May, 2021 2 commits
  3. 10 May, 2021 22 commits
    • Volodymyr Babchuk's avatar
      optee: enable OPTEE_SMC_SEC_CAP_MEMREF_NULL capability · d4fb5f16
      Volodymyr Babchuk authored
      OP-TEE mediator already have support for NULL memory references. It
      was added in patch 0dbed3ad
      
       ("optee: allow plain TMEM buffers with
      NULL address"). But it does not propagate
      OPTEE_SMC_SEC_CAP_MEMREF_NULL capability flag to a guest, so well
      behaving guest can't use this feature.
      
      Note: linux optee driver honors this capability flag when handling
      buffers from userspace clients, but ignores it when working with
      internal calls. For instance, __optee_enumerate_devices() function
      uses NULL argument to get buffer size hint from OP-TEE. This was the
      reason, why "optee: allow plain TMEM buffers with NULL address" was
      introduced in the first place.
      
      This patch adds the mentioned capability to list of known
      capabilities. From Linux point of view it means that userspace clients
      can use this feature, which is confirmed by OP-TEE test suite:
      
      * regression_1025 Test memref NULL and/or 0 bytes size
      o regression_1025.1 Invalid NULL buffer memref registration
        regression_1025.1 OK
      o regression_1025.2 Input/Output MEMREF Buffer NULL - Size 0 bytes
        regression_1025.2 OK
      o regression_1025.3 Input MEMREF Buffer NULL - Size non 0 bytes
        regression_1025.3 OK
      o regression_1025.4 Input MEMREF Buffer NULL over PTA invocation
        regression_1025.4 OK
        regression_1025 OK
      Signed-off-by: default avatarVolodymyr Babchuk <volodymyr_babchuk@epam.com>
      Acked-by: default avatarJulien Grall <jgrall@amazon.com>
      d4fb5f16
    • Julien Grall's avatar
      tools/xenstore: Fix indentation in the header of xenstored_control.c · 30f34457
      Julien Grall authored
      Commit e867af08
      
       "tools/xenstore: save new binary for live update"
      seemed to have spuriously changed the indentation of the first line of
      the copyright header.
      
      The previous indentation is re-instated so all the lines are indented
      the same.
      Reported-by: default avatarBjoern Doebel <doebel@amazon.com>
      Signed-off-by: default avatarJulien Grall <jgrall@amazon.com>
      Reviewed-by: Juergen Gross's avatarJuergen Gross <jgross@suse.com>
      30f34457
    • Julien Grall's avatar
      tools/xenstored: Prevent a buffer overflow in dump_state_node_perms() · 7e71b1e0
      Julien Grall authored
      ASAN reported one issue when Live Updating Xenstored:
      
      =================================================================
      ==873==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffc194f53e0 at pc 0x555c6b323292 bp 0x7ffc194f5340 sp 0x7ffc194f5338
      WRITE of size 1 at 0x7ffc194f53e0 thread T0
          #0 0x555c6b323291 in dump_state_node_perms xen/tools/xenstore/xenstored_core.c:2468
          #1 0x555c6b32746e in dump_state_special_node xen/tools/xenstore/xenstored_domain.c:1257
          #2 0x555c6b32a702 in dump_state_special_nodes xen/tools/xenstore/xenstored_domain.c:1273
          #3 0x555c6b32ddb3 in lu_dump_state xen/tools/xenstore/xenstored_control.c:521
          #4 0x555c6b32e380 in do_lu_start xen/tools/xenstore/xenstored_control.c:660
          #5 0x555c6b31b461 in call_delayed xen/tools/xenstore/xenstored_core.c:278
          #6 0x555c6b32275e in main xen/tools/xenstore/xenstored_core.c:2357
          #7 0x7f95eecf3d09 in __libc_start_main ../csu/libc-start.c:308
          #8 0x555c6b3197e9 in _start (/usr/local/sbin/xenstored+0xc7e9)
      
      Address 0x7ffc194f53e0 is located in stack of thread T0 at offset 80 in frame
          #0 0x555c6b32713e in dump_state_special_node xen/tools/xenstore/xenstored_domain.c:1232
      
        This frame has 2 object(s):
          [32, 40) 'head' (line 1233)
          [64, 80) 'sn' (line 1234) <== Memory access at offset 80 overflows this variable
      
      This is happening because the callers are passing a pointer to a variable
      allocated on the stack. However, the field perms is a dynamic array, so
      Xenstored will end up to read outside of the variable.
      
      Rework the code so the permissions are written one by one in the fd.
      
      Fixes: ed6eebf1
      
       ("tools/xenstore: dump the xenstore state for live update")
      Signed-off-by: default avatarJulien Grall <jgrall@amazon.com>
      Reviewed-by: Juergen Gross's avatarJuergen Gross <jgross@suse.com>
      Reviewed-by: Luca Fancellu's avatarLuca Fancellu <luca.fancellu@arm.com>
      7e71b1e0
    • Michal Orzel's avatar
      arm/time,vtimer: Get rid of READ/WRITE_SYSREG32 · 3f568354
      Michal Orzel authored
      
      
      AArch64 registers are 64bit whereas AArch32 registers
      are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
      we should get rid of helpers READ/WRITE_SYSREG32
      in favour of using READ/WRITE_SYSREG.
      We should also use register_t type when reading sysregs
      which can correspond to uint64_t or uint32_t.
      Even though many AArch64 registers have upper 32bit reserved
      it does not mean that they can't be widen in the future.
      
      Modify type of vtimer structure's member: ctl to register_t.
      
      Add macro CNTFRQ_MASK containing mask for timer clock frequency
      field of CNTFRQ_EL0 register.
      
      Modify CNTx_CTL_* macros to return unsigned long instead of
      unsigned int as ctl is now of type register_t.
      Signed-off-by: default avatarMichal Orzel <michal.orzel@arm.com>
      Acked-by: default avatarJulien Grall <jgrall@amazon.com>
      3f568354
    • Michal Orzel's avatar
      arm/page: Get rid of READ/WRITE_SYSREG32 · 86faae56
      Michal Orzel authored
      
      
      AArch64 registers are 64bit whereas AArch32 registers
      are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
      we should get rid of helpers READ/WRITE_SYSREG32
      in favour of using READ/WRITE_SYSREG.
      We should also use register_t type when reading sysregs
      which can correspond to uint64_t or uint32_t.
      Even though many AArch64 registers have upper 32bit reserved
      it does not mean that they can't be widen in the future.
      
      Modify accesses to CTR_EL0 to use READ/WRITE_SYSREG.
      Signed-off-by: default avatarMichal Orzel <michal.orzel@arm.com>
      Reviewed-by: default avatarJulien Grall <jgrall@amazon.com>
      86faae56
    • Michal Orzel's avatar
      xen/arm: Always access SCTLR_EL2 using READ/WRITE_SYSREG() · 25e5d0c4
      Michal Orzel authored
      
      
      The Armv8 specification describes the system register as a 64-bit value
      on AArch64 and 32-bit value on AArch32 (same as ARMv7).
      
      Unfortunately, Xen is accessing the system registers using
      READ/WRITE_SYSREG32() which means the top 32-bit are clobbered.
      
      This is only a latent bug so far because Xen will not yet use the top
      32-bit.
      
      There is also no change in behavior because arch/arm/arm64/head.S will
      initialize SCTLR_EL2 to a sane value with the top 32-bit zeroed.
      Signed-off-by: default avatarMichal Orzel <michal.orzel@arm.com>
      Acked-by: default avatarJulien Grall <jgrall@amazon.com>
      25e5d0c4
    • Michal Orzel's avatar
      arm/p2m: Get rid of READ/WRITE_SYSREG32 · 8eb7cc04
      Michal Orzel authored
      
      
      AArch64 registers are 64bit whereas AArch32 registers
      are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
      we should get rid of helpers READ/WRITE_SYSREG32
      in favour of using READ/WRITE_SYSREG.
      We should also use register_t type when reading sysregs
      which can correspond to uint64_t or uint32_t.
      Even though many AArch64 registers have upper 32bit reserved
      it does not mean that they can't be widen in the future.
      
      Modify type of vtcr to register_t.
      Signed-off-by: default avatarMichal Orzel <michal.orzel@arm.com>
      Reviewed-by: default avatarJulien Grall <jgrall@amazon.com>
      8eb7cc04
    • Michal Orzel's avatar
      arm/gic: Get rid of READ/WRITE_SYSREG32 · 78e67c99
      Michal Orzel authored
      
      
      AArch64 registers are 64bit whereas AArch32 registers
      are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
      we should get rid of helpers READ/WRITE_SYSREG32
      in favour of using READ/WRITE_SYSREG.
      We should also use register_t type when reading sysregs
      which can correspond to uint64_t or uint32_t.
      Even though many AArch64 registers have upper 32bit reserved
      it does not mean that they can't be widen in the future.
      
      Modify types of following members of struct gic_v3 to register_t:
      -vmcr
      -sre_el1
      -apr0
      -apr1
      
      Add new macro GICC_IAR_INTID_MASK containing the mask
      for INTID field of ICC_IAR0/1_EL1 register as only the first 23-bits
      of IAR contains the interrupt number. The rest are RES0.
      Therefore, take the opportunity to mask the bits [23:31] as
      they should be used for an IRQ number (we don't know how the top bits
      will be used).
      Signed-off-by: default avatarMichal Orzel <michal.orzel@arm.com>
      Acked-by: default avatarJulien Grall <jgrall@amazon.com>
      78e67c99
    • Michal Orzel's avatar
      arm/gic: Remove member hcr of structure gic_v3 · d55afb1a
      Michal Orzel authored
      
      
      ... as it is never used even in the patch introducing it.
      Signed-off-by: default avatarMichal Orzel <michal.orzel@arm.com>
      Acked-by: default avatarJulien Grall <jgrall@amazon.com>
      d55afb1a
    • Michal Orzel's avatar
      arm: Modify type of actlr to register_t · b80470c8
      Michal Orzel authored
      
      
      AArch64 registers are 64bit whereas AArch32 registers
      are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
      we should get rid of helpers READ/WRITE_SYSREG32
      in favour of using READ/WRITE_SYSREG.
      We should also use register_t type when reading sysregs
      which can correspond to uint64_t or uint32_t.
      Even though many AArch64 registers have upper 32bit reserved
      it does not mean that they can't be widen in the future.
      
      ACTLR_EL1 system register bits are implementation defined
      which means it is possibly a latent bug on current HW as the CPU
      implementer may already have decided to use the top 32bit.
      Signed-off-by: default avatarMichal Orzel <michal.orzel@arm.com>
      Reviewed-by: default avatarJulien Grall <jgrall@amazon.com>
      b80470c8
    • Michal Orzel's avatar
      arm/domain: Get rid of READ/WRITE_SYSREG32 · 3fd8336b
      Michal Orzel authored
      
      
      AArch64 registers are 64bit whereas AArch32 registers
      are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
      we should get rid of helpers READ/WRITE_SYSREG32
      in favour of using READ/WRITE_SYSREG.
      We should also use register_t type when reading sysregs
      which can correspond to uint64_t or uint32_t.
      Even though many AArch64 registers have upper 32bit reserved
      it does not mean that they can't be widen in the future.
      
      Modify type of register cntkctl to register_t.
      
      Thumbee registers are only usable by a 32-bit domain and therefore
      we can just store the bottom 32-bit (IOW there is no type change).
      In fact, this could technically be restricted to Armv7 HW (the
      support was dropped retrospectively in Armv8) but leave it as-is
      for now.
      Signed-off-by: default avatarMichal Orzel <michal.orzel@arm.com>
      Reviewed-by: default avatarJulien Grall <jgrall@amazon.com>
      3fd8336b
    • Michal Orzel's avatar
      arm64/vfp: Get rid of READ/WRITE_SYSREG32 · 8990f0ea
      Michal Orzel authored
      
      
      AArch64 registers are 64bit whereas AArch32 registers
      are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
      we should get rid of helpers READ/WRITE_SYSREG32
      in favour of using READ/WRITE_SYSREG.
      We should also use register_t type when reading sysregs
      which can correspond to uint64_t or uint32_t.
      Even though many AArch64 registers have upper 32bit reserved
      it does not mean that they can't be widen in the future.
      
      Modify type of FPCR, FPSR, FPEXC32_EL2 to register_t.
      Signed-off-by: default avatarMichal Orzel <michal.orzel@arm.com>
      Reviewed-by: default avatarJulien Grall <jgrall@amazon.com>
      8990f0ea
    • Olaf Hering's avatar
      tools: add newlines to xenstored WRL_LOG · 982c89ed
      Olaf Hering authored and Andrew Cooper's avatar Andrew Cooper committed
      
      
      According to syslog(3) the fmt string does not need a newline.
      The mini-os implementation of syslog requires the trailing newline.
      Other calls to syslog do include the newline already, add it also to WRL_LOG.
      Signed-off-by: Olaf Hering's avatarOlaf Hering <olaf@aepfle.de>
      Reviewed-by: Juergen Gross's avatarJuergen Gross <jgross@suse.com>
      982c89ed
    • jandryuk's avatar
      vtpm: Correct timeout units and command duration · fdff034b
      jandryuk authored and Andrew Cooper's avatar Andrew Cooper committed
      
      
      Add two patches:
      vtpm-microsecond-duration.patch fixes the units for timeouts and command
      durations.
      vtpm-command-duration.patch increases the timeout linux uses to allow
      commands to succeed.
      
      Linux works around low timeouts, but not low durations.  The second
      patch allows commands to complete that often timeout with the lower
      command durations.
      Signed-off-by: jandryuk's avatarJason Andryuk <jandryuk@gmail.com>
      Reviewed-by: Samuel Thibault's avatarSamuel Thibault <samuel.thibault@ens-lyon.org>
      Reviewed-by: Daniel P. Smith's avatarDaniel P. Smith <dpsmith@apertussolutions.com>
      fdff034b
    • jandryuk's avatar
      vtpmmgr: Check req_len before unpacking command · 5974702b
      jandryuk authored and Andrew Cooper's avatar Andrew Cooper committed
      
      
      vtpm_handle_cmd doesn't ensure there is enough space before unpacking
      the req buffer.  Add a minimum size check.  Called functions will have
      to do their own checking if they need more data from the request.
      
      The error case is tricky since abort_egress wants to rely with a
      corresponding tag.  Just hardcode TPM_TAG_RQU_COMMAND since the vtpm is
      sending in malformed commands in the first place.
      Signed-off-by: jandryuk's avatarJason Andryuk <jandryuk@gmail.com>
      Reviewed-by: Samuel Thibault's avatarSamuel Thibault <samuel.thibault@ens-lyon.org>
      Reviewed-by: Daniel P. Smith's avatarDaniel P. Smith <dpsmith@apertussolutions.com>
      5974702b
    • jandryuk's avatar
      vtpmmgr: Fix owner_auth & srk_auth parsing · c8d8a1e2
      jandryuk authored and Andrew Cooper's avatar Andrew Cooper committed
      
      
      Argument parsing only matches to before ':' and then the string with
      leading ':' is passed to parse_auth_string which fails to parse.  Extend
      the length to include the seperator in the match.
      
      While here, switch the seperator to "=".  The man page documented "="
      and the other tpm.* arguments already use "=".  Since it didn't work
      before, we don't need to worry about backwards compatibility.
      Signed-off-by: jandryuk's avatarJason Andryuk <jandryuk@gmail.com>
      Reviewed-by: Samuel Thibault's avatarSamuel Thibault <samuel.thibault@ens-lyon.org>
      Reviewed-by: Daniel P. Smith's avatarDaniel P. Smith <dpsmith@apertussolutions.com>
      c8d8a1e2
    • jandryuk's avatar
      vtpmmgr: Remove bogus cast from TPM2_GetRandom · 7f4276fa
      jandryuk authored and Andrew Cooper's avatar Andrew Cooper committed
      
      
      The UINT32 <-> UINT16 casting in TPM2_GetRandom is incorrect.  Use a
      local UINT16 as needed for the TPM hardware command and assign the
      result.
      Suggested-by: Samuel Thibault's avatarSamuel Thibault <samuel.thibault@ens-lyon.org>
      Signed-off-by: jandryuk's avatarJason Andryuk <jandryuk@gmail.com>
      Reviewed-by: Samuel Thibault's avatarSamuel Thibault <samuel.thibault@ens-lyon.org>
      Reviewed-by: Daniel P. Smith's avatarDaniel P. Smith <dpsmith@apertussolutions.com>
      7f4276fa
    • jandryuk's avatar
      vtpmmgr: Support GetRandom passthrough on TPM 2.0 · 64d00dd1
      jandryuk authored and Andrew Cooper's avatar Andrew Cooper committed
      
      
      GetRandom passthrough currently fails when using vtpmmgr with a hardware
      TPM 2.0.
      vtpmmgr (8): INFO[VTPM]: Passthrough: TPM_GetRandom
      vtpm (12): vtpm_cmd.c:120: Error: TPM_GetRandom() failed with error code (30)
      
      When running on TPM 2.0 hardware, vtpmmgr needs to convert the TPM 1.2
      TPM_ORD_GetRandom into a TPM2 TPM_CC_GetRandom command.  Besides the
      differing ordinal, the TPM 1.2 uses 32bit sizes for the request and
      response (vs. 16bit for TPM2).
      
      Place the random output directly into the tpmcmd->resp and build the
      packet around it.  This avoids bouncing through an extra buffer, but the
      header has to be written after grabbing the random bytes so we have the
      number of bytes to include in the size.
      Signed-off-by: jandryuk's avatarJason Andryuk <jandryuk@gmail.com>
      Reviewed-by: Samuel Thibault's avatarSamuel Thibault <samuel.thibault@ens-lyon.org>
      Reviewed by: Daniel P. Smith <dpsmith@apertussolutions.com>
      64d00dd1
    • jandryuk's avatar
      vtpmmgr: Shutdown more gracefully · 1b4bfa0b
      jandryuk authored and Andrew Cooper's avatar Andrew Cooper committed
      
      
      vtpmmgr uses the default, weak app_shutdown, which immediately calls the
      shutdown hypercall.  This short circuits the vtpmmgr clean up logic.  We
      need to perform the clean up to actually Flush our key out of the tpm.
      
      Setting do_shutdown is one step in that direction, but vtpmmgr will most
      likely be waiting in tpmback_req_any.  We need to call shutdown_tpmback
      to cancel the wait inside tpmback and perform the shutdown.
      Signed-off-by: jandryuk's avatarJason Andryuk <jandryuk@gmail.com>
      Reviewed-by: default avatarSamuel Thibault <samuel.thibaut@ens-lyon.org>
      Reviewed-by: Daniel P. Smith's avatarDaniel P. Smith <dpsmith@apertussolutions.com>
      1b4bfa0b
    • jandryuk's avatar
      vtpmmgr: Flush all transient keys · 746d20b1
      jandryuk authored and Andrew Cooper's avatar Andrew Cooper committed
      
      
      We're only flushing 2 transients, but there are 3 handles.  Use <= to also
      flush the third handle since TRANSIENT_LAST is inclusive
      
      The number of transient handles/keys is hardware dependent, so this
      should query for the limit.  And assignment of handles is assumed to be
      sequential from the minimum.  That may not be guaranteed, but seems okay
      with my tpm2.
      Signed-off-by: jandryuk's avatarJason Andryuk <jandryuk@gmail.com>
      Reviewed-by: Samuel Thibault's avatarSamuel Thibault <samuel.thibault@ens-lyon.org>
      Reviewed-by: Daniel P. Smith's avatarDaniel P. Smith <dpsmith@apertussolutions.com>
      746d20b1
    • jandryuk's avatar
      vtpmmgr: Flush transient keys on shutdown · ec9596dc
      jandryuk authored and Andrew Cooper's avatar Andrew Cooper committed
      
      
      Remove our key so it isn't left in the TPM for someone to come along
      after vtpmmgr shutsdown.
      Signed-off-by: jandryuk's avatarJason Andryuk <jandryuk@gmail.com>
      Reviewed-by: Samuel Thibault's avatarSamuel Thibault <samuel.thibault@ens-lyon.org>
      Reviewed-by: Daniel P. Smith's avatarDaniel P. Smith <dpsmith@apertussolutions.com>
      ec9596dc
    • jandryuk's avatar
      vtpmmgr: Allow specifying srk_handle for TPM2 · 3f1b5080
      jandryuk authored and Andrew Cooper's avatar Andrew Cooper committed
      
      
      Bypass taking ownership of the TPM2 if an srk_handle is specified.
      
      This srk_handle must be usable with Null auth for the time being.
      Signed-off-by: jandryuk's avatarJason Andryuk <jandryuk@gmail.com>
      Reviewed-by: Samuel Thibault's avatarSamuel Thibault <samuel.thibault@ens-lyon.org>
      Reviewed-by: Daniel P. Smith's avatarDaniel P. Smith <dpsmith@apertussolutions.com>
      3f1b5080
  4. 07 May, 2021 7 commits
  5. 05 May, 2021 4 commits
  6. 04 May, 2021 2 commits