From nobody Thu May 25 13:40:06 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QRq1d73RVz4V1KC; Thu, 25 May 2023 13:40:21 +0000 (UTC) (envelope-from gusev.vitaliy@gmail.com) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QRq1d6XChz49Wg; Thu, 25 May 2023 13:40:21 +0000 (UTC) (envelope-from gusev.vitaliy@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lf1-x134.google.com with SMTP id 2adb3069b0e04-4f3baf04f0cso2393521e87.1; Thu, 25 May 2023 06:40:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685022018; x=1687614018; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=SgjAC+kTpUWPKowBxrOZR11GblLebEpUF0Yh32dQoN0=; b=OOrtFCtBF3CUSJz0Oav2DCrXZDn0dVZ3B7FXn4I6tj0HVpfgfe9lGu3yehtTYktO1C rfwVnUHaNxEZihY7Lx7k37Qs730NyTwq4Y8+MZHzsuRW1DC4ouryls0uA6pWACfto+TT apZvRvS/yh/7VxJmq7+bbJ71tgVqNfHk/jZ9pGIZ1k1H7MHbtNzrXc+g5Z5BHARH1piS G8Qpo+qPOsdrjvxF9gd9kunj4cpZcL11cO2TO4t9mZmBPXC5ZMbnce9FEpAiHxvW9WUM r1vcJPagCbTvnkcT90OlsYcRzVxRteQD+nTadmnfXxL77V0yZOnskxZHfH3tMf7TphDF +Tbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685022018; x=1687614018; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=SgjAC+kTpUWPKowBxrOZR11GblLebEpUF0Yh32dQoN0=; b=iBydoYMu9B69yETrS7gr0ARop2gBAzKTDT1vz94QoVsEbX38m+RnOgTmSZnzp89x3e oLl+EJLkYiSJdIKwkcnw4hawqzmPuvFGzIWWb/dWyHgoyNsGYJXgEh8+EOm+SkcvRaL4 vXhGGW6YMIWwwX/XsHs7IrE4iTWuyFBgLGAwScxRdpIQJStPetpr7Y9OndnM5Kk1nyCi M3bifPNLIp2Wj/0xQWEP1H2SLAiYAqwCKLkrpqXgmCrRXrVnY/dP5BCKgr0y8gDWuXIc nqRO/Yw18vr3Kvc/TX06a22cathx50mjbIbJogcDsq79Y9PBD8aLVkwc0EkoL5QjuKXa PfJQ== X-Gm-Message-State: AC+VfDxsLBp7WNLhH2RJ5lh5arAMy2o+U4+X+PHJRRmJInqlXs2Vrzjo 3QbPWZT6ERGTRhjdCqM1sQpkrKl+1FnI3A== X-Google-Smtp-Source: ACHHUZ4oqGuVc3USY0dp5vYvS11tt0n5YNEj5pBwJk+SUiLwxMKm5qdw/+Mn1TvBB01vT419klJovw== X-Received: by 2002:ac2:5991:0:b0:4f3:940d:abc with SMTP id w17-20020ac25991000000b004f3940d0abcmr5796153lfn.0.1685022017615; Thu, 25 May 2023 06:40:17 -0700 (PDT) Received: from smtpclient.apple ([78.140.234.98]) by smtp.gmail.com with ESMTPSA id p21-20020ac246d5000000b004f3ba3b948dsm210729lfo.284.2023.05.25.06.40.17 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 May 2023 06:40:17 -0700 (PDT) From: Vitaliy Gusev Message-Id: <8FE14143-1AA9-418E-A497-FEFB99BF6B9F@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_CD459CBE-FE38-45F5-8B0C-D194440D4C9B" List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.500.231\)) Subject: Re: BHYVE SNAPSHOT image format proposal Date: Thu, 25 May 2023 16:40:06 +0300 In-Reply-To: Cc: virtualization@freebsd.org, freebsd-hackers@freebsd.org To: Tomek CEDRO References: <67FDC8A8-86A6-4AE4-85F0-FF7BEF9F2F06@gmail.com> X-Mailer: Apple Mail (2.3731.500.231) X-Rspamd-Queue-Id: 4QRq1d6XChz49Wg X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_CD459CBE-FE38-45F5-8B0C-D194440D4C9B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 25 May 2023, at 04:30, Tomek CEDRO wrote: >=20 > On Wed, May 24, 2023 at 5:11=E2=80=AFPM Vitaliy Gusev wrote: >> Protecting requires more efforts and it should be clearly defined: = what is purpose. If >> purpose is having checksum with 99.9% reliability, NVLIST HEADER can = be widen >> to have =E2=80=9Cchecksum=E2=80=9D key/value for a Section. >=20 > Well, this could be optional but useful to make sure snapshot did not > break somehow for instance backup medium error or something like > that.. even more maybe a way to fix it.. just a design stage idea :- Yes, new format can have checksum of a Section data if implemented. >=20 >=20 >> If purpose is having crypto verification - I believe sha256 program = should be your choice. >=20 > My question was more specific to availability of that feature > (integrity + repair) rather than specific format :-) >=20 > The use case here is having a virtual machine (it was VirtualBox) with > a bare os installed, plus some common applications, that is snapshoted > at some point in time, then experimented a lot, restored from > snapshot, etc. I had a backup of such vm + snapshot backed up that got > broken somehow. It would be nice to know that something is broken, > what is broken, maybe a way to fix :-) =E2=80=9CIntegrity" is a very broad term. What checksum algorithm is = fine enough? =20 For the instance, ZFS has several options for checksum: checksum=3Don|off|fletcher2|fletcher4|sha256|noparity|sha512|skein|edonr =20 Having checksum for a filesystem is strongly recommended. However, If = consider image format, it doesn=E2=80=99t need to care about consistency in a file itself. As = example (!) - binary files in a system. They don=E2=80=99t have checksum integrated, validation is done by = another program - pkg or another. >=20 >=20 >> Why do you need modify snapshot image ? Could you describe more? Do = you >> modify current 3 snapshot files? >=20 > Analysis that require ram / nvram modification? Not sure if this is > already possible, but may come handy for experimenting with uefi and > maybe some OS (features) that will not run with unmodified nvram :-P Sorry I don=E2=80=99t get, why do you need to modify snapshot image, but = not directly vmem on the running VM? Another question, checksum and modifying image - two mutual exclusive = things.=20 >=20 >=20 >> If you are talking about compatibility of a Image format - it should = be compatible in >> both directions, at least for not so big format changes. >>=20 >> If consider overall snapshot/resume compatibility - I believe = forward compatibility >> is not case and target. Indeed, why do you need to resume an image = created by >> a higher version of a program? >=20 > This happens quite often. For instance there is a bug in application > and I need to revert to (at least) one step older version. Then I am > unable to work on a file that I just saved (or was autosaved for me). > Firefox profile settings let be the first example. KiCAD file format > is another example (sometimes I need to switch to a devel build to > evade a nasty blocker bug then anyone else that uses a release is > blocked for some months including me myself). Any additional thing has a cost of development, testing and support. = Current Implementation doesn=E2=80=99t support compatibility at all. Having = compatibility in both directions can be hard. For example, if some variable is removed in bhyve, backward = compatibility is fine, but forward compatibly is not possible unless that removed variable is = being saved into a snapshot image just for forward compatibility. And of course, it = should be tested and verified as worked. Do you like that approach? I don=E2=80=99t think so. So I guess only = backward compatibility should be supported to make the snapshot code simple and robust. Thanks, Vitaliy Gusev --Apple-Mail=_CD459CBE-FE38-45F5-8B0C-D194440D4C9B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 25 = May 2023, at 04:30, Tomek CEDRO <tomek@cedro.info> wrote:

On Wed, May 24, 2023 at = 5:11=E2=80=AFPM Vitaliy Gusev wrote:
Protecting requires more efforts and it should be clearly = defined: what is purpose. If
purpose is having checksum with 99.9% = reliability, NVLIST HEADER can be widen
to have =E2=80=9Cchecksum=E2=80= =9D key/value for a Section.

Well, this could be = optional but useful to make sure snapshot did not
break somehow for = instance backup medium error or something like
that.. even more maybe = a way to fix it.. just a design stage idea = :-

Yes, new format can have checksum of a = Section data if implemented.



If purpose is = having crypto verification - I believe sha256 program should be your = choice.

My question was more specific to = availability of that feature
(integrity + repair) rather than = specific format :-)

The use case here is having a virtual machine = (it was VirtualBox) with
a bare os installed, plus some common = applications, that is snapshoted
at some point in time, then = experimented a lot, restored from
snapshot, etc. I had a backup of = such vm + snapshot backed up that got
broken somehow. It would be = nice to know that something is broken,
what is broken, maybe a way to = fix = :-)


 =E2= =80=9CIntegrity" is a very broad term. What checksum algorithm is fine = enough?
 
For the instance,  ZFS has = several options for checksum:

checksum=3Don|off|fletcher2|fletcher4= |sha256|noparity|sha512|skein|edonr=

      =  


Having = checksum for a filesystem is strongly recommended. However, If consider = image format,
it  doesn=E2=80=99t need to care about = consistency in a file itself. As example (!)  - binary files in a = system.
They don=E2=80=99t have checksum integrated, = validation is done by another program  - pkg or = another.




Why do you = need modify snapshot image ? Could you describe more? Do you
modify = current 3 snapshot files?

Analysis that require ram = / nvram modification? Not sure if this is
already possible, but may = come handy for experimenting with uefi and
maybe some OS (features) = that will not run with unmodified nvram = :-P


Sorry I = don=E2=80=99t get, why do you need to modify snapshot image, but not = directly vmem on the = running
VM?

Another question, = checksum and modifying image - two mutual exclusive = things. 



If you are = talking about compatibility of a Image format - it should be compatible = in
both directions, at least for not so big format changes.

If = consider overall snapshot/resume compatibility - I believe  forward = compatibility
is not case and target. Indeed, why do you need =  to resume an image created by
a higher version of a = program?

This happens quite often. For instance = there is a bug in application
and I need to revert to (at least) one = step older version. Then I am
unable to work on a file that I just = saved (or was autosaved for me).
Firefox profile settings let be the = first example. KiCAD file format
is another example (sometimes I need = to switch to a devel build to
evade a nasty blocker bug then anyone = else that uses a release is
blocked for some months including me = myself).

Any additional = thing has a cost of development, testing and support. = Current
Implementation doesn=E2=80=99t support compatibility = at all. Having compatibility in both
directions can be = hard.

For example, if some variable is removed = in bhyve, backward compatibility is fine,
but forward = compatibly is not possible unless that removed variable is being = saved
into a snapshot image just for forward compatibility. = And of course, it should be tested
and verified as = worked.

Do you like that approach? I don=E2=80=99= t think so. So I guess only backward compatibility
should be = supported to make the snapshot code simple and = robust.

Thanks,
Vitaliy = Gusev


= --Apple-Mail=_CD459CBE-FE38-45F5-8B0C-D194440D4C9B--