On 1/14/26 18:06, Farhan Ali wrote:
> On 1/14/2026 1:54 PM, Zhuoying Cai wrote:
>> On 1/8/26 5:54 PM, Farhan Ali wrote:
>>> <..snip...>
>>>
>>> On 12/8/2025 1:32 PM, Zhuoying Cai wrote:
>>>> +static int build_vce_data(VCEntry *vce, S390IPLCertificate cert)
>>>> +{
>>>> + uint16_t keyid_field_len;
>>>> + uint16_t hash_field_len;
>>>> + uint32_t cert_field_len;
>>>> + uint32_t vce_len;
>>>> + int rc;
>>>> +
>>>> + handle_key_id(vce, cert);
>>>> + /* vce key id field length - can be 0 if failed to retrieve */
>>>> + keyid_field_len = ROUND_UP(be16_to_cpu(vce->keyid_len), 4);
>>> If we fail to retrieve the key, does it makes sense to build the VCE? I
>>> think we need the key to verify the signature of the certificate, so why
>>> not mark the certificate as invalid?
>>>
>>>
>> The key ID is used to identify the public key in the certificate, but
>> it is not utilized in the current patch series. Therefore, I thought it
>> would be acceptable to continue building the VCE without this field,
>> though I am open to other ideas or suggestions on how to handle it.
With respect to the VCE, since the key_id is used in neither the secure
IPL process nor the kernel, perhaps remove it from the data structure.
I don't see a reason to waste precious BIOS memory holding onto it
otherwise.
> I looked at the kernel code again and it doesn't look like the kernel
> uses the key information today(arch/s390/kernel/cert_store.c). So maybe
> its fine to continue building the vce today. But IMHO it's a little odd
> that we are marking a certificate as valid even though we have an
> invalid key field.
I agree with Farhan. It's still important to sanity check as much of
the certificate as possible to ensure its validity before continuing.
The better approach is to handle any errors that arise with the key_id
parsing.
--
Regards,
Collin
