On Tue, Feb 11, 2025 at 11:31:28AM +0100, Clément Léger wrote:
On 11/02/2025 06:43, Deepak Gupta wrote:
+static int kvm_sbi_fwft_get(struct kvm_vcpu *vcpu, unsigned long
feature,
+ unsigned long *value)
+{
+ int ret;
+ struct kvm_sbi_fwft_config *conf;
+
+ ret = kvm_fwft_get_feature(vcpu, feature, &conf);
+ if (ret)
+ return ret;
+
+ return conf->feature->get(vcpu, conf, value);
+}
+
+static int kvm_sbi_ext_fwft_handler(struct kvm_vcpu *vcpu, struct
kvm_run *run,
+ struct kvm_vcpu_sbi_return *retdata)
+{
+ int ret = 0;
+ struct kvm_cpu_context *cp = &vcpu->arch.guest_context;
+ unsigned long funcid = cp->a6;
+
+ switch (funcid) {
+ case SBI_EXT_FWFT_SET:
+ ret = kvm_sbi_fwft_set(vcpu, cp->a0, cp->a1, cp->a2);
+ break;
+ case SBI_EXT_FWFT_GET:
+ ret = kvm_sbi_fwft_get(vcpu, cp->a0, &retdata->out_val);
+ break;
+ default:
+ ret = SBI_ERR_NOT_SUPPORTED;
+ break;
+ }
+
+ retdata->err_val = ret;
+
+ return 0;
+}
+
+static int kvm_sbi_ext_fwft_init(struct kvm_vcpu *vcpu)
+{
+ struct kvm_sbi_fwft *fwft = vcpu_to_fwft(vcpu);
+ const struct kvm_sbi_fwft_feature *feature;
+ struct kvm_sbi_fwft_config *conf;
+ int i;
+
+ fwft->configs = kcalloc(ARRAY_SIZE(features), sizeof(struct
kvm_sbi_fwft_config),
+ GFP_KERNEL);
nit:
I understand that in next patch you grow the static array`features`. But
in this patch
`ARRAY_SIZE(features)` evaluates to 0, thus kcalloc will be returning a
pointer
to some slab block (IIRC, kcalloc will not return NULL if size
eventually evals to 0)
This probably won't result in some bad stuff. But still there is a
pointer in
fwft->configs which is pointing to some random stuff if `features` turns
out to be
empty.
Let me know if I got that right or missing something.
So I actually searched into the kmalloc code to see what hapopens with a
zero size allocation and it actually return ZERO_SIZE_PTR:
/*
* ZERO_SIZE_PTR will be returned for zero sized kmalloc requests.
*
* Dereferencing ZERO_SIZE_PTR will lead to a distinct access fault.
*
* ZERO_SIZE_PTR can be passed to kfree though in the same way that NULL
can.
* Both make kfree a no-op.
*/
Which seems like it's not really random and will fault if accessed. I
think that's enough for that commit (which will be bisectable if needed
then).
Awesome. Thanks for looking into it.
Clément
