From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.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 0292839F17D for ; Wed, 25 Mar 2026 11:27:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.168.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774438078; cv=none; b=V8EoDlkCRf6bQ7hJVqk1ABpii9pNNb/7O8JJdGIV33ly9sjo7CAxrXMzlIKNIGDuJcyV1+3D8yhlZFw0IIQIMfhbrPzqOEh6ZjLZHwe5lSLbY2WkisM2wh5yt320wrLHNwV2YTDApocVTBkVBxMARicPkNili8EuL2poYgFGPRI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774438078; c=relaxed/simple; bh=DnZaBhzGFxXnqOxSGlpPY7ahaCmpo1GkrOsB1cg5jsY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=oqfrghhxiR5jiSYGjp7xwkkNgu41+CuvjoyGDe/tELKRZ955llb9ql19dgFln73tvZwAWB4h+uSAtQjw+b+C3C6sfw07y8aoYwbRqJw6mk+DRi6CnR1msmRxdXuQF5rjyfV1MCvjPuNbFJKcWitYcJPM5/UnvNxxqBWwbjrGEHY= 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=mHIzDNE5; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=Hd32+sBu; arc=none smtp.client-ip=205.220.168.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="mHIzDNE5"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="Hd32+sBu" Received: from pps.filterd (m0279865.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 62PBFwgf720346 for ; Wed, 25 Mar 2026 11:27:56 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= gtphB0uT9yTG03QQZ4jwiVHKGdOTvs/YlaGJ19taHGs=; b=mHIzDNE5eoJlrJRE u3e1uqdKhUk3bBlKwkcGkrN7geKqnPqdjmAaUmKtfLqn3NZsVus89mJV5ISxRkUM 9MP3CFsB2hj2WWJKxQGHZyG8F/K+WmaGOeJXL/2KPsL92VhL2WmaSU22avjPsSxS ReGkHM6JkoQhHoXN1MCY/s0bDlG8O4MFo3RwEvJ9uJu1e5WxQSoe9QZgA6UvNiZU NFAW7Krv0LZPOXRdBJrA6CC1kWJUCa7bO+yVGJjEoWJAGtYELsHDiOvPA1ybuQ+g QwNGK9BYc6dspTG8pf3NUCDMk5DC13U3VuYsTvYw3PcUfhzybm7Rrala3/67L1PI +PsydA== Received: from mail-dy1-f199.google.com (mail-dy1-f199.google.com [74.125.82.199]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4d4dm2r9su-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Wed, 25 Mar 2026 11:27:56 +0000 (GMT) Received: by mail-dy1-f199.google.com with SMTP id 5a478bee46e88-2bdf75bc88fso1993616eec.0 for ; Wed, 25 Mar 2026 04:27:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1774438076; x=1775042876; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=gtphB0uT9yTG03QQZ4jwiVHKGdOTvs/YlaGJ19taHGs=; b=Hd32+sBujhJsiAIf30UnAHPacJexlCzzJnVmZ+Z7t0aOcg5Cdl0vC4cJgUJ1CNSoVq 61S1ylcnq14OLtOLyrIDdoup3u+wPGg0I6G09uES9PGvi1SMOkzUEz7oft0zS0J7KUVb OjKyohruNxrwJjeAOJ6aHDVKagtIsPwjPpKls4Os7/KGnBpFl7hta076AVMCd19cFxwp 50m/Of2+sguMq+0wJlgOYaQ9fOc9D9NgoJGN9crLq2/tlhAXQ0euG0W6LIn/o/rq7fvt fu38u+8/kWhAHxcaPeK4KQfwXtvJjSm1FUYWWgLDreGhVlXACAHfej0oejNQIlylPF1/ vt+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774438076; x=1775042876; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=gtphB0uT9yTG03QQZ4jwiVHKGdOTvs/YlaGJ19taHGs=; b=W/ncwhrrC9oJVHBAVn911ndxxA5BTK2WxL35DFjk7+jOTyzYP8DYItIeREn1BadTHK GJadCqcpqCJ+TJ6qs2kzF8Ps3xyIIghn5JEfPT40WhknCYSgW1b84aJyBmZhUIeZablz ka4QqSk2uTNvpcdIYQ0KcuMfJZ9hcOZvXOVL2t/4qTkXtlKkwJ2q5c28kjkQ2orcpW2j zkHlBvDxyg9UJT5Fe+Sefe1qO1EbSYtk/GkqCqn0cTfTfhSdgbCb3ZD2W76Ct+2/jpEL TgxSMb42nCoeYxv4v08Rcpts6Q+5giEPwO/GwesHCo+Y3IqvYdy96u01VflQWBMR6RrA V74A== X-Gm-Message-State: AOJu0YxcP+TCvYBylA/DsvYCjwAJXX8/UX1IkVZzSa1p9qT1LMf36OVv +QP8Ptt+j5pstzgrPecNNHH5K5bDi3BeTh2b/kbkk0I+18XuZxiccKwX9gTsnWQemUY+2H6jMO6 xPTfUGbrGKHkojfjTkwo6WC4XYLds781nBYFUSOYJD6HkSYMqtQAm/niD68d6jJ9g37Y= X-Gm-Gg: ATEYQzzk3Kn7qxSR82AH7xQ8W9y30I2Ag5Y5oc06I+BHKBMEG+lZnxaqS+Rh83m8Fki 5c1tOvhX2nQgKie0nkSrgll6QGh4yf2IAH6TsW6mGM5sDZ2y/W9+sK+Jt34+Uq/mmx+P5tOMvTq F9n5HCFeFzTFDTkGmamCGYF16b+xk4ZCtEY6OE3Au5XBaw+RZ/F9E9771nvT/t2DTnjeejyWgCA vGUVnKzJa4NLPx8Z3BTLCZRwx+rsf4px4ZqTmx+/K9sTGGceJ+TI+rAHUci4EZZBJLF2g6+cK6N PiZhtzhzJsCgpSbS7du/w7QLOgn5uBHaZudbyPCq8tSCIVXyFG7CoEQgouY8BfgfEDeZr3mh0mI JoV6A9Srh+HM/isRHocCCRJwAsCZXpgp2bOiCf5qo56Ihq1FokSKOOMTTdSV5P9fZ0NiE9Shj8Q UzlrU= X-Received: by 2002:a05:7300:dc05:b0:2c0:f424:b545 with SMTP id 5a478bee46e88-2c15d350374mr1758191eec.15.1774438075460; Wed, 25 Mar 2026 04:27:55 -0700 (PDT) X-Received: by 2002:a05:7300:dc05:b0:2c0:f424:b545 with SMTP id 5a478bee46e88-2c15d350374mr1758162eec.15.1774438074661; Wed, 25 Mar 2026 04:27:54 -0700 (PDT) Received: from [10.110.19.183] (i-global254.qualcomm.com. [199.106.103.254]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-2c10b14caf3sm24298598eec.5.2026.03.25.04.27.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 25 Mar 2026 04:27:54 -0700 (PDT) Message-ID: <8bd50656-6b6d-41d3-8093-c97dd1bb3e91@oss.qualcomm.com> Date: Wed, 25 Mar 2026 19:27:49 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 2/3] dm-inlinecrypt: add target for inline block device encryption To: Milan Broz , linux-block@vger.kernel.org, ebiggers@kernel.org Cc: linux-kernel@vger.kernel.org, adrianvovk@gmail.com, dm-devel@lists.linux.dev, quic_mdalam@quicinc.com, israelr@nvidia.com, mpatocka@redhat.com References: <20260304121729.1532469-1-linlin.zhang@oss.qualcomm.com> <20260304121729.1532469-3-linlin.zhang@oss.qualcomm.com> <682506ea-c9c2-458b-8123-8d78fc53cc7f@gmail.com> Content-Language: en-US From: Linlin Zhang In-Reply-To: <682506ea-c9c2-458b-8123-8d78fc53cc7f@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMzI1MDA4MSBTYWx0ZWRfX/u9wpRdmpPwd xNZQz2YlNLSZ8t3H97iAmp6L5OWToKVvuoghZcMbslCkTcpfjMw0PakGQzrcsYeZOLEO5+W7KZw pAcJATLJT5kSZE5fgxOJNAEpInJDWGRzjpVWgXC2OLlVu56reJqOxgzXregteko0FmBZYXSxKVu u1KfaTpWbgyNM4+qG65pCaZlojN9x0ynavMJwqN+bP9cpwP2dgiyWn46FvoEAC8KTNyAvlG14Tg 3f7EwbGcz7CL6dnEiUkgnYL6BOxA0cPqZJTtP1LvikdbbzGCtMjqFm2xnvag9q29BrjGx/V1Olw he8KDVUpsV9nhb1izUvTm7S9UOFOW01T2oZtn/a+Jox7FM09VeWbHSjqgKrvUD7pFXs9hYHWMSf YyQccDapCWUICDqYCvfDJQ34/eRNDcY4+6E2N0KTO8pzxetul646g4/c6cSn2o/8oD7GHF/rOa6 ff8arR0CZn59f6kjcSg== X-Proofpoint-GUID: 0L75d1o-SY0PEmok3GSHZp3SzEEJZhjo X-Authority-Analysis: v=2.4 cv=Fo0IPmrq c=1 sm=1 tr=0 ts=69c3c6bc cx=c_pps a=cFYjgdjTJScbgFmBucgdfQ==:117 a=JYp8KDb2vCoCEuGobkYCKw==:17 a=IkcTkHD0fZMA:10 a=Yq5XynenixoA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=Um2Pa8k9VHT-vaBCBUpS:22 a=Oh2cFVv5AAAA:8 a=1XWaLZrsAAAA:8 a=EUspDBNiAAAA:8 a=F5rjXf0sUYbAb7_yClkA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=scEy_gLbYbu1JhEsrz4S:22 a=7KeoIwV6GZqOttXkcoxL:22 X-Proofpoint-ORIG-GUID: 0L75d1o-SY0PEmok3GSHZp3SzEEJZhjo X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-03-25_03,2026-03-24_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 adultscore=0 malwarescore=0 clxscore=1015 spamscore=0 bulkscore=0 phishscore=0 priorityscore=1501 suspectscore=0 impostorscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2603050001 definitions=main-2603250081 On 3/4/2026 9:11 PM, Milan Broz wrote: > Hi, > > just few comments below, but I am not DM maintainer so feel free to ignore it :) > > On 3/4/26 1:17 PM, Linlin Zhang wrote: >> From: Eric Biggers >> >> Add a new device-mapper target "dm-inlinecrypt" that is similar to >> dm-crypt but uses the blk-crypto API instead of the regular crypto API. >> This allows it to take advantage of inline encryption hardware such as >> that commonly built into UFS host controllers. >> >> The table syntax matches dm-crypt's, but for now only a stripped-down >> set of parameters is supported.  For example, for now AES-256-XTS is the >> only supported cipher. >> >> dm-inlinecrypt is based on Android's dm-default-key with the >> controversial passthrough support removed.  Note that due to the removal >> of passthrough support, use of dm-inlinecrypt in combination with >> fscrypt causes double encryption of file contents (similar to dm-crypt + >> fscrypt), with the fscrypt layer not being able to use the inline >> encryption hardware.  This makes dm-inlinecrypt unusable on systems such >> as Android that use fscrypt and where a more optimized approach is >> needed.  It is however suitable as a replacement for dm-crypt. >> >> Signed-off-by: Eric Biggers >> Signed-off-by: Linlin Zhang >> --- >>   drivers/md/Kconfig          |  10 + >>   drivers/md/Makefile         |   1 + >>   drivers/md/dm-inlinecrypt.c | 416 ++++++++++++++++++++++++++++++++++++ > > I think it should also add doc in > Documentation/admin-guide/device-mapper/dm-inlinecrypt.rst Thanks for your review. You're right. I'll add it in next patch. > ... > >> +#define DM_MSG_PREFIX    "inlinecrypt" >> + >> +static const struct dm_inlinecrypt_cipher { >> +    const char *name; >> +    enum blk_crypto_mode_num mode_num; >> +    int key_size; >> +} dm_inlinecrypt_ciphers[] = { >> +    { >> +        .name = "aes-xts-plain64", >> +        .mode_num = BLK_ENCRYPTION_MODE_AES_256_XTS, >> +        .key_size = 64, > > Hm. I can understand some translation table for this stupid > dm-crypt notation to inline enum, but why you need key size here? > > Shouldn't there be some helper for inline crypt returning > keysize based on BLK_ENCRYPTION_MODE_AES_256_XTS? Similar to dm-default-key in Android (https://android.googlesource.com/kernel/common/+/android-mainline/drivers/md/dm-default-key.c), key_size 64 here is always corresponding to a raw key. For a HW wrapped key, the key size differs from different manufacturers. Linux kernel only constraints that the max key size of HW wrapped key isn't larger than BLK_CRYPTO_MAX_HW_WRAPPED_KEY_SIZE(128). So we get the actual key size based on the input key parameter received in ctr functions. > > I guess you have fixed cipher list already, but what about IV? > Is it always little-endian, or someone already reinvented plain64be (big-endian)? > > ...> +    while (opt_params--) { > > ...> +/* Same to dm-crypt, 'plain64' in "aes-xts-plain64" of cipher name is the IV mode. It uses the 64‑bit little‑endian sector number as the IV. >> + * Construct an inlinecrypt mapping: >> + * > > As above, it supports opt params, it should mention it here (or in doc). ACK, refer to dm-crypt, I'll add it in doc. > > > ... >> +    /* */ >> +    if (strlen(argv[1]) != 2 * cipher->key_size) { >> +        ti->error = "Incorrect key size for cipher"; >> +        err = -EINVAL; >> +        goto bad; >> +    } >> +    if (hex2bin(raw_key, argv[1], cipher->key_size) != 0) { >> +        ti->error = "Malformed key string"; >> +        err = -EINVAL; >> +        goto bad; >> +    } > > > Any reason it does not support keyring keys from the beginning? No special reason. The implementation of `dm-inlinecrypt` was modeled after 'dm-default-key', which, in Android, does not support keyring keys. I'll have a insight about keyring and dm-crypt, inspect how to add keyring support in dm-inline-crypt. > > ... >> +static int inlinecrypt_map(struct dm_target *ti, struct bio *bio) > >> +    /* Map the bio's sector to the underlying device. (512-byte sectors) */ >> +    sector_in_target = dm_target_offset(ti, bio->bi_iter.bi_sector); >> +    bio->bi_iter.bi_sector = ctx->start + sector_in_target; >> +    /* >> +     * If the bio doesn't have any data (e.g. if it's a DISCARD request), >> +     * there's nothing more to do. >> +     */ > > dmcrypt uses bio_set_dev() for REQ_PREFLUSH or REQ_OP_DISCARD, why this differs? bio_has_data() is a payload‑based check that decides whether an encryption context is needed, while REQ_PREFLUSH and REQ_OP_DISCARD are semantic checks that ensure flush and discard requests bypass the dm‑crypt processing pipeline to maintain correct I/O ordering. As a result, the two mechanisms address different concerns and are not interchangeable. In addition, bio_has_data is called in the beginning of inlinecrypt_map, rather in the conditional branch like dm-crypt. But they have same effect. > >> + >> +    switch (type) { >> +    case STATUSTYPE_INFO: >> +    case STATUSTYPE_IMA: >> +        result[0] = '\0'; > > This should really emit audit information similar to dm-crypt. > >> +        break; >> + >> +    case STATUSTYPE_TABLE: >> +        /* >> +         * Warning: like dm-crypt, dm-inlinecrypt includes the key in >> +         * the returned table.  Userspace is responsible for redacting >> +         * the key when needed. > > Again, why not support keyring format? LUKS2 uses it by default for dm-crypt table. ACK. Need support keyring format. I see both hex key and keyring-based keys are supported in dm-crypt. can both of them be supported in dm-inlinecrypt? > > Milan >