From patchwork Wed Apr 5 11:57:15 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christian Loehle X-Patchwork-Id: 7748 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp252409vqo; Wed, 5 Apr 2023 05:11:44 -0700 (PDT) X-Google-Smtp-Source: AKy350ZVJI1GTkDh9pVY+Rh9RYI0nL4IvMUvddkVu/2vzKLeoKxKrscXg5QYSXHgOJag3sw5P+5O X-Received: by 2002:a17:906:57c7:b0:8ad:51e9:cd57 with SMTP id u7-20020a17090657c700b008ad51e9cd57mr2564291ejr.49.1680696704747; Wed, 05 Apr 2023 05:11:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680696704; cv=none; d=google.com; s=arc-20160816; b=aZktplf0x+XkY+QCq/hjnt7zx8/qaQvW5lrykCYOOTIz+DguIFGqqGcfc2eaYnlK9a xB5uoCcmfbSGOodctI6s9LOAUaogt5jVkQTagLJT7k5jcE7WpBFosYc10d0EcBefeqjW TxQrbETvGn/9LvqqKVgQGDglJ3Bbn4Zi02wfHHVcChm8PKc92cr8TGMHRlUVRaWX3f46 zDsd5qzQa+oiz3kvIVLXZeC9D1QKVFh+Ne9zovKT4bCG5StDFBLCEyWlRoE1p2DqvuEj A4mBFfBiTO/MzevEhdOSmUMQuW4ABA9FojXHbwlWbw+2fbLNc4bVUcueg9dxWhNKHsPp lzsw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:content-transfer-encoding :content-language:accept-language:message-id:date:thread-index :thread-topic:subject:cc:to:from; bh=3cGlJWjoUx748VLBm5wvAUaTVOUDg2eofp8WTkyBow8=; b=ohH63j4sEE/OZE1RaFMIcFQ0lu3k1hotIXQ5AikxKzBZeExuZzKMj9v50ZcECNqZQx q33cZ3r3G7tgi4EIP4M2/QsZE6o9h1ehq7vIJKZLt1G8khc9GOMokxo0tymzaU3idHUq xbadBLZjsyLtq63ruFz/jvwV/Kvx0D7J4qn+y8prrryurEY78pSIbDzWT8L7b/EYymdb SwVgpNKKTN13UnS/BpEGBef3snyhr+04PkGmAjZya1Mfrm9EdgnQepITbbRnjXN7zYGX /oGkQXGJ8Wq12KfvwNsF06q+XKXGDKbaEmJaRTaTRERePaJ/9d1wqpp5hsZjiufq8x1u UMEw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=hyperstone.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id du3-20020a17090772c300b00947f3f6469esi3100016ejc.874.2023.04.05.05.11.19; Wed, 05 Apr 2023 05:11:44 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=hyperstone.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237803AbjDEL5V convert rfc822-to-8bit (ORCPT + 99 others); Wed, 5 Apr 2023 07:57:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42556 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232985AbjDEL5U (ORCPT ); Wed, 5 Apr 2023 07:57:20 -0400 Received: from mail5.swissbit.com (mail5.swissbit.com [148.251.244.252]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 72DB03C0E; Wed, 5 Apr 2023 04:57:18 -0700 (PDT) Received: from mail5.swissbit.com (localhost [127.0.0.1]) by DDEI (Postfix) with ESMTP id 77FCC3A2A47; Wed, 5 Apr 2023 13:57:16 +0200 (CEST) Received: from mail5.swissbit.com (localhost [127.0.0.1]) by DDEI (Postfix) with ESMTP id 6AFD13A2A3E; Wed, 5 Apr 2023 13:57:16 +0200 (CEST) X-TM-AS-ERS: 10.181.10.102-127.5.254.253 X-TM-AS-SMTP: 1.0 bXgyLmRtei5zd2lzc2JpdC5jb20= Y2xvZWhsZUBoeXBlcnN0b25lLmNvb Q== X-DDEI-TLS-USAGE: Used Received: from mx2.dmz.swissbit.com (mx2.dmz.swissbit.com [10.181.10.102]) by mail5.swissbit.com (Postfix) with ESMTPS; Wed, 5 Apr 2023 13:57:16 +0200 (CEST) From: =?iso-8859-1?q?Christian_L=F6hle?= To: Ulf Hansson , Adrian Hunter , "linux-mmc@vger.kernel.org" , "linux-kernel@vger.kernel.org" CC: Avri Altman Subject: [RFC][PATCH 0/3] mmc: block: ioctl: Enhance userspace err-checking Thread-Topic: [RFC][PATCH 0/3] mmc: block: ioctl: Enhance userspace err-checking Thread-Index: AdlntVwS+89diB7ATPqDW+FoRq4nTA== Date: Wed, 5 Apr 2023 11:57:15 +0000 Message-ID: <20620b972fe448f381c3d585a1ae4730@hyperstone.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0 X-TMASE-Version: DDEI-5.1-9.0.1002-27546.007 X-TMASE-Result: 10--13.709100-10.000000 X-TMASE-MatchedRID: 9M69yBZ2Ml5rFdvBEmTnvNFJ92mNllHuNZEftOVQtYaNJ2ckLRg2UQwb B6fWQkqsTqoWkhFw+fLQyMBx6JGg+jwdmyX2g5Xwyn0GCvk40qG3ClSK/bUMDS196sn93sBvSGk gWW9laDWkV52mAIXFpWWFV9BfSfALYY3ozW+EngeHZXNSWjgdU9UEOicf335W2gjng2FkAcSsto QvCgKRixAhHOhMv3S3hK7o2WR9HX/3LKKZvqYslN9JA2lmQRNUI64EUz6lBajmNEV/m/YJp2Jjg 9GXn3itOelJXrqHws2o+6444pTvToYM3GbKHhDEtPYfgFJ3kY/UoMiU4Mi75bt/YafNBu9cBBYt pm0LkTaEkt/L8HtAJ29yZj3aufb5aDAi8sBNMoELbigRnpKlKSPzRlrdFGDwSxtfyX5OOjJxtiO pYBUzOaXBlbe9D52tjo/Zlyf+Px1t6nh0ne7HIQ== X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0 X-TMASE-INERTIA: 0-0;;;; X-TMASE-XGENCLOUD: 0a493fbb-c613-4b78-9116-e512e20b84da-0-0-200-0 X-Spam-Status: No, score=0.0 required=5.0 tests=SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1762338228144889368?= X-GMAIL-MSGID: =?utf-8?q?1762338228144889368?= This series enhances the ioctl path so that userspace callers are able to reliably check all error bits for their operation. The current implementation poses the problem of error bits which the caller cannot check, this is potentially a security issue. If the phrase security issue has woken you up, but you haven't been using: mmc-utils sanitize mmc-utils erase secure-trim{1|2} mmc-utils secure-erase mmc-utils rpmb write-block you can go back to sleep, sorry to bother you. If you have, you are probably still fine, if there was no active attacker sabotaging your eMMC, the secure operation probably succeeded. There is just no way to confirm that it actually has. Examples include e.g. a flash-fail of the eMMC. Card behavior differs here, R1 bit 19 could be set, many cards will just shut off on flash-fail, so if you want to play with this patch I would suggest aiming for WP_ERASE_SKIP, although that technically doesn't need the patch, as WP groups could be queried before and after erase. sudo ./mmc writeprotect user set temp 0x0 $(($(blockdev --getsz /dev/mmcblk2))) /dev/mmcblk2 sudo ./mmc erase secure-erase 0 $(($(blockdev --getsz /dev/mmcblk2)-1)) /dev/mmcblk2 will yield Executing Secure Erase from 0x00000000 to 0x0773ffff High Capacity Erase Unit Size=524288 bytes High Capacity Erase Timeout=600 ms High Capacity Write Protect Group Size=2097152 bytes RSP0: 0x00000800 # added by author, this is what the patch will add RSP1: 0x00008f40 # added by author, this is what the patch will add Secure Erase Succeed! even though no erase is issued. Why is it RFC? setting BIT(31) of write_flag is of course hacky, would like your comments on that. The post-PROG errors are only relevant for either writes or SWITCH and ERASE, so operations without data, it can safely be abused. Similarly saving the errors in response[1] is also a bit hacky, I personally like it a bit better for the userspace caller to be able to distinguish immediate errors and X errors. Just putting everything in response[0] would of course work, too. 1/3 and 2/3 are fine from my end. Christian Loehle (3): mmc: block: ioctl: define rpmb reliable flag mmc: block: ioctl: do write error check for spi mmc: block: ioctl: Add error aggregation flag drivers/mmc/core/block.c | 48 ++++++++++++++++++++++++++++++---- include/uapi/linux/mmc/ioctl.h | 3 +++ 2 files changed, 46 insertions(+), 5 deletions(-)