From: Schspa Shi <schspa@gmail.com>
To: Marc Zyngier <maz@kernel.org>
Cc: will@kernel.org, catalin.marinas@arm.com,
linux-kernel@vger.kernel.org, kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] KVM: arm64: Fix 64 bit mmio handle
Date: Wed, 06 Jul 2022 19:29:58 +0800 [thread overview]
Message-ID: <m25ykawk7f.fsf@gmail.com> (raw)
In-Reply-To: <87edyyn2a5.wl-maz@kernel.org>
Marc Zyngier <maz@kernel.org> writes:
> On Fri, 01 Jul 2022 15:22:51 +0100,
> Schspa Shi <schspa@gmail.com> wrote:
>>
>>
>> Marc Zyngier <maz@kernel.org> writes:
>>
>> >>
>> >> I have running some static code analysis software upon
>> >> Kernel code.
>> >> Seeing there is possible overflow.
>> >>
>> >> maks << 1U << ((len * 8) -1);
>> >>
>> >> The AI don't know, len is only the value of 1, 2, 4, and
>> >> make this
>> >> a warnings
>> >>
>> >> I tring to analysis this, but didn't realize the real
>> >> scenario of
>> >> sign extension, and finally sent this problematic patch.
>> >>
>> >> I do see some uninitialized memory reads (the values are not
>> >> used
>> >> in the end, just as temporary space for API execution),
>> >> do we need to fix these?
>> >
>> > You need to be more descriptive here. What uninitialised
>> > reads? In
>> > general, pointing at the code and providing a full
>> > description of
>> > what
>> > you think is incorrect would really help...
>> >
>> > M.
>> One example is
>> int vgic_v3_has_attr_regs(struct kvm_device *dev, struct
>> kvm_device_attr *attr)
>> {
>> ...
>> case KVM_DEV_ARM_VGIC_GRP_CPU_SYSREGS: {
>> u64 reg, id;
>>
>> id = (attr->attr & KVM_DEV_ARM_VGIC_SYSREG_INSTR_MASK);
>> return vgic_v3_has_cpu_sysregs_attr(vcpu, 0, id, ®);
>> }
>>
>> }
>>
>> The funcion vgic_v3_has_cpu_sysregs_attr will read reg's value
>> to
>> params without initialization. There should have no problems,
>> because the register value never used.
>
> Thanks for pointing this out.
>
> I spent some time looking at this, and this is only the tip of
> the
> iceberg. The whole userspace interaction with the GIC sysregs is
> ugly
> (at best), and needs some love.
>
> I've written a small series[1] cleaning things up, which needs
> testing
> (I've just checked that it was compiling correctly). I'd
> appreciate
> you running your tool on it.
>
I have run static code analysis software upon this branch, and the
warnings have gone.
> M.
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=kvm-arm64/sysreg-cleanup-5.20
--
BRs
Schspa Shi
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
WARNING: multiple messages have this Message-ID (diff)
From: Schspa Shi <schspa@gmail.com>
To: Marc Zyngier <maz@kernel.org>
Cc: james.morse@arm.com, alexandru.elisei@arm.com,
suzuki.poulose@arm.com, catalin.marinas@arm.com, will@kernel.org,
linux-arm-kernel@lists.infradead.org,
kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] KVM: arm64: Fix 64 bit mmio handle
Date: Wed, 06 Jul 2022 19:29:58 +0800 [thread overview]
Message-ID: <m25ykawk7f.fsf@gmail.com> (raw)
In-Reply-To: <87edyyn2a5.wl-maz@kernel.org>
Marc Zyngier <maz@kernel.org> writes:
> On Fri, 01 Jul 2022 15:22:51 +0100,
> Schspa Shi <schspa@gmail.com> wrote:
>>
>>
>> Marc Zyngier <maz@kernel.org> writes:
>>
>> >>
>> >> I have running some static code analysis software upon
>> >> Kernel code.
>> >> Seeing there is possible overflow.
>> >>
>> >> maks << 1U << ((len * 8) -1);
>> >>
>> >> The AI don't know, len is only the value of 1, 2, 4, and
>> >> make this
>> >> a warnings
>> >>
>> >> I tring to analysis this, but didn't realize the real
>> >> scenario of
>> >> sign extension, and finally sent this problematic patch.
>> >>
>> >> I do see some uninitialized memory reads (the values are not
>> >> used
>> >> in the end, just as temporary space for API execution),
>> >> do we need to fix these?
>> >
>> > You need to be more descriptive here. What uninitialised
>> > reads? In
>> > general, pointing at the code and providing a full
>> > description of
>> > what
>> > you think is incorrect would really help...
>> >
>> > M.
>> One example is
>> int vgic_v3_has_attr_regs(struct kvm_device *dev, struct
>> kvm_device_attr *attr)
>> {
>> ...
>> case KVM_DEV_ARM_VGIC_GRP_CPU_SYSREGS: {
>> u64 reg, id;
>>
>> id = (attr->attr & KVM_DEV_ARM_VGIC_SYSREG_INSTR_MASK);
>> return vgic_v3_has_cpu_sysregs_attr(vcpu, 0, id, ®);
>> }
>>
>> }
>>
>> The funcion vgic_v3_has_cpu_sysregs_attr will read reg's value
>> to
>> params without initialization. There should have no problems,
>> because the register value never used.
>
> Thanks for pointing this out.
>
> I spent some time looking at this, and this is only the tip of
> the
> iceberg. The whole userspace interaction with the GIC sysregs is
> ugly
> (at best), and needs some love.
>
> I've written a small series[1] cleaning things up, which needs
> testing
> (I've just checked that it was compiling correctly). I'd
> appreciate
> you running your tool on it.
>
I have run static code analysis software upon this branch, and the
warnings have gone.
> M.
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=kvm-arm64/sysreg-cleanup-5.20
--
BRs
Schspa Shi
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Schspa Shi <schspa@gmail.com>
To: Marc Zyngier <maz@kernel.org>
Cc: james.morse@arm.com, alexandru.elisei@arm.com,
suzuki.poulose@arm.com, catalin.marinas@arm.com, will@kernel.org,
linux-arm-kernel@lists.infradead.org,
kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] KVM: arm64: Fix 64 bit mmio handle
Date: Wed, 06 Jul 2022 19:29:58 +0800 [thread overview]
Message-ID: <m25ykawk7f.fsf@gmail.com> (raw)
In-Reply-To: <87edyyn2a5.wl-maz@kernel.org>
Marc Zyngier <maz@kernel.org> writes:
> On Fri, 01 Jul 2022 15:22:51 +0100,
> Schspa Shi <schspa@gmail.com> wrote:
>>
>>
>> Marc Zyngier <maz@kernel.org> writes:
>>
>> >>
>> >> I have running some static code analysis software upon
>> >> Kernel code.
>> >> Seeing there is possible overflow.
>> >>
>> >> maks << 1U << ((len * 8) -1);
>> >>
>> >> The AI don't know, len is only the value of 1, 2, 4, and
>> >> make this
>> >> a warnings
>> >>
>> >> I tring to analysis this, but didn't realize the real
>> >> scenario of
>> >> sign extension, and finally sent this problematic patch.
>> >>
>> >> I do see some uninitialized memory reads (the values are not
>> >> used
>> >> in the end, just as temporary space for API execution),
>> >> do we need to fix these?
>> >
>> > You need to be more descriptive here. What uninitialised
>> > reads? In
>> > general, pointing at the code and providing a full
>> > description of
>> > what
>> > you think is incorrect would really help...
>> >
>> > M.
>> One example is
>> int vgic_v3_has_attr_regs(struct kvm_device *dev, struct
>> kvm_device_attr *attr)
>> {
>> ...
>> case KVM_DEV_ARM_VGIC_GRP_CPU_SYSREGS: {
>> u64 reg, id;
>>
>> id = (attr->attr & KVM_DEV_ARM_VGIC_SYSREG_INSTR_MASK);
>> return vgic_v3_has_cpu_sysregs_attr(vcpu, 0, id, ®);
>> }
>>
>> }
>>
>> The funcion vgic_v3_has_cpu_sysregs_attr will read reg's value
>> to
>> params without initialization. There should have no problems,
>> because the register value never used.
>
> Thanks for pointing this out.
>
> I spent some time looking at this, and this is only the tip of
> the
> iceberg. The whole userspace interaction with the GIC sysregs is
> ugly
> (at best), and needs some love.
>
> I've written a small series[1] cleaning things up, which needs
> testing
> (I've just checked that it was compiling correctly). I'd
> appreciate
> you running your tool on it.
>
I have run static code analysis software upon this branch, and the
warnings have gone.
> M.
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=kvm-arm64/sysreg-cleanup-5.20
--
BRs
Schspa Shi
next prev parent reply other threads:[~2022-07-06 11:44 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-30 16:12 [PATCH] KVM: arm64: Fix 64 bit mmio handle Schspa Shi
2022-06-30 16:12 ` Schspa Shi
2022-06-30 16:12 ` Schspa Shi
2022-06-30 16:23 ` Marc Zyngier
2022-06-30 16:23 ` Marc Zyngier
2022-06-30 16:23 ` Marc Zyngier
2022-06-30 16:50 ` Schspa Shi
2022-06-30 16:50 ` Schspa Shi
2022-06-30 16:50 ` Schspa Shi
2022-07-01 10:50 ` Marc Zyngier
2022-07-01 10:50 ` Marc Zyngier
2022-07-01 10:50 ` Marc Zyngier
2022-07-01 12:22 ` Schspa Shi
2022-07-01 12:22 ` Schspa Shi
2022-07-01 12:22 ` Schspa Shi
2022-07-01 13:48 ` Marc Zyngier
2022-07-01 13:48 ` Marc Zyngier
2022-07-01 13:48 ` Marc Zyngier
2022-07-01 14:22 ` Schspa Shi
2022-07-01 14:22 ` Schspa Shi
2022-07-01 14:22 ` Schspa Shi
2022-07-06 7:11 ` Marc Zyngier
2022-07-06 7:11 ` Marc Zyngier
2022-07-06 7:11 ` Marc Zyngier
2022-07-06 11:29 ` Schspa Shi [this message]
2022-07-06 11:29 ` Schspa Shi
2022-07-06 11:29 ` Schspa Shi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m25ykawk7f.fsf@gmail.com \
--to=schspa@gmail.com \
--cc=catalin.marinas@arm.com \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.