On Mon, Mar 13, 2023 at 10:45:45PM -0700, Dave Hansen <dave.hansen@xxxxxxxxx> wrote: > On 3/13/23 21:02, Isaku Yamahata wrote: > >> Then it is a hidden behaviour of the TDX module that is not reflected in the > >> spec. I am not sure whether we should handle because: > >> > >> 1) This is an extremely rare case. Kernel would be basically under attack if > >> such error happened. In the current series we don't handle such case in > >> KEY.CONFIG either but just leave a comment (see patch 13). > >> > >> 2) Not sure whether this will be changed in the future. > >> > >> So I think we should keep as is. > > TDX 1.5 spec introduced TDX_RND_NO_ENTROPY status code. For TDX 1.0, let's > > postpone it to TDX 1.5 activity. > > What the heck does this mean? > > I don't remember seeing any code here that checks for "TDX 1.0" or "TDX > 1.5". That means that this code needs to work with _any_ TDX version. > > Are features being added to new versions that break code written for old > versions? No new feature, but new error code. TDX_RND_NO_ENTROPY, lack of entropy. For TDX 1.0, some APIs return TDX_SYS_BUSY. It can be contention(lock failure) or the lack of entropy. The caller can't distinguish them. For TDX 1.5, they return TDX_RND_NO_ENTROPY instead of TDX_SYS_BUSY in the case of rdrand/rdseed failure. Because both TDX_SYS_BUSY and TDX_RND_NO_ENTROPY are recoverable error (bit 63 error=1, bit 62 non_recoverable=0), the caller can check error bit and non_recoverable bit for retry. -- Isaku Yamahata <isaku.yamahata@xxxxxxxxx>
