On 6/9/26 1:42 PM, Jared Rossi wrote: > > > On 6/9/26 11:28 AM, Zhuoying Cai wrote: >> [...] > >> vce_max_size = sizeof(VCEntryHeader) + >> ROUND_UP(CERT_KEY_ID_LEN, 4) + >> ROUND_UP(CERT_HASH_LEN, 4) + >> ROUND_UP(cert->der_size, 4); >> >> After thinking about this, I’m not entirely sure, but I think using the >> calculated vce_max_size might be a better choice than MAX_ENTRY_SIZE, >> since vce_max_size more closely reflects the size of the current VCE. >> >> MAX_ENTRY_SIZE is currently defined as 8192, which is significantly >> larger than the size of a single VCB that will be requested in a later >> patch. > > I agree that it does make more sense to use the calculated size here, but > do we actually know 8192 is significantly larger than what we will need? > If so that seems like a problem with our definition of the max size. > > Can we use a smaller value, or is it possible that the calculated > vce_max_size is close to 8k anyway? >
I'm not entirely sure, but I think it’s uncommon for a self-generated certificate to reach such a large size, though it is not impossible. >From my experience, the largest certificate I’ve generated used an RSA 16384-bit key and was 5982 bytes. Typically, certificates range from about 1 KB to 4 KB in size. For reference, RHEL 10.2 signs components using the Red Hat Secure Boot 302 certificate from https://access.redhat.com/security/team/key, which has a size of 4429 bytes. >> Although we check whether the remaining space is sufficient to >> store the VCE, allocating MAX_ENTRY_SIZE for each VCE might be unnecessary? >> >> Just wondering if this makes sense, or if you think we should keep using >> MAX_ENTRY_SIZE here? > In this context, yes, it would be better to use the calculated size, but > also if you feel that the current definition of MAX_ENTRY_SIZE will be > significantly larger than we need, should we reconsider what we define > MAX_ENTRY_SIZE as? We could reduce the limit to something like 6144 (6 * 1024) or 7168 (7 * 1024) to better align with the certificate sizes we are likely to use during verification, or keep it at 8192 (8 * 1024) to provide additional buffer for less common cases. Please let me know what you think. >> [...] > > Regards, > Jared Rossi
