From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ot1-f43.google.com (mail-ot1-f43.google.com [209.85.210.43]) by mx.groups.io with SMTP id smtpd.web08.1816.1620242876866898995 for ; Wed, 05 May 2021 12:27:57 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@nuviainc-com.20150623.gappssmtp.com header.s=20150623 header.b=u6md03fr; spf=pass (domain: nuviainc.com, ip: 209.85.210.43, mailfrom: rebecca@nuviainc.com) Received: by mail-ot1-f43.google.com with SMTP id q7-20020a9d57870000b02902a5c2bd8c17so2739148oth.5 for ; Wed, 05 May 2021 12:27:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuviainc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=j2feggNbHxg2go5Vpb6pC43BwBbRQpur8fzk/FNyiqM=; b=u6md03fruhSzo/OZpUMFHbq2Kt6fKkzBJ8dh1ph7PG8jaiquZy6ADzVh+eO+Q5BCo4 isEQlFmjwnRrIbKMPzkJmgTXU+Vajd9wP4LvyKd/ZOZlwA0PtJZF7BSyZWx44yLUT8xJ x6H+oiboNs8OLPWPot/AugjRLjdlZC9MpHtO/yvtDfCmiokVQ7qHM2bGEe7CD0W/PmAc H6+uW7DW7alpiH59nJk9LudMVGP0mlsBA0ftR/UM6uB3iyyq6uyS/xyOQtOV/sTpYPbI YjRb6WoXsqcyleZnIA1sjbVOf0eAZFCuOPP/d1k/NMB8j5HAVZqRqgkLkXHVbVE6Bnlz +wEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=j2feggNbHxg2go5Vpb6pC43BwBbRQpur8fzk/FNyiqM=; b=MUuFuYgKO2umJ+m0dOPhhbvJhaDWlyITmvxYOT6MDimhVNWtohMarM0aoRxAP6izw/ 1hDwhYssAOB+3Qcoo/Arm53z0CE2KO66grDQsYVJpAJVNQxnMEOQBnKQB5w+FC9+IFDj aKgojiJpHzpbRaEoIcqtGTD5r4wtJeocfvcChkLFS1oyqBdiM0Z0WMCGiu5FusKKq/vX f1QishhWhGkJ5FxXIbxxSIhqzvbkk5vxrb89m1oFYBsb9ZooivhyeWhpOwy0leTe4ct7 mWGYr4vZ8x9jlMYDZTJ7eEonk7YrYX/K1ulkWoa+C20zFO0Z9+WBOFwn7cmO6sszWt8n u9tA== X-Gm-Message-State: AOAM532h0P4AgDDCjoC4/dcfGuOxr1HuRfuk7AYmnmjYhGISqwbN93iC M16lzAboThClUOFbmFbbE2vNzA== X-Google-Smtp-Source: ABdhPJz4KbGPemUhY1J4At6BsLh0SG1mEdC3HDGSl/PuVJnMrrOzbMs5XRe17o/6fa/HPtuNHOsS1w== X-Received: by 2002:a9d:1ac:: with SMTP id e41mr239876ote.166.1620242876181; Wed, 05 May 2021 12:27:56 -0700 (PDT) Return-Path: Received: from [10.0.10.142] (c-174-52-16-57.hsd1.ut.comcast.net. [174.52.16.57]) by smtp.gmail.com with ESMTPSA id c17sm83259otn.45.2021.05.05.12.27.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 05 May 2021 12:27:55 -0700 (PDT) Subject: Re: [edk2-devel] [PATCH 2/3] MdePkg: Refactor BaseRngLib to support AARCH64 in addition to X86 To: devel@edk2.groups.io, sami.mujawar@arm.com Cc: Jiewen Yao , Jian J Wang , Michael D Kinney , Liming Gao , Zhiguang Liu , Ard Biesheuvel , nd@arm.com References: <20210428204415.25454-1-rebecca@nuviainc.com> <20210428204415.25454-3-rebecca@nuviainc.com> From: "Rebecca Cran" Message-ID: Date: Wed, 5 May 2021 13:27:54 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit On 5/4/21 3:09 PM, Sami Mujawar wrote: >> +EFIAPI >> +BaseRngLibConstructor ( >> + VOID >> + ) >> +{ >> + UINT64 Isar0; >> + // >> + // Determine RNDR support by examining bits 63:60 of the ISAR0 register returned by >> + // MSR. A non-zero value indicates that the processor supports the RNDR instruction. >> + // >> + Isar0 = ArmReadIdIsar0 (); >> + ASSERT ((Isar0 & RNDR_MASK) != 0); >> + (void)Isar0; > [SAMI] ASSERTs will vanish in the release builds. So, I think this needs > to be an if condition. If RNDR is not supported RETURN_UNSUPPORTED > should be returned. > However, it appears thatthe auto generated function > ProcessLibraryConstructorList() disregards the error code returned by > the constructor (see Build\...\AutoGen.c files). So it looks like the > loading operation would continue in release builds despite of an error. > I am not aware if this is the desired behavior or why the status code > returned by the constructor is disregarded. > > However, this would be a probem in the current case as subsequent calls > to generate random numbers will result in an undefined instruction > exception. > To prevent this, I think the above check should be done in either >    - ArmRndr()/ArmRndrrs() >   or >    - preferably in ArchGetRandomNumberXX(), which should return an > error code EFI_UNSUPPORTED, EFI_NOT_READY or EFI_SUCCESS. However, the > impact on IA32/x64 code needs to be evaluated. > > [/SAMI] Yes, I noticed that but the same problem exists for the IA32/x64 code, since it might not support RDRAND/RDSEED. Should I change the BaseRngLib interface to return an EFI_STATUS instead of BOOLEAN? Or would that be too disruptive? -- Rebecca Cran