Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[csrng] Return error status response for GEN commands with glen = 0 #23846

Open
vogelpi opened this issue Jun 28, 2024 · 0 comments
Open

[csrng] Return error status response for GEN commands with glen = 0 #23846

vogelpi opened this issue Jun 28, 2024 · 0 comments
Labels
Component:RTL Type:Enhancement Feature requests, enhancements Type:FutureRelease Not relevant to currently planned releases/milestones
Milestone

Comments

@vogelpi
Copy link
Contributor

vogelpi commented Jun 28, 2024

Description

When taking care of #18350, I found out that CSRNG treats Generate commands with a glen = 0 similarly to commands with a glen = 1, i.e., it generates one single 128-bit block of random data instead of nothing.

I don't think this is a bug really because the CSRNG documentation specifies:

Generate Length: Only defined for the generate command, this field is the total number of cryptographic entropy blocks requested. Each unit represents 128 bits of entropy returned. This field allows values between 1 and 4095. A value of 1 returns 1 * 128 bits of entropy. A value of 4095 returns 4095 * 128 bits of entropy, which is less than the 219 bits allowed by NIST (referenced to as max_number_of_bit_per_request).

and further:

The glen field defines how many 128-bit words are to be returned to the application interface. The glen field needs to be a minimum value of one.

In terms of the NIST spec, we are a bit in a gray area here. NIST SP 800-90Ar1 says
Screenshot from 2024-06-28 15-32-01

What the returned_bits actually is if requested_number_of_bits = 0 isn't clear.

Right now, CSRNG produces one 128-bit block and also the following CTR_DRBG_Update is done and the reseed counter is incremented. I think this behavior is not intended from an RTL perspective. When receiving the Generate command in the command stage, there is just a check for glen = 1:

SendSOP: begin
cmd_gen_1st_req = 1'b1;
cmd_arb_sop_o = 1'b1;
cmd_fifo_pop = 1'b1;
if (sfifo_cmd_rdata[12+:GenBitsCntrWidth] == GenBitsCntrWidth'(1)) begin
cmd_gen_cnt_last = 1'b1;
end
if (cmd_len == '0) begin
cmd_arb_eop_o = 1'b1;
state_d = GenCmdChk;
end else begin
state_d = SendMOP;
end
end

And then also the u_prim_count_cmd_gen_cntr output is compared against 1 again. But there is no check against 0. I think the current behavior is a coincidence.

Now that we have the capability to signal error status responses, it would probably be better to change the design to return an error response when receiving a Generate command with glen = 0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Component:RTL Type:Enhancement Feature requests, enhancements Type:FutureRelease Not relevant to currently planned releases/milestones
Projects
None yet
Development

No branches or pull requests

1 participant