On Tue, 23 Jan 2024 00:26:59 +0000,
Kees Cook <keesc...@chromium.org> wrote:
>
> In an effort to separate intentional arithmetic wrap-around from
> unexpected wrap-around, we need to refactor places that depend on this
> kind of math. One of the most common code patterns of this is:
>
> VAR + value < VAR
>
> Notably, this is considered "undefined behavior" for signed and pointer
> types, which the kernel works around by using the -fno-strict-overflow
> option in the build[1] (which used to just be -fwrapv). Regardless, we
> want to get the kernel source to the position where we can meaningfully
> instrument arithmetic wrap-around conditions and catch them when they
> are unexpected, regardless of whether they are signed[2], unsigned[3],
> or pointer[4] types.
>
> Refactor open-coded unsigned wrap-around addition test to use
> check_add_overflow(), retaining the result for later usage (which removes
> the redundant open-coded addition). This paves the way to enabling the
> wrap-around sanitizers in the future.
>
> Link: https://git.kernel.org/linus/68df3755e383e6fecf2354a67b08f92f18536594
> [1]
> Link: https://github.com/KSPP/linux/issues/26 [2]
> Link: https://github.com/KSPP/linux/issues/27 [3]
> Link: https://github.com/KSPP/linux/issues/344 [4]
> Cc: Marc Zyngier <m...@kernel.org>
> Cc: Oliver Upton <oliver.up...@linux.dev>
> Cc: James Morse <james.mo...@arm.com>
> Cc: Suzuki K Poulose <suzuki.poul...@arm.com>
> Cc: Zenghui Yu <yuzeng...@huawei.com>
> Cc: Catalin Marinas <catalin.mari...@arm.com>
> Cc: Will Deacon <w...@kernel.org>
> Cc: Reiji Watanabe <rei...@google.com>
> Cc: Eric Auger <eric.au...@redhat.com>
> Cc: Ricardo Koller <ricar...@google.com>
> Cc: Raghavendra Rao Ananta <rana...@google.com>
> Cc: Quentin Perret <qper...@google.com>
> Cc: Jean-Philippe Brucker <jean-phili...@linaro.org>
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: kvm...@lists.linux.dev
> Signed-off-by: Kees Cook <keesc...@chromium.org>
> ---
> arch/arm64/kvm/vgic/vgic-kvm-device.c | 6 ++++--
> arch/arm64/kvm/vgic/vgic-v2.c | 10 ++++++----
> 2 files changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm64/kvm/vgic/vgic-kvm-device.c
> b/arch/arm64/kvm/vgic/vgic-kvm-device.c
> index f48b8dab8b3d..0eec5344d203 100644
> --- a/arch/arm64/kvm/vgic/vgic-kvm-device.c
> +++ b/arch/arm64/kvm/vgic/vgic-kvm-device.c
> @@ -18,17 +18,19 @@ int vgic_check_iorange(struct kvm *kvm, phys_addr_t
> ioaddr,
> phys_addr_t addr, phys_addr_t alignment,
> phys_addr_t size)
> {
> + phys_addr_t sum;
> +
> if (!IS_VGIC_ADDR_UNDEF(ioaddr))
> return -EEXIST;
>
> if (!IS_ALIGNED(addr, alignment) || !IS_ALIGNED(size, alignment))
> return -EINVAL;
>
> - if (addr + size < addr)
> + if (check_add_overflow(addr, size, &sum))
> return -EINVAL;
>
> if (addr & ~kvm_phys_mask(&kvm->arch.mmu) ||
> - (addr + size) > kvm_phys_size(&kvm->arch.mmu))
> + sum > kvm_phys_size(&kvm->arch.mmu))
nit: 'sum' doesn't mean much in this context. Something like 'end'
would be much more descriptive.
> return -E2BIG;
>
> return 0;
> diff --git a/arch/arm64/kvm/vgic/vgic-v2.c b/arch/arm64/kvm/vgic/vgic-v2.c
> index 7e9cdb78f7ce..c8d1e965d3b7 100644
> --- a/arch/arm64/kvm/vgic/vgic-v2.c
> +++ b/arch/arm64/kvm/vgic/vgic-v2.c
> @@ -273,14 +273,16 @@ void vgic_v2_enable(struct kvm_vcpu *vcpu)
> /* check for overlapping regions and for regions crossing the end of memory
> */
> static bool vgic_v2_check_base(gpa_t dist_base, gpa_t cpu_base)
> {
> - if (dist_base + KVM_VGIC_V2_DIST_SIZE < dist_base)
> + gpa_t dist_sum, cpu_sum;
Same here: dist_end, cpu_end.
> +
> + if (check_add_overflow(dist_base, KVM_VGIC_V2_DIST_SIZE, &dist_sum))
> return false;
> - if (cpu_base + KVM_VGIC_V2_CPU_SIZE < cpu_base)
> + if (check_add_overflow(cpu_base, KVM_VGIC_V2_CPU_SIZE, &cpu_sum))
> return false;
>
> - if (dist_base + KVM_VGIC_V2_DIST_SIZE <= cpu_base)
> + if (dist_sum <= cpu_base)
> return true;
> - if (cpu_base + KVM_VGIC_V2_CPU_SIZE <= dist_base)
> + if (cpu_sum <= dist_base)
> return true;
>
> return false;
With these nits addressed, and assuming you intend to merge the whole
series yourself:
Acked-by: Marc Zyngier <m...@kernel.org>
M.
--
Without deviation from the norm, progress is not possible.
