From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 6B2A4D0D79C for ; Fri, 11 Oct 2024 14:24:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=i5kHVVgPI1KBfHsq0IgsVaLkRXgEXv251bPZZxsFxAg=; b=U8qBWuyNCKHaTFQNFDBtA9bDMw B94mAIbOCzBPOYCc9KV0K2Pre1LMaZJfjERstYv+hPJdcEQxFzFSlRP5w8IASYg6t4fzIUB7oebss REy6MC8l55rOxTBSlHltwOeWA+OCcHFJxerpzBmK9yA0NpOPkXRLXiRWCOYluYjiBac23cJI30ZeI UMF3oxhvrdklc+bRU7nnLSfP/hqd8MPQuFxHpEoLB3qNhfthnimgTxl1W6Xpqu7V7wtUOaw6DulfO qRSX2WJNcHp6Jhz720T2tYhNdht5PoWi6uPMTvr3Ja0QnDfRiPPkHPb96FnO6QSLoCzz93GNYsOUF 6LtSYY/w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1szGZU-0000000Gb3y-0IYE; Fri, 11 Oct 2024 14:24:48 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1szGPY-0000000GYzn-1PUq for linux-arm-kernel@lists.infradead.org; Fri, 11 Oct 2024 14:14:34 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 01F7E497; Fri, 11 Oct 2024 07:14:58 -0700 (PDT) Received: from [10.1.31.21] (e122027.cambridge.arm.com [10.1.31.21]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 608673F5A1; Fri, 11 Oct 2024 07:14:25 -0700 (PDT) Message-ID: <77030ef8-e180-46bb-872c-e41c8b25bbc2@arm.com> Date: Fri, 11 Oct 2024 15:14:24 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 01/11] arm64: rsi: Add RSI definitions To: Gavin Shan , kvm@vger.kernel.org, kvmarm@lists.linux.dev Cc: Suzuki K Poulose , Catalin Marinas , Marc Zyngier , Will Deacon , James Morse , Oliver Upton , Zenghui Yu , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Joey Gouly , Alexandru Elisei , Christoffer Dall , Fuad Tabba , linux-coco@lists.linux.dev, Ganapatrao Kulkarni , Shanker Donthineni , Alper Gun , "Aneesh Kumar K . V" , Gavin Shan References: <20241004144307.66199-1-steven.price@arm.com> <20241004144307.66199-2-steven.price@arm.com> <2ed92455-b97f-40ba-b5d6-695e885be62f@redhat.com> From: Steven Price Content-Language: en-GB In-Reply-To: <2ed92455-b97f-40ba-b5d6-695e885be62f@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20241011_071432_518303_6AF8FF6E X-CRM114-Status: GOOD ( 20.43 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 08/10/2024 00:08, Gavin Shan wrote: > On 10/5/24 12:42 AM, Steven Price wrote: >> From: Suzuki K Poulose >> >> The RMM (Realm Management Monitor) provides functionality that can be >> accessed by a realm guest through SMC (Realm Services Interface) calls. >> >> The SMC definitions are based on DEN0137[1] version 1.0-rel0. >> >> [1] https://developer.arm.com/documentation/den0137/1-0rel0/ >> >> Signed-off-by: Suzuki K Poulose >> Acked-by: Catalin Marinas >> Reviewed-by: Gavin Shan >> Signed-off-by: Steven Price >> --- > > [...] > >> + >> +static inline unsigned long rsi_set_addr_range_state(phys_addr_t start, >> +                             phys_addr_t end, >> +                             enum ripas state, >> +                             unsigned long flags, >> +                             phys_addr_t *top) >> +{ >> +    struct arm_smccc_res res; >> + >> +    arm_smccc_smc(SMC_RSI_IPA_STATE_SET, start, end, state, >> +              flags, 0, 0, 0, &res); >> + >> +    if (top) >> +        *top = res.a1; >> + >> +    if (res.a2 != RSI_ACCEPT) >> +        return -EPERM; >> + >> +    return res.a0; >> +} >> + > > Similar to rsi_attestation_token_init(), the return value type needs to > be 'long' > since '-EPERM' can be returned from the function. Good spot. >> +/** >> + * rsi_attestation_token_init - Initialise the operation to retrieve an >> + * attestation token. >> + * >> + * @challenge:    The challenge data to be used in the attestation token >> + *        generation. >> + * @size:    Size of the challenge data in bytes. >> + * >> + * Initialises the attestation token generation and returns an upper >> bound >> + * on the attestation token size that can be used to allocate an >> adequate >> + * buffer. The caller is expected to subsequently call >> + * rsi_attestation_token_continue() to retrieve the attestation token >> data on >> + * the same CPU. >> + * >> + * Returns: >> + *  On success, returns the upper limit of the attestation report size. >> + *  Otherwise, -EINVAL >> + */ >> +static inline long >> +rsi_attestation_token_init(const u8 *challenge, unsigned long size) >> +{ >> +    struct arm_smccc_1_2_regs regs = { 0 }; >> + >> +    /* The challenge must be at least 32bytes and at most 64bytes */ >> +    if (!challenge || size < 32 || size > 64) >> +        return -EINVAL; >> + >> +    regs.a0 = SMC_RSI_ATTESTATION_TOKEN_INIT; >> +    memcpy(®s.a1, challenge, size); >> +    arm_smccc_1_2_smc(®s, ®s); >> + >> +    if (regs.a0 == RSI_SUCCESS) >> +        return regs.a1; >> + >> +    return -EINVAL; >> +} >> + >> +/** >> + * rsi_attestation_token_continue - Continue the operation to >> retrieve an >> + * attestation token. >> + * >> + * @granule: {I}PA of the Granule to which the token will be written. >> + * @offset:  Offset within Granule to start of buffer in bytes. >> + * @size:    The size of the buffer. >> + * @len:     The number of bytes written to the buffer. >> + * >> + * Retrieves up to a RSI_GRANULE_SIZE worth of token data per call. >> The caller >> + * is expected to call rsi_attestation_token_init() before calling this >> + * function to retrieve the attestation token. >> + * >> + * Return: >> + * * %RSI_SUCCESS     - Attestation token retrieved successfully. >> + * * %RSI_INCOMPLETE  - Token generation is not complete. >> + * * %RSI_ERROR_INPUT - A parameter was not valid. >> + * * %RSI_ERROR_STATE - Attestation not in progress. >> + */ >> +static inline int rsi_attestation_token_continue(phys_addr_t granule, >> +                         unsigned long offset, >> +                         unsigned long size, >> +                         unsigned long *len) >> +{ >> +    struct arm_smccc_res res; >> + >> +    arm_smccc_1_1_invoke(SMC_RSI_ATTESTATION_TOKEN_CONTINUE, >> +                 granule, offset, size, 0, &res); >> + >> +    if (len) >> +        *len = res.a1; >> +    return res.a0; >> +} >> + > > The return value type of this function needs to be 'unsigned long' even > it's > converted to 'int' in arm_cca_attestation_continue(). In this way, the > wrapper > functions has consistent return value type, which is 'unsigned long' or > 'long'. Ack, seems reasonable. Thanks, Steve