From nobody Thu May 25 16:22:10 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 4QRtd85PzBz4V9qf; Thu, 25 May 2023 16:22:52 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-yw1-x112d.google.com (mail-yw1-x112d.google.com [IPv6:2607:f8b0:4864:20::112d]) (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 4QRtd35nxjz3MQ8; Thu, 25 May 2023 16:22:47 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20221208 header.b=JrGIqHKf; spf=pass (mx1.freebsd.org: domain of marietto2008@gmail.com designates 2607:f8b0:4864:20::112d as permitted sender) smtp.mailfrom=marietto2008@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-yw1-x112d.google.com with SMTP id 00721157ae682-561e5014336so6763057b3.1; Thu, 25 May 2023 09:22:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685031767; x=1687623767; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=r9YI6+hMcd7OV+oac4bpou6A/Jq22N9AbSDYtZeLido=; b=JrGIqHKffw9TPA6Sj+XsLlfkTTM7xrEKCUW/IzFwghJYqqyMS+0K7QyRMY6nH4diW/ YKKrkFKgoVkUGe7Fu4UFdh6AmrS5p1UZ37f4W2tGR4rOaxgozmdOElQ5OpMupfc46zjv OzNVIhJfZgwpsiZ1kkpwBoFRrJ2K9EYwYbxKzC8KtGIYLC3a+HP6YM3Ar6zFVHxYCX77 S3SK4vwfyZ2LLLAPtHQJSGA1pu4hMu5nH5YDYw0gu+NuwbFsv3/rS+AQL/Y+cLwyyZOJ f234oUdyxfMI33as39TQuJl15P8PsiatZt3OphGbME8bXf3a0KsfVE7tS8rIilukmeKh uKDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685031767; x=1687623767; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=r9YI6+hMcd7OV+oac4bpou6A/Jq22N9AbSDYtZeLido=; b=QGWvkSOpbYT3uYEJxUroy0OW97Ylc84IXmtVJqbcA+VA4gchkh1/y35dbdQDa9B1el aHIpwQF8box+LYB2Z7fNp5oxAN3H2po/ENO5ZkYc0cwvi7LNuzHdwG3xmpbmGSQT+bSq riZKz0d+f8ba7WsWtLtSFVe3CG/XMipDAxbMuUwlOtR2LB8SXpPg5kCOTJiZuVuWqqIz orCIsKTUwEpUUXvE04MMftgmzOWHF4NdYpqf3nVFb7DgADT/A8n5crWhHwvD1sXK7CpY fJQ05+pYuJgdFw88G5yvUOPJdBtwTyHiGbg91chue4NUbAYQxgQd1NOjrOJTpLNmLwLW J3Aw== X-Gm-Message-State: AC+VfDz3GfN/HwfKegkhaJWu6PyDiBkrWHH2v1MxDjh6Qb/Rl5rDFMRL 0h+/Kzsuygj00rcGcBb5Sti/EeD+6Kv52nlB7GdOeCWSyxE= X-Google-Smtp-Source: ACHHUZ5C8uWknnhVdFFjNyRwVoLr5IYLumB1Luk0/Cw1GDXjZpjxG0bsGJ2ihhEHiSC5CfS2Yn+mgy0XQ/lBr4lwh5g= X-Received: by 2002:a25:dcd3:0:b0:ba8:364b:8f3c with SMTP id y202-20020a25dcd3000000b00ba8364b8f3cmr3962142ybe.53.1685031766639; Thu, 25 May 2023 09:22:46 -0700 (PDT) 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 References: <67FDC8A8-86A6-4AE4-85F0-FF7BEF9F2F06@gmail.com> <8FE14143-1AA9-418E-A497-FEFB99BF6B9F@gmail.com> In-Reply-To: <8FE14143-1AA9-418E-A497-FEFB99BF6B9F@gmail.com> From: Mario Marietto Date: Thu, 25 May 2023 18:22:10 +0200 Message-ID: Subject: Re: BHYVE SNAPSHOT image format proposal To: Vitaliy Gusev Cc: Tomek CEDRO , virtualization@freebsd.org, freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="000000000000e2ca2a05fc8707fc" X-Spamd-Result: default: False [-2.50 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20221208]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TAGGED_RCPT(0.00)[]; MLMMJ_DEST(0.00)[virtualization@freebsd.org,freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::112d:from]; RCPT_COUNT_THREE(0.00)[4]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_DN_SOME(0.00)[] X-Rspamd-Queue-Id: 4QRtd35nxjz3MQ8 X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N --000000000000e2ca2a05fc8707fc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Vitaliy, what happens if I clone your repo as source code on my FreeBSD system. Can I test your code directly or not ? Anyway,I think that,before doing this,I need to follow some kind of tutorial,to understand how the workflow is. Otherwise I will be not able to test and stress it. On Thu, May 25, 2023 at 3:40=E2=80=AFPM Vitaliy Gusev wrote: > > > On 25 May 2023, at 04:30, Tomek CEDRO 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 i= s > 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 shoul= d > 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 fin= e enough? > > For the instance, ZFS has several options for checksum: > > *checksum*=3D*on*|*off*|*fletcher2*|*fletcher4*|*sha256*|*noparity*|*sha5= 12* > |*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 e= xample > (!) - binary files in a system. > They don=E2=80=99t have checksum integrated, validation is done by anothe= r 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 compa= tibility > 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 back= ward > compatibility > should be supported to make the snapshot code simple and robust. > > Thanks, > Vitaliy Gusev > > > --=20 Mario. --000000000000e2ca2a05fc8707fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Vitaliy,

what happens if I c= lone your repo as source code on my FreeBSD system. Can I test your code di= rectly or not ? Anyway,I think that,before doing this,I need to follow some= kind of tutorial,to understand how the workflow is. Otherwise I will be no= t able to test and stress it.

On Thu, May 25, 2023 at 3:40=E2=80= =AFPM Vitaliy Gusev <gusev.vi= taliy@gmail.com> wrote:


On 25 May 2= 023, 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 mak= e sure snapshot did not
break somehow for instance backup medium error o= r 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 ver= ification - I believe sha256 program should be your choice.

My question was more specific to availability of that feature
(inte= grity + 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 :-)=


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

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

=C2= =A0 =C2=A0 =C2=A0 =C2=A0


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



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

Analysis tha= t require ram / nvram modification? Not sure if this is
already possible= , but may come handy for experimenting with uefi and
maybe some OS (feat= ures) 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
V= M?

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



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

If consider overall snapsh= ot/resume compatibility - I believe =C2=A0forward compatibility
is not c= ase and target. Indeed, why do you need =C2=A0to resume an image created by=
a higher version of a program?

This happens quite o= ften. 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 t= hat 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 anyon= e else that uses a release is
blocked for some months including me mysel= f).

Any additional thing ha= s a cost of development, testing and support. Current
Implementat= ion doesn=E2=80=99t support compatibility at all. Having compatibility in b= oth
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 i= s being saved
into a snapshot image just for forward compatibilit= y. 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 mak= e the snapshot code simple and robust.

Thank= s,
Vitaliy Gusev




--=
Mario.
--000000000000e2ca2a05fc8707fc--