On Thu, Sep 9, 2021 at 10:17 AM Brijesh Singh <brijesh.singh@xxxxxxx> wrote: > > > > On 9/9/21 10:43 AM, Peter Gonda wrote: > ... > > >> > >> Does this address your concern? > > > > So the 'snp_msg_seqno()' call in 'enc_payload' will not increment the > > counter, its only incremented on 'snp_gen_msg_seqno()'? If thats > > correct, that addresses my first concern. > > > > Yes, that is goal. > > >>> > >> > >> So far, the only user for the snp_msg_seqno() is the attestation driver. > >> And the driver is designed to serialize the vmgexit request and thus we > >> should not run into concurrence issue. > > > > That seems a little dangerous as any module new code or out-of-tree > > module could use this function thus revealing this race condition > > right? Could we at least have a comment on these functions > > (snp_msg_seqno and snp_gen_msg_seqno) noting this? > > > > Yes, if the driver is not performing the serialization then we will get > into race condition. > > One way to avoid this requirement is to do all the crypto inside the > snp_issue_guest_request() and eliminate the need to export the > snp_msg_seqno(). > > I will add the comment about it in the function. Actually I forgot that the sequence number is the only component of the AES-GCM IV. Seen in 'enc_payload'. Given the AES-GCM spec requires uniqueness of the IV. I think we should try a little harder than a comment to guarantee we never expose 2 requests encrypted with the same sequence number / IV. It's more than just a DOS against the guest's PSP request ability but also could be a guest security issue, thoughts? https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf (Section 8 page 18) > > thanks
