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: Fri, 01 Jul 2022 22:22:51 +0800 [thread overview]
Message-ID: <m2h740zz1i.fsf@gmail.com> (raw)
In-Reply-To: <87letd0wqm.wl-maz@kernel.org>
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.
--
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: Fri, 01 Jul 2022 22:22:51 +0800 [thread overview]
Message-ID: <m2h740zz1i.fsf@gmail.com> (raw)
In-Reply-To: <87letd0wqm.wl-maz@kernel.org>
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.
--
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: Fri, 01 Jul 2022 22:22:51 +0800 [thread overview]
Message-ID: <m2h740zz1i.fsf@gmail.com> (raw)
In-Reply-To: <87letd0wqm.wl-maz@kernel.org>
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.
--
BRs
Schspa Shi
next prev parent reply other threads:[~2022-07-06 7:21 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 [this message]
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
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=m2h740zz1i.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.