From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 699A6377015 for ; Fri, 28 Aug 2026 15:56:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.180.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787932573; cv=none; b=Ft1Jcj8JUUVkm2faATa8GRkD0WVcMdpY5MFoHjb/QZ893MJJZAH5OEQ8gRsODpsogQkMPzKsXaP3sp/0/Y4MEeG/JsyizoOxYMdznx6tfAhqD+8HvegLJdsj7dZ7Zel8gSXhnYSoOLkZVzU0JVeAcw5l/uCMR554nP5Qd2Aee44= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787932573; c=relaxed/simple; bh=YPFAfwgLXyRYWu0qKDT7O8z9rx4Le0VUAMpakSNW0Is=; h=Message-ID:Date:MIME-Version:Subject:From:To:Cc:References: In-Reply-To:Content-Type; b=qsicOoHkDMVH7C4B0+d2hemGfmoDEmTRk6GCogvYOItKuhWO/M61WD0Kyf5fjXnduqstU28/jVOuNBSZrsfrbRRGNr8ZKtykrJDePjWyjhOZ8uzhkTMcd72w2UHVGJMFdDoqgBY4UsIiG3dhuvYfYqd/H1g+9rzKxWJI+0S+f4s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com; spf=pass smtp.mailfrom=oss.qualcomm.com; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b=DvsjZ2Ls; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=NNEGrZqi; arc=none smtp.client-ip=205.220.180.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b="DvsjZ2Ls"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="NNEGrZqi" Received: from pps.filterd (m0279868.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 67SDl2xd2971030 for ; Fri, 28 Aug 2026 15:56:10 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= QWK2pao1WAM8yI8Fl2//fFtzpUUZCvVVyo5r8hizPUA=; b=DvsjZ2LsVsvmIPjD cj7LSSEwmXlDTK+zsDzSAGaxZlfNi+MtDuMlbE9tq/aGlM4kd991+VMkWZITv1AP ZDtm/5x6tea1dQQp/stuFNciPiC2wsHtjI0W83fbewoGJ5F2d2TP0txv23SXXDUM x5Np1nwAagHAeY94LmjuSfTcCpkOiH9FZp8qji89R/Czmwpz+tI78oBJUFIU2OP1 EBf64brrOr/k+4w5NENc4R1Nk2xv/skup7H0UdrEVW2pUJ7m0KsZkffsK9fvU/52 /NdgLhOuTD28ELOrSvt7RXkv9GjhTKW7Oih9zefr/eASuUxpYJ/q5PdbQfXy24KO /go55w== Received: from mail-pg1-f198.google.com (mail-pg1-f198.google.com [209.85.215.198]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4gb3hs2kuc-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Fri, 28 Aug 2026 15:56:09 +0000 (GMT) Received: by mail-pg1-f198.google.com with SMTP id 41be03b00d2f7-cc1b8088202so1207343a12.3 for ; Fri, 28 Aug 2026 08:56:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1787932569; x=1788537369; darn=lists.linux.dev; h=content-transfer-encoding:content-type:in-reply-to:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to:content-type; bh=QWK2pao1WAM8yI8Fl2//fFtzpUUZCvVVyo5r8hizPUA=; b=NNEGrZqiNLmmryu9x72COsgA6gK1DPD4MBi82oOtv5CAalaujzAmAhOKS3uah6k781 lLSskZpjM+mpJhaex7DaGqMgRsG0xqrEpxm1ma0DyLHc65SI8oagCFaZHb/q5blnO3BF 6O99GePg5LjPvEPx9AS9YwBndzWyTBr8ofcD3TsIVRuvc5XPvYejcSJE7hyxWJSX9BeI MhlJvMhxksCcda3Zlk/wJVG6VHePsfq89s3JXDtrWqaUEC8K4m0mZgomehUgCEU0nD29 HIaAMbM4xQfcyiQf4FVAGW7O2QgiABYu1W6sbVCVZ6MgNVzRqre6APoj0a3A2u4WIwF+ W2WA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787932569; x=1788537369; h=content-transfer-encoding:content-type:in-reply-to:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=QWK2pao1WAM8yI8Fl2//fFtzpUUZCvVVyo5r8hizPUA=; b=AvaV/nXi9c4iXWbCkN9eelk+z6AaCQLqPn5iXBa3jGP1lIg4dtYKZg67w+0X8h654/ Q7bgj6iZeaXjss0P0LUbuAEzNclKaJEULXAJtc/cP5RTQbiqIMhcU8jnweStB0BJtMAH WHytWsbELGy4gHx12Df9hdfAxJsdXmukd3nst/gASyFLAIdFCvROGwlfQrDNmW8SuI1m ZSSD1TVOJRwhmEXFXMDGQ927fPX6a/7U9LL9yFqrxwo2Xn1rweBRjMjdxQpVeh77Mlvm uO5X+CCJv2MrQGUycYCTxUMGmgkwe4W4s+bGtVHNY/OHLeRlHJUxih6H7+2ZE6U/EQvk tLsg== X-Forwarded-Encrypted: i=1; AHgh+RoEcb4sYzo3VrmGkOJ1EIFLq8+HPWCF0DIV9myafK1d/l1ox8K6feLpu6v8Sles00oXWW5KqqZ02IuHzG6Rgw==@lists.linux.dev X-Gm-Message-State: AFuF++kHy6kXhRtQn3yA8MOL7ppBQw0b9kInhZRI/T/BeX2ykWG7cGeE vyDvG/qT0fBUxixlW4AZ7mz+Zm/TuW/3mfzyF/5DBQuiGbnD06KU5odyu/Q0H8aaAUc4rWaTErQ 7CsqVSeRYE898msnWpIsMlY082Xa0S6z5bEpfZs1elFj8JBpzoRXXn9lGpcjZOG1D+aM4rw== X-Gm-Gg: AR+sD12Hl38veKm21yq3VJWDapSf2Ny0kw+VfSPmSsi/j2XVdXkiOF2vxZb+THFPM9V UVygit58XLPluj49v1mR1wmmxJ2Gg9JEq2eyeuL6HPhr03vi//icQXResNV21LGBMhFP4a8Rx/T 8e0ak2wEU58EsUIg3rsw+PL/ctNlHfJbPDYLxQ53UDdBDPVijN9uWbLwQR+BEnMUK2YN8poc3xO 9TKmU1RQyc8NMpJnGrRoJeL7aShjXOr+8FTaVx/pjBhaJ4x4FYj7jt1mjLGoYuoM43dWP03RTo3 xUMN054ajZ0URaUkWniRyDDW7cBcU0Y9oLZr2T0cPA8qkuBdkYEFaMz2+tzHBkQL8U/EhXzchwz 0ycgR9X7nV/5TEu1mlW+5g5vv88UMEWBKzmYlsU4AVwx7OoLGOYy1PdLSf00= X-Received: by 2002:a05:6a20:a11c:b0:3d3:adbf:777f with SMTP id adf61e73a8af0-3d3adbf8124mr1206729637.20.1787932568973; Fri, 28 Aug 2026 08:56:08 -0700 (PDT) X-Received: by 2002:a05:6a20:a11c:b0:3d3:adbf:777f with SMTP id adf61e73a8af0-3d3adbf8124mr1206667637.20.1787932568530; Fri, 28 Aug 2026 08:56:08 -0700 (PDT) Received: from [10.110.102.109] (i-global254.qualcomm.com. [199.106.103.254]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-328713b944bsm6433151eec.27.2026.08.28.08.56.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 Aug 2026 08:56:08 -0700 (PDT) Message-ID: <431215e8-1c80-4aa4-8407-5b3779c344f8@oss.qualcomm.com> Date: Fri, 28 Aug 2026 23:56:00 +0800 Precedence: bulk X-Mailing-List: virtualization@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 00/11] FBE virtualization: inline encryption for virtio-blk guests From: Linlin Zhang To: Eric Biggers Cc: axboe@kernel.dk, mst@redhat.com, jasowangio@gmail.com, James.Bottomley@hansenpartnership.com, martin.petersen@oracle.com, robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org, linux-block@vger.kernel.org, linux-crypto@vger.kernel.org, linux-scsi@vger.kernel.org, virtualization@lists.linux.dev, devicetree@vger.kernel.org, linux-arm-msm@vger.kernel.org, neeraj.soni@oss.qualcomm.com, gaurav.kashyap@oss.qualcomm.com, mani@kernel.org, andersson@kernel.org, konradybcio@kernel.org, bvanassche@acm.org, alim.akhtar@samsung.com, avri.altman@sandisk.com, stefanha@redhat.com, pbonzini@redhat.com, eperezma@redhat.com, xuanzhuo@linux.alibaba.com, linux-kernel@vger.kernel.org References: <20260827160806.1295313-1-linlin.zhang@oss.qualcomm.com> <20260827184219.GB2137493@google.com> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Authority-Analysis: v=2.4 cv=XKYAjwhE c=1 sm=1 tr=0 ts=6a91af9a cx=c_pps a=Qgeoaf8Lrialg5Z894R3/Q==:117 a=JYp8KDb2vCoCEuGobkYCKw==:17 a=IkcTkHD0fZMA:10 a=Sv0fKeRqtYgA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=ZpdpYltYx_vBUK5n70dp:22 a=EUspDBNiAAAA:8 a=_h6NAR8LnRz2utxSRfIA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=x9snwWr2DeNwDh03kgHS:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODI4MDEzOCBTYWx0ZWRfX1g/B09Wu4T3l rdylOlwt1nCWGjgnCuZAWLZV9k8I5MX/JslWL9HQB16798rtWflk9+hv10W5Gbl5KvjokNYBjS+ 1IxmXwEUSoJSyJADNM7dncLj+OiVW1cbyFoZfVS4zEJoSWBMY1M2LiPwyX5h19g+2MC8D7AGbvw oTxT4sVzzO6kopQkIb9PlyPStlAzEGOzjS4GycYWGJ8oryPQRfzWycdk98HxIYazdO5prserUTH ckPiSSUHxZ1e3VTrqcQ21oOWU9ct4hHIMPsbBYHkIL/TFQpdPqfXLpOmGILKFjRhE02enpZLENH n9m6kSADN/9j8MG8uW1PYJHMrLa+IRXhw1u23EjVxT62KWBwZ2CIZoDX2IsIUqIxiZUkZZQlVdD hZllxAHCfocpTsPCvS7yg636YUFgIQkpPBci1KtR+e/qyFVgqux7i1S5qPpnPUULjLG+qcUVr00 qEcgBtNwyaFJrY/VKew== X-Proofpoint-Spam-Info: AW1haW4tMjYwODI4MDEzOCBTYWx0ZWRfX6iJhSGaJBO5t Lt5BYZHMxvHQqYxA/+ublUnP4YBig4j7rnlrmrecj/OGwvE5S3/hrFziHKq19d3b4dCFLC7dOYe XhYwzeWtFMo5XWY75hnoQjdTnNM2n+8= X-Proofpoint-GUID: HwOkRs29iDGwCzUZLsnGc6TOHJZ5H6qq X-Proofpoint-ORIG-GUID: HwOkRs29iDGwCzUZLsnGc6TOHJZ5H6qq X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-08-28_04,2026-08-27_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 lowpriorityscore=0 clxscore=1015 priorityscore=1501 bulkscore=0 adultscore=0 phishscore=0 suspectscore=0 impostorscore=0 spamscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2608280138 On 8/28/2026 11:37 PM, Linlin Zhang wrote: > > > On 8/28/2026 2:42 AM, Eric Biggers wrote: >> On Thu, Aug 27, 2026 at 09:07:09AM -0700, Linlin Zhang wrote: >>> From: linlzhan >>> >>> Current virtio-blk does not provide a mechanism for a guest to >>> program hardware keys or submit encrypted I/O using pre-programmed >>> keyslots. It drops the crypto context when issuing a bio request >>> to the virtio-blk queue, preventing inline-encryption-based FBE >>> on virtio block devices. >>> >>> This series enables File-Based Encryption in guest VMs on Qualcomm >>> GVM platforms where the ICE inline encryption hardware is shared >>> between the host and guests. In this environment the guest kernel >>> has no access to the ICE hardware directly; it supplies a virtual >>> keyslot index and data unit number with each encrypted I/O request >>> via VIRTIO_BLK_F_INLINE_ENCRYPTION, and the host must translate the >>> virtual slot to a physical ICE keyslot and submit the bio — without >>> transferring raw key material across the VM boundary. >> >> This seems to be designed incorrectly by not making virtio-blk itself >> support key programming and eviction. That complicates things >> significantly by then having to handle the key programming and eviction >> out-of-band using Qualcomm-specific SCM calls. It also means that >> adding other implementations of this would be very difficult. >> >> There are some claims that not transmitting keys across the VM boundary >> is desirable. But that doesn't seem meaningful, given that all the I/O >> is transmitted across that boundary in plaintext anyway, and also it >> seems that hardware-wrapped keys will be supported too. >> >> Please make virtio-blk support the key programming, eviction, and >> HW-wrapped key management operations that are needed for this to work. >> >> - Eric > > Thanks for your comments! > > Not making virtio-blk itself support key programming and eviction is > something done deliberately. Based on that HW-wrapped key management > operations are also handled in the out-of-band path. > > There are bellow 2 approaches I investigated to let virtio-blk programming > the key. > > 1. virtio_blk implements blk_crypto_ll_ops interfaces, including program > key and evict key interfaces.(Same to 'the virtio-blk interface standardized > blk_crypto_ll_ops requests' mentioned by Stefan in the virtio SPEC thread) > > The guest's block crypto profile manages the keyslot in virtual slot > format in this scenario. > > - block crypto key and virt_slot index it passed to the hypervisor's > (EL2) device emulation (QEMU, using QEMU in the following) which > runs in userspace of the host. Besides of transferring the virtual > slot to the physical slot, a programming block crypto key UAPI need > be added. Follow current blk-crypto design, it may be like > BLKCRYPTOGENERATEKEY. I thought this results in a security risk that > allows userspace process a key into a key slot. > > - For key eviction, it's similar to above key programming handling, also > need a key eviction in blk IOCTLs, but leads to the security risk > that allow userspace client to evict a key in a key slot. > > virt_slot, DUN and DUSize is appended to virtblk request during crypto > I/O. > > 2. virtio_blk implements blk_crypto_ll_ops interfaces, excluding program > key and evict key interfaces. > > The guest's block crypto profile doesn't manage keyslot for the guest, > the host's block crypto profile manages keyslot for both the guest and > the host. The trigger of key programming operation is moved from the > guest to the host. > > - The whole block crypto key (key size, key bytes, blk_crypto_config) > and DUN are appended to the virtblk request during IO, a little > high payload. > > The backend parses the crypto message in the virtio queue and > construct a block crypto key and DUN for the bio_crypto_ctx > set to the BIO. So that the IO flow in the host can program > the key. > > The question is that the blk-crypto-profile distinguishs the > block crypto key via the key's address. But the host has > different key addresses for the programming and eviction key > operations of the same block crypto key from GVM, because the > key is re-constructed in the host for the key program and > eviction operations. > > To fix it, the approach I thought is maintaining a new key > hash table in the backend, and comparing the block crypto key > content and DUN parsed from virtio queue with that in the key > hash table. > My major concern is that this need keep the keys synchronization > b/w this new hash table and the blk-crypto-profile's hash table > carefully, avoiding that key is still present in the > blk-crypto-profile's hash table, but removed in backend hash > table. Another point is that the whole block crypto key and > DUN are appended into virtio block request per crypto I/O. > > - For key eviction, adding a key eviction in blk IOCTLs allows > userspace client to evict a key in a key slot. I thought this > is a security concern. > Do you have any suggestion about the key eviction operation? Could this key eviction request triggered in QEMU be accepted? Would you please help share insights about how to handle it? Thanks a lot! > > This option doesn't need map virt_slot to physical one. > > > Taking all the above into account, I made a compromise to implement > blk_crypto_ll_ops interfaces in a out-of-band path, which lets the virtio > blk only need focus on the data path. I agree that it is complex than > the second option mentioned in the above, but small payload (only > virt_slot, DUN, DUSize) in the virtio block request and no security > risk of key eviction from userspace. > > > I would like to hear your thoughts about the above and am appreciated > if you could share your insights about the design of inline > encryption in virtio block. > > Regards, > Linlin > > >