From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=vNKV=JH=saout.de=dm-crypt-bounces@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
X-Spam-Level: 
X-Spam-Status: No, score=-2.0 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED,
	DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,
	HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,
	USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
	by smtp.lore.kernel.org (Postfix) with ESMTP id 92615C433B4
	for <dm-crypt@archiver.kernel.org>; Sat, 10 Apr 2021 19:30:26 +0000 (UTC)
Received: from mail.server123.net (mail.server123.net [78.46.64.186])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mail.kernel.org (Postfix) with ESMTPS id 0ABF4610CC
	for <dm-crypt@archiver.kernel.org>; Sat, 10 Apr 2021 19:30:25 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0ABF4610CC
Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com
Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dm-crypt-bounces@saout.de
X-Virus-Scanned: amavisd-new at saout.de
Authentication-Results: mail.server123.net (amavisd-new);
	dkim=pass (2048-bit key) header.d=gmail.com
Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2a00:1450:4864:20::435; helo=mail-wr1-x435.google.com; envelope-from=gmazyland@gmail.com; receiver=<UNKNOWN> 
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.server123.net (Postfix) with ESMTPS
	for <dm-crypt@saout.de>; Sat, 10 Apr 2021 21:27:23 +0200 (CEST)
Received: by mail-wr1-x435.google.com with SMTP id p6so2147662wrn.9
        for <dm-crypt@saout.de>; Sat, 10 Apr 2021 12:27:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20161025;
        h=subject:to:references:from:message-id:date:user-agent:mime-version
         :in-reply-to:content-language:content-transfer-encoding;
        bh=LBBgeJwCOLwVx2yuVhZcpuT0ySVs2GOcrUIuPXx2v5I=;
        b=hZjBNUg43aIcFWi0Lx1Ms7TZybJZVG5KF/2py/nSAWnbBvffYhKg5B3TO+B2qfZBYS
         ++bBbPA1y8SOo/bgBQCWdXe8AUVUXRM1S/IeF8EfLbTmB/Nl9eozFvb5F47NewWM/tnu
         oO8bPRQ3x65Yzsf6ZFnsj6SCrTjY2hQgNtH8TMTLjcqPFRvk6J3urmOcwiRoka0CGBOY
         W+q795CCDCoQ9TEKHsZBQHCXJzm5P6KJRBEizhWKmaXupEVseZEHl+HR+kSV7dLTPeLc
         Zp83y9lbgin7rv8J/ZR70pLLdmK9pXi4ngzD3tesjWUao/X2tzi/VpQYlTnIuHPXUhWh
         bWug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:subject:to:references:from:message-id:date
         :user-agent:mime-version:in-reply-to:content-language
         :content-transfer-encoding;
        bh=LBBgeJwCOLwVx2yuVhZcpuT0ySVs2GOcrUIuPXx2v5I=;
        b=M4ULPbo5l3szixP4P0zdT1MMIHgKbaV/dHjQx+n3kiuG0KCpyxxM6uIKRi96KaoGXJ
         dGFxChTBVTYdl2y7x00iQKrRVzB0zs3UPmvTUPPk81PrXghpKIcjaevhy9NuROBaOrLL
         cbZQda6ZrHUo26e0xiFzBbHhjM/y+U6G1uj3RlL2GcrG6KzysZT3NgOQUX5MI2TikM3K
         OJwBX7LyTSDLVeuTiCND5nkyYRuD9GiVs6N+uHbFrOM3hqemogQdq/AdpdwjLmrsrEhc
         MD7/zytgazlwijadtUIw+jay70d6jcWLK97g4TSG5Q3Hu7G0h6WJ4ThRHa0VQj4MqhjC
         5Z2A==
X-Gm-Message-State: AOAM531qwU16oE9tR2UbLz5NTUyknydUVRqbkF3nHhZLFoTFyVwW0TsG
	q8K0G38pDNmQGJNigjQ8qHcrX+okhc4=
X-Google-Smtp-Source: ABdhPJzp1rTlUZzILluTuWOHNS5RJFfhH4UcdQFXAAM2twUVNfb9eDfqXJe0BZqwznEWwLa5zo1bBw==
X-Received: by 2002:adf:c186:: with SMTP id x6mr24008912wre.253.1618082842759;
        Sat, 10 Apr 2021 12:27:22 -0700 (PDT)
Received: from [192.168.2.27] (39.35.broadband4.iol.cz. [85.71.35.39])
        by smtp.gmail.com with ESMTPSA id m11sm9815840wri.44.2021.04.10.12.27.21
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Sat, 10 Apr 2021 12:27:22 -0700 (PDT)
To: "Schneider, Robert" <robert.schneider03@sap.com>,
 "dm-crypt@saout.de" <dm-crypt@saout.de>
References: <AM0PR02MB5585DDB379587BDCADB87F628F739@AM0PR02MB5585.eurprd02.prod.outlook.com>
From: Milan Broz <gmazyland@gmail.com>
Message-ID: <96066d25-7e45-17a9-6799-e6dd39b3bffb@gmail.com>
Date: Sat, 10 Apr 2021 21:27:21 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.9.0
MIME-Version: 1.0
In-Reply-To: <AM0PR02MB5585DDB379587BDCADB87F628F739@AM0PR02MB5585.eurprd02.prod.outlook.com>
Content-Language: en-US
Message-ID-Hash: EW77SERTX54VY64UVRCA4SGTXXQ5WVP6
X-Message-ID-Hash: EW77SERTX54VY64UVRCA4SGTXXQ5WVP6
X-MailFrom: gmazyland@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dm-crypt.saout.de-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header
X-Mailman-Version: 3.3.2
Precedence: list
Subject: [dm-crypt] Re: Transactional updates for LUKS2 metadata?
List-Id: <dm-crypt.saout.de>
List-Help: <mailto:dm-crypt-request@saout.de?subject=help>
List-Post: <mailto:dm-crypt@saout.de>
List-Subscribe: <mailto:dm-crypt-join@saout.de>
List-Unsubscribe: <mailto:dm-crypt-leave@saout.de>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

On 09/04/2021 20:46, Schneider, Robert wrote:
> Hi,
> 
> Is there a way to get transactions over multiple metadata operations when using libcryptsetup?
> 
> Imagine I have some mechanism for unlocking which requires information from a token associated to a keyslot. Now I'd like to update that information in the token together with the keyslot.
> But if the machine reboots in between the API calls, I believe my unlock mechanism would be broken - for example, when I've updated the keyslot but still have the old token.
> 
> I could not find an operation to update a token atomically, nor any transaction operations (like open transaction, commit) in the API. I've had a quick glance at the source code and it looks to me like the header is updated in memory and finally written to disk with replica, using a sequence number. This suggests to me that transactions should be relatively easy to implement. However I don't see the full picture of course, so I'd like to know your opinion.
> 
> As an alternative to transactions within the libcryptsetup API, it looks like it's possible to perform a header backup, then manipulate the detached (backup) header, and finally restore the header - as long as the volume key is not changed. Do you think that's a reasonable alternative, or are there potential pitfalls here?

LUKS2 header is not database and never will be. Implementing transactions smells like overengineering here.

For "complex" operations you can recover after failure by removing token metadata and recreate them, it is expected that you still
have a backup keyslot or volume key (or header backup).

And yes, you can modify backup header externally and then update it. But then the recovery can fail with a partial write or a media failure,
so you will end in the same situation you tried to avoid.

Milan
_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de