Hello,

I'm wondering if there is a way to move or copy "sparse" VM image files
between Qubes VMs and retain the small sparse filesize without it
expanding out to full size upon move/copy.

Either from AppVM to AppVM, or AppVM to Dom0.


I've tried:

qvm-move-to-vm

qvm-copy-to-vm

qvm-run --pass-io <src_domain> 'cat /path/to/file_in_src_domain' >
/path/to/file_name_in_dom0


No luck. With each method, the ~2GB sparse VM image file expands out to
its full ~100GB space allocation and takes forever (~1.5 hours) to write
the new file.

Is there a way for Qubes to handle moving/copying "sparse" files?


Speculative answer... Maybe some way to substitute "cp --sparse=always" or
"mv" into command, instead of using "cat", in order to retain small sparse
file size?


Thank you!

The usual way to batch-copy sparse files over a network is to use 'tar'
on both ends and it will try to preserve the sparse-ness. It'll work
fine with qvm-run and for single files, too.
$ qvm-run --pass-io sourcevm 'tar -cSf - filenames' | qvm-run --pass-io
destvm 'tar xSf -'

Wow, thank you so much, cprise!

This helps me out big time...


Copy time: from ~1.5 hours down to ~15 minutes now.

Disk space used: from ~107GB down to ~2.6GB now.

On a laptop HDD (non-SSD) drive.


For AppVM to AppVM sparse file copy, I'm now using:

qvm-run --pass-io <source-appvm-name> 'tar -cvSf - filename' | qvm-run
--pass-io <destination-appvm-name> 'tar xvSf -'


For AppVM to Dom0 sparse file copy, I'm now using:

qvm-run --pass-io <source-appvm-name> 'tar -cvSf - filename' >
~/filename.tar && tar -xvSf ~/filename.tar


Works super! Thank you! :)

Glad it helped!

However, now that I think about using this on Qubes, I feel obliged to
mention that you're placing some trust in the sourcevm to create the tar
stream properly (with no exploits against the tar format).

A safer alternative would involve reading unallocated space as zeroes
but converting them to sparse seeks on the side that writes the new file:
$ qvm-run --pass-io sourcevm 'cat file.img' | qvm-run --pass-io destvm
'dd of=file.img conv=sparse'

 From appvm to dom0 (no need to create an intermediate file on disk):
$qvm-run --pass-io sourcevm 'cat file.img' | dd of=file.img conv=sparse

This method will take longer due to much more in-memory copying of
zero-ed blocks, but those extra blocks will never be allocated to disk
because 'dd' will skip over them. OTOH, if your intention was to mount
the image in the destvm anyway then using a safer copy process may not
matter in that case.

>
> Glad it helped!
>
> However, now that I think about using this on Qubes, I feel obliged to
> mention that you're placing some trust in the sourcevm to create the tar
> stream properly (with no exploits against the tar format).
>
> A safer alternative would involve reading unallocated space as zeroes
> but converting them to sparse seeks on the side that writes the new file:
> $ qvm-run --pass-io sourcevm 'cat file.img' | qvm-run --pass-io destvm
> 'dd of=file.img conv=sparse'
>
>  From appvm to dom0 (no need to create an intermediate file on disk):
> $qvm-run --pass-io sourcevm 'cat file.img' | dd of=file.img conv=sparse
>
> This method will take longer due to much more in-memory copying of
> zero-ed blocks, but those extra blocks will never be allocated to disk
> because 'dd' will skip over them. OTOH, if your intention was to mount
> the image in the destvm anyway then using a safer copy process may not
> matter in that case.
>

Thanks for mentioning this cprise.

Efficient copy time is a meaningful attribute here, so I'll have to see
how much time it adds to this step.

I'm not sure if the potential vulnerability would be "passive" with the
file itself being modified, or somwhow "active" from the tar and transfer
procedure.

If just a passive concern about the file being modified, then maybe a
simple sha512sum comparison between the source file to the destination
file, before using it, would mitigate this concern?

The intention for the file is to mount it as the "root.img" for a new VM.

A compromised/malicious sourcevm could infect the disk img itself about
as easily as a tar stream. The questions are: do you consider sourcevm
safe/trustworthy, and if not then can you operate the vm that will run
the img with the same lowered level of trust? If sourcevm is
trustworthy, then I'd surmise there is no risk.

Using tar in the copy process does pose a slight active risk to the
destvm, but IMHO it could be worse since compression isn't used. When
using the alternate method with 'dd', there is no risk until you
consider mounting the image.

I don't know about the use of a sha hash, because someone trustworthy
has to perform it and it sounds like you don't trust sourcevm. If the
img came from a trustworthy place before it was downloaded to sourcevm,
then perhaps there is already a hash available from that initial source
and you could use that to verify the img in your destvm.

whoni...@mail2tor.com:
This might be a silly question, but why not either

a) download the img directly to the VM in which it will be stored,

or

b) mount the img from the VM in which it was downloaded?

> A compromised/malicious sourcevm could infect the disk img itself about
> as easily as a tar stream. The questions are: do you consider sourcevm
> safe/trustworthy, and if not then can you operate the vm that will run
> the img with the same lowered level of trust? If sourcevm is
> trustworthy, then I'd surmise there is no risk.

Yes, I'd think that the sourcevm is safe/trustworthy, assuming certain use
cases.

A brand new Qubes AppVM based on built-in Fedora Template is being created
and used as the sourcevm in real-time.

Temporary existence for this sourcevm to get the img file into Qubes,
maybe a little file extraction and conversion work, and then transferred
over to dom0.

Img file is likely either being downloaded within sourcevm or transferred
via external media like USB stick to sourcevm.

Then transferred from this new dedicated temporary sourcevm to dom0. And
the sourcevm is destroyed.

As to the question about differing trust levels between sourcevm and
destvm, that depends upon the individual users specific use case(s). Some
yes. Some no.

But I'd assume a newly created Qubes Fedora AppVM should be
safe/trustworthy onto itself, only to be pretty much used as a dedicated
temporary working file extraction, conversion, and transfer mechanism.

> Using tar in the copy process does pose a slight active risk to the
> destvm, but IMHO it could be worse since compression isn't used. When
> using the alternate method with 'dd', there is no risk until you
> consider mounting the image.

Thanks for the mention of slight active risk increase.

> I don't know about the use of a sha hash, because someone trustworthy
> has to perform it and it sounds like you don't trust sourcevm. If the
> img came from a trustworthy place before it was downloaded to sourcevm,
> then perhaps there is already a hash available from that initial source
> and you could use that to verify the img in your destvm.

Yes... Both SHA512 hashes and GPG signatures are provided by source
developer website.

If user extracts and converts image in-between downloading from website
and booting as root.img in dom0, then there wouldn't be hash or signature
verification ability on the destvm (dom0), and even greater trust would be
placed on all environments the file passes through after wherever such
work is done upon it.


I'm wondering if maybe it would be safer/better/more-trustworthy to do
such extraction (tar) and conversion (qemu-img) of such qcow2 images to
raw images in dom0, after verifying source file download integrity in
final destvm (dom0)?

It would help verify the file integrity for sure, but it would require
installing qemu-img in dom0 and running a tar extract and qemu-img convert
process on a qcow2 image in dom0. Not sure if that adds any greater risk
to the overall system than doing so in a dedicated temporary AppVM as
planned and living with the lack of source file verification after
extraction/conversion? Especially since we're talking about such matters
within dom0, I wonder.

> This might be a silly question, but why not either
>
> a) download the img directly to the VM in which it will be stored,
>
> or
>
> b) mount the img from the VM in which it was downloaded?

Hello Axon,

a) Will be stored in dom0, so not really a good security option to
download direct here, I assume.

b) I did attempt to mount the "root.img" from a dedicated AppVM that held
the img files, as Joanna described to me, but for whatever reason they
would not boot. Yet the same images booted fine when placed in dom0. I
used Advanced tab: "Additional drive" option. Maybe this option failed due
to incompatibility with "sparse" img files?

On 08/25/14 18:17, whoni...@mail2tor.com wrote:
> Yes... Both SHA512 hashes and GPG signatures are provided by source
> developer website.

Well, since you both a) have an original signature and b) trust sourcevm
anyway, your task is pretty simple. If it were me, I'd probably lean a
bit more toward security and do the verify step in a separate
no-networking vm, then use the dd method to transfer to dom0.

>
> If user extracts and converts image in-between downloading from website
> and booting as root.img in dom0, then there wouldn't be hash or signature
> verification ability on the destvm (dom0), and even greater trust would be
> placed on all environments the file passes through after wherever such
> work is done upon it.
>
>
> I'm wondering if maybe it would be safer/better/more-trustworthy to do
> such extraction (tar) and conversion (qemu-img) of such qcow2 images to
> raw images in dom0, after verifying source file download integrity in
> final destvm (dom0)?

If the source img type is raw, it would be a very simple conversion and
therefore low-risk IMHO, especially if you specify the input img type to
the converter instead of having it auto-detect the format. But if you do
the gpg verify and the conversion in the destvm, then there is risk only
coming from upstream and also dom0 is not exposed even if the final img
gets stored in dom0 and accessed from there.

> It would help verify the file integrity for sure, but it would require
> installing qemu-img in dom0 and running a tar extract and qemu-img convert
> process on a qcow2 image in dom0. Not sure if that adds any greater risk
> to the overall system than doing so in a dedicated temporary AppVM as
> planned and living with the lack of source file verification after
> extraction/conversion? Especially since we're talking about such matters
> within dom0, I wonder.
>

Dom0 already has a version of the converter as 'qemu-img-xen', but I
would still do the verify and conversion in the destvm (which I would
create without networking for the purpose of verifying and proccessing
the img files).

Well taken and understood. Thank you very much for your thought out and
highly informative replies, cprise! :)

whoni...@mail2tor.com:
Oh, I see. Copying anything from a less trusted source to dom0 always
makes me very nervous. (And, by definition, everything is less trusted
than dom0, since dom0 is "ultimately trusted.") Nonetheless, merely
copying a stream of bytes to dom0 is not in itself a risk.[1]

However, I don't know whether any additional risk is incurred by
subsequently running a VM off of the img in dom0. It sounds similar to
the question I asked in another thread[2] (in which the answer seems to
be "no").

> I used Advanced tab: "Additional drive" option.

What is that? It sounds like an option in Qubes VM Manager, but I don't
see anything like that there.


[1]https://groups.google.com/d/msg/qubes-devel/EBc4to5IBdg/f2i2Wj7eXjsJ
[2]https://groups.google.com/d/topic/qubes-users/nDrOM7dzLNE/discussion

whoni...@mail2tor.com:

>> A compromised/malicious sourcevm could infect the disk img itself about
>> as easily as a tar stream. The questions are: do you consider sourcevm
>> safe/trustworthy, and if not then can you operate the vm that will run
>> the img with the same lowered level of trust? If sourcevm is
>> trustworthy, then I'd surmise there is no risk.
>
>
> Yes, I'd think that the sourcevm is safe/trustworthy, assuming certain use
> cases.
>
> A brand new Qubes AppVM based on built-in Fedora Template is being created
> and used as the sourcevm in real-time.
>
> Temporary existence for this sourcevm to get the img file into Qubes,
> maybe a little file extraction and conversion work, and then transferred
> over to dom0.
>
> Img file is likely either being downloaded within sourcevm or transferred
> via external media like USB stick to sourcevm.
>

It sounds like the sourcevm could realistically be compromised through
either vector (e.g., MITMed download, BadUSB stick). We'd then have to
assume that any file(s) which get transferred from the sourcevm to dom0
are also compromised.

> Then transferred from this new dedicated temporary sourcevm to dom0. And
> the sourcevm is destroyed.
>
> As to the question about differing trust levels between sourcevm and
> destvm, that depends upon the individual users specific use case(s). Some
> yes. Some no.
>
> But I'd assume a newly created Qubes Fedora AppVM should be
> safe/trustworthy onto itself, only to be pretty much used as a dedicated
> temporary working file extraction, conversion, and transfer mechanism.
>

I'd say that every AppVM is less trusted than dom0 due the nature of
Xen/Qubes. (In this case, sourcevm = AppVM, and destvm = dom0.) But this
is an old debate.
Merely copying a stream of bytes to dom0 is safe.[1] But performing any
subsequent operations on those bytes exposes dom0 to attack and is
discouraged.[2]

It sounds like the general problem you're facing here is the perennial
problem of securely transferring data from less trusted domains to more
trusted domains. The problem is that any complex verification step you
might take entails an unacceptable risk that the VM in which you perform
that verification step could itself be compromised by malformed input
being fed into the program doing the verifying, which would render any
verification result (and output) from that VM untrustworthy. This is
exactly the problem that Qubes faced when designing its current backup
system. You may be interested in perusing the (admittedly gigantic)
thread[3] on it to see how the problem was analyzed, what solution was
decided upon, why it was chosen, and how it was implemented.

I don't know how serious the security implications are (for dom0) in
your case, but if they're significant, it may be worthwhile to figure
out some way to use the img files from an AppVM rather than from dom0,
if at all possible.

[1]https://groups.google.com/d/msg/qubes-devel/EBc4to5IBdg/f2i2Wj7eXjsJ
[2]https://qubes-os.org/wiki/SecurityGuidelines#Dom0Precautions
[3]https://groups.google.com/d/topic/qubes-devel/TQr_QcXIVww/discussion

>> I used Advanced tab: "Additional drive" option.
>
> What is that? It sounds like an option in Qubes VM Manager, but I don't
> see anything like that there.

In Qubes R2rc2, I get to it by going to:

Qubes VM Manager -> Select a VM -> VM Settings -> Advanced -> Additional
drive


Joanna mentioned it to me in the following thread [1], saying:

"However, we already have some support for starting VMs using backends
hosted in other VMs: you can pass the VM name to --cdrom/--hddisk
options for qvm-start (also nicely supported from Qubes Manager).
E.g. I have a VM called "installs" where I keep all the various
installation ISOs I copied from my DVDs or downloaded from the net. When
I need to create a new HVM, I just point to the ISO on the "installs" VM
filesystem and so I never need to copy it to Dom0."


However, it did not seem to work for me when I tried to boot a "sparse"
img for a HVM as an additional drive from a different dedicated AppVM.


[1] https://groups.google.com/d/topic/qubes-devel/zHrCA8Zp7No

whoni...@mail2tor.com:
That's very weird. I'm (supposedly) on R2rc2, but I don't have that
option in Qubes VM Manager at all.

I upgraded from a previous install rather than installing from an R2rc2
ISO, so maybe that's why.

I remember using CLI option a long time ago, though, so I think that has
been supported for a while now.

> That's very weird. I'm (supposedly) on R2rc2, but I don't have that
> option in Qubes VM Manager at all.
>
> I upgraded from a previous install rather than installing from an R2rc2
> ISO, so maybe that's why.
>
> I remember using CLI option a long time ago, though, so I think that has
> been supported for a while now.

Axon,

Looks limited to "Standalone HVM".

VMs with OS templates seem to have kernel selection options instead.

> It sounds like the sourcevm could realistically be compromised through
> either vector (e.g., MITMed download, BadUSB stick). We'd then have to
> assume that any file(s) which get transferred from the sourcevm to dom0
> are also compromised.

Yeah, I guess it could be.

Though, one doesn't have to assume the files are definitely or likely
compromised. One just has to assume that they "could be" compromised,
estimate the general likelihood of file compromise, and make a decision to
boot the file or not based on the person's own personal risk tolerance.

In order to compromise the files, and fake file verification, it just
seems like a decently high bar of exploit to do so. Although technically
possible, the general likelihood just seems pretty low at any given time.

While I do acknowledge the possibility, I don't see myself or most others
assuming definite or likely compromise here if general precautions are
taken (e.g. file verification, trustworthy vendors, encrypted traffic,
etc) and the individual is not a high profile target or likely to be under
advanced persistent threat.

But each individual can tailor decisions to their own personal risk
profile/preferences. Just like the choice virtually all of us make to risk
using our hardware, firmware, drivers, Linux, Xen, Qubes, and all the
other associated libraries, apps, and updates.

> I'd say that every AppVM is less trusted than dom0 due the nature of
> Xen/Qubes. (In this case, sourcevm = AppVM, and destvm = dom0.) But this
> is an old debate.

Yeah, I'd agree with that statement.

> I don't know how serious the security implications are (for dom0) in
> your case, but if they're significant, it may be worthwhile to figure
> out some way to use the img files from an AppVM rather than from dom0,
> if at all possible.

It would be nice to figure out that feature (--hddisk) of how to boot
sparse images from AppVMs to Standalone HVMs. It didn't seem to work for
me, even though the images booted fine in dom0. Maybe sparse files break
this capability?

whoni...@mail2tor.com:
Oh, of course! I was only checking regular AppVMs, but I see it now.
Thanks for pointing that out. :)

> Oh, of course! I was only checking regular AppVMs, but I see it now.
> Thanks for pointing that out. :)

You got it, Axon! :)

Not an option for me on a Fedora standalone. It must be available only
for HVMs.

I don't think its possible to boot from private.img files, if that's
what you mean. They lack the system files that are contained in the
template's root.img. You would have to at least copy a root.img from a
template to create a standalone HVM from it, I think. And probably the
qubes tools support that scenario. Then you would either copy the
contents of a private.img into your new standalone filesystem, or mount
it in additon to the root.img (run 'mount' in an appvm to see the spots
where the private.img gets mounted).

> Not an option for me on a Fedora standalone. It must be available only
> for HVMs.

Yeah, seems limited to Standalone HVMs.

Maybe because the concept is about mounting an alternate root.img from
outside dom0?

Where VMs based on templates, either Standalone derived from Fedora
template, or standard AppVM with active template, might assume that one
wouldn't have a need to boot an alternative root.img.

However, an HVM that is a Stanalone HVM often may get their root.img from
a "new" non-templated source, such as an installation ISO or existing VM
disk (in my case).

That's my guess, anyway.

> I don't think its possible to boot from private.img files, if that's
> what you mean. They lack the system files that are contained in the
> template's root.img. You would have to at least copy a root.img from a
> template to create a standalone HVM from it, I think. And probably the
> qubes tools support that scenario. Then you would either copy the
> contents of a private.img into your new standalone filesystem, or mount
> it in additon to the root.img (run 'mount' in an appvm to see the spots
> where the private.img gets mounted).

This would be an alternate for the root.img file.

It is a sparse raw img file loaded with a Debian Wheezy operating system.

It boots fine when transferred into dom0 and imported into the standard VM
system directory.

However, it does not boot "No boot device" when mounted as an "additional
drive" from another AppVM using this feature.

So I know this sparse img with Debian OS installed on it works fine as a
root.img in dom0.

I've also booted Debian ISO disks from AppVMs this way.

It would be a good test to compare trying to boot a non-sparse img this
way from an AppVM and see what happens.

whoni...@mail2tor.com:
In Qubes, aren't all HVMs by definition "Standalone HVMs"? I'm not aware
of any such thing as a "Non-standalone HVM" in Qubes.

(This is a sincere question; I'm not trying to be pedantic. So, I
apologize if it comes across that way.)

On 08/29/14 09:52, Axon wrote:
> In Qubes, aren't all HVMs by definition "Standalone HVMs"? I'm not aware
> of any such thing as a "Non-standalone HVM" in Qubes.

https://wiki.qubes-os.org/wiki/WindowsAppVms

Using template-based_Windows_AppVMs


--
Zrubi

Zrubi:
Ah, I see. I guess the terminology which Qubes employs is a little
confusing, since we borrow "HVM" from Xen but don't borrow "PV" from Xen
(at least not to the same extent, i.e., in an "official" way). We seem
to have substituted "AppVM" for "PV VM" in some cases. (Actually, the
usage of "AppVM" is largely inconsistent, since AppVM is also sometimes
used to refer to "any VM in Qubes.")

Axon:
For example, Qubes VM Manager distinguishes between "HVM" and "HVM
template" in the prompt to create a new VM. VMs which are based on a
Windows "HVM template" are (as Zrubi pointed out) called "Windows
AppVMs," but all of those are (apparently) different from plain old "HVMs."

So, if I *really* wanted to be pedantic, I could say: "Technically, I
was right! All HVMs are 'standalone' since any VM which depends on
another (necessarily standalone) VM for its root filesystem is called an
'AppVM', while the standalone VM which supplies the root filesystem is
called a 'template'. There are only regular HVMs and HVM templates, both
of which contain their own root filesystems. Therefore, all HVMs are
standalone VMs!" :)

Perhaps I should create a "glossary" page on the wiki. Hm...

On 08/29/14 10:32, Axon wrote:

> For example, Qubes VM Manager distinguishes between "HVM" and "HVM
> template" in the prompt to create a new VM. VMs which are based on a
> Windows "HVM template" are (as Zrubi pointed out) called "Windows
> AppVMs," but all of those are (apparently) different from plain old "HVMs."
>
> So, if I *really* wanted to be pedantic, I could say: "Technically, I
> was right! All HVMs are 'standalone' since any VM which depends on
> another (necessarily standalone) VM for its root filesystem is called an
> 'AppVM', while the standalone VM which supplies the root filesystem is
> called a 'template'. There are only regular HVMs and HVM templates, both
> of which contain their own root filesystems. Therefore, all HVMs are
> standalone VMs!" :)
>
> Perhaps I should create a "glossary" page on the wiki. Hm...

Sure we should make it clear - however I don't fully agree with your
explanation.

PV:
http://wiki.xenproject.org/wiki/Paravirtualization_%28PV%29

HVM
http://wiki.xenproject.org/wiki/Xen_Overview#HVM

What we really using in case of the Windows AppVMs is called
"PV on HVM"  or PVH:
http://www.informit.com/articles/article.aspx?p=2233978


So the main difference if the Guest OS kernel needs to know about the
virtualization (PV) or not (HVM)

If the actual VM is based on a template or not is really another
question. Currently we calling the non template based VMs Standalone,
but those are usually HVMs or PVH type regarding the virtualization.





--
Zrubi

Double posting to create a real new thread.

On 08/29/14 10:32, Axon wrote:

> For example, Qubes VM Manager distinguishes between "HVM" and "HVM
> template" in the prompt to create a new VM. VMs which are based on a
> Windows "HVM template" are (as Zrubi pointed out) called "Windows
> AppVMs," but all of those are (apparently) different from plain old
"HVMs."
>
> So, if I *really* wanted to be pedantic, I could say: "Technically, I
> was right! All HVMs are 'standalone' since any VM which depends on
> another (necessarily standalone) VM for its root filesystem is called an
> 'AppVM', while the standalone VM which supplies the root filesystem is
> called a 'template'. There are only regular HVMs and HVM templates, both
> of which contain their own root filesystems. Therefore, all HVMs are
> standalone VMs!"
>

On 08/29/14 10:47, Zrubi wrote:
> PV:
> http://wiki.xenproject.org/wiki/Paravirtualization_%28PV%29
>
> HVM
> http://wiki.xenproject.org/wiki/Xen_Overview#HVM
>
> What we really using in case of the Windows AppVMs is called
> "PV on HVM"  or PVH:
> http://www.informit.com/articles/article.aspx?p=2233978
>
>
> So the main difference if the Guest OS kernel needs to know about the
> virtualization (PV) or not (HVM)
>
> If the actual VM is based on a template or not is really another
> question. Currently we calling the non template based VMs Standalone,
> but those are usually HVMs or PVH type regarding the virtualization.

To make it more Qubes specific we have different type of guest (domU)
VMs called:

- Net VM

- Proxy VM

- AppVM
  And We can make more categories here:
  - normal AppVMs - the PV VMs based on template.
  - HVM - based on template
  - Standalone HVM

I guess Axon will make it more detailed and much more readable for the
mass :D



--
Zrubi

Zrubi:

> On 08/29/14 10:47, Zrubi wrote:
>> PV:
>> http://wiki.xenproject.org/wiki/Paravirtualization_%28PV%29
>>
>> HVM
>> http://wiki.xenproject.org/wiki/Xen_Overview#HVM
>>
>> What we really using in case of the Windows AppVMs is called
>> "PV on HVM"  or PVH:
>> http://www.informit.com/articles/article.aspx?p=2233978
>>
>>
>> So the main difference if the Guest OS kernel needs to know about the
>> virtualization (PV) or not (HVM)
>>
>> If the actual VM is based on a template or not is really another
>> question. Currently we calling the non template based VMs Standalone,
>> but those are usually HVMs or PVH type regarding the virtualization.
>

This is a helpful clarification. Thank you, Zrubi!

>

> To make it more Qubes specific we have different type of guest (domU)
> VMs called:
>
> - Net VM
>
> - Proxy VM
>
> - AppVM
>   And We can make more categories here:
>   - normal AppVMs - the PV VMs based on template.
>   - HVM - based on template
>   - Standalone HVM
>
> I guess Axon will make it more detailed and much more readable for the
> mass :D
>

Here's my attempt at doing so. ;)

https://qubes-os.org/wiki/Glossary

If anyone can think of any other terms that should be added, please let
me know.