DispVM IP addr uniqueness in 3.0-rc1
29 views
Skip to first unread message
Joonas Lehtonen
May 2, 2015, 8:22:49 PM5/2/15
to qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi,
I heavily depend on the fact that source IPs of two distinct VMs do
never match*.
I noticed that in 3.0-rc1 dispvms do no longer have that property.
Start a dispvm, kill it, start another, will result in the same dispvm
ID and dispvm IP address.
Is this a bug, or by design? Is it possible to change this behavior to
match to one in R2 via a config change?
thanks,
Joonas
*) If the use case is relevant for you: The property is important
because tor's isolation depends on the source IP when deciding whether
something needs to go on a distinct circuit.
btw: DispVM bootup in R3 is great - thanks for that!
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJVRWpRAAoJENGIB/ssoMC2GXkP/AlhXkagG8J1OCHDQH+azQP1
HZCpyyXmPqOj8fIH1Zk1q4O7h1E6hW6NKaLYKzGt0wGOdYlT1tcT41kuaTsHRGTu
+XQgQy8FHxrejbev8gf8SmqGXNd4xcyKKd+J1sO0HvdGlO1BLDL7a4dd/mDl1mDv
+KbKHje4u22Swl3eCW8WPXoKzyjoxZ5JO9eUYBeonOpz5KoA91PCecKMu+Hm5E8u
k9ie9MVD1iX0uGFphfyTifhKSjknMKnhYcn4kIaLnxIzZsAHR2NlqnQzJ5MbvK/z
msDJ73nnQZ0DNExneR2a46YE9vmT5QoZpvTBmzLFORSTV4ldEhG2TwCL6cvhlby6
A4OM9UQ9/5eYLH+gw7YqavUSIX9ioW+sgrW10hT+HZBjlBle5ozOlz3y3021Tytz
9xRGp0wxn0LUQyQqmvtZGVsdhwSJ7YPgNTDSD07zYNTGvmdrk4dVQ8OO7KGZWpa4
zCvYTDlEFms/ewCIwQShMNyVnptfXaFbNaDEQueg2U7NpDPZU5niKpGygPyWnWMR
zmG3AYXSw5hipJsSmx/UZydgalZnWgVDN451C4JWJD/dk1ywQUvnfr/2j31xhrWb
QTzaNlw9Z/1c7sfG/Dg8g2qzZCpau8pGaNwRTjdEk3/lT2e8kRGoozOBh7+0jOCp
5Xjy6f2PusFfMMky8khs
=gKhn
-----END PGP SIGNATURE-----
Hash: SHA512
Hi,
I heavily depend on the fact that source IPs of two distinct VMs do
never match*.
I noticed that in 3.0-rc1 dispvms do no longer have that property.
Start a dispvm, kill it, start another, will result in the same dispvm
ID and dispvm IP address.
Is this a bug, or by design? Is it possible to change this behavior to
match to one in R2 via a config change?
thanks,
Joonas
*) If the use case is relevant for you: The property is important
because tor's isolation depends on the source IP when deciding whether
something needs to go on a distinct circuit.
btw: DispVM bootup in R3 is great - thanks for that!
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJVRWpRAAoJENGIB/ssoMC2GXkP/AlhXkagG8J1OCHDQH+azQP1
HZCpyyXmPqOj8fIH1Zk1q4O7h1E6hW6NKaLYKzGt0wGOdYlT1tcT41kuaTsHRGTu
+XQgQy8FHxrejbev8gf8SmqGXNd4xcyKKd+J1sO0HvdGlO1BLDL7a4dd/mDl1mDv
+KbKHje4u22Swl3eCW8WPXoKzyjoxZ5JO9eUYBeonOpz5KoA91PCecKMu+Hm5E8u
k9ie9MVD1iX0uGFphfyTifhKSjknMKnhYcn4kIaLnxIzZsAHR2NlqnQzJ5MbvK/z
msDJ73nnQZ0DNExneR2a46YE9vmT5QoZpvTBmzLFORSTV4ldEhG2TwCL6cvhlby6
A4OM9UQ9/5eYLH+gw7YqavUSIX9ioW+sgrW10hT+HZBjlBle5ozOlz3y3021Tytz
9xRGp0wxn0LUQyQqmvtZGVsdhwSJ7YPgNTDSD07zYNTGvmdrk4dVQ8OO7KGZWpa4
zCvYTDlEFms/ewCIwQShMNyVnptfXaFbNaDEQueg2U7NpDPZU5niKpGygPyWnWMR
zmG3AYXSw5hipJsSmx/UZydgalZnWgVDN451C4JWJD/dk1ywQUvnfr/2j31xhrWb
QTzaNlw9Z/1c7sfG/Dg8g2qzZCpau8pGaNwRTjdEk3/lT2e8kRGoozOBh7+0jOCp
5Xjy6f2PusFfMMky8khs
=gKhn
-----END PGP SIGNATURE-----
Marek Marczykowski-Górecki
May 2, 2015, 9:28:32 PM5/2/15
to Joonas Lehtonen, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sun, May 03, 2015 at 12:22:41AM +0000, Joonas Lehtonen wrote:
> Hi,
>
> I heavily depend on the fact that source IPs of two distinct VMs do
> never match*.
>
> I noticed that in 3.0-rc1 dispvms do no longer have that property.
>
> Start a dispvm, kill it, start another, will result in the same dispvm
> ID and dispvm IP address.
>
> Is this a bug, or by design? Is it possible to change this behavior to
> match to one in R2 via a config change?
This was a desired change to get rid of global lock for dispvm counter.
DispVM was replaced by Qubes VM ID, which is assigned to all the VMs
anyway.
But I see your point. In addition to the IP problem, it gives some clue
about number of VMs in the system - QID is assigned to first unused
value, so if you see "disp16" it means you have at least 15 other VMs
(maybe more). Not sure how unique this value could be in generic case,
but I guess values like 128 are pretty unique...
If you don't have better ideas, indeed it looks like restoring R2
behaviour here is the best option.
> thanks,
> Joonas
>
> *) If the use case is relevant for you: The property is important
> because tor's isolation depends on the source IP when deciding whether
> something needs to go on a distinct circuit.
>
> btw: DispVM bootup in R3 is great - thanks for that!
Glad to hear :)
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVRXm4AAoJENuP0xzK19csKCsH/0ByFLBVtXlZ1J3IBx4kdq2r
lh7LKRKI7KKjsmapMj2PfvMSoPf/obM/EmVxUHbcwlYsh+kyWiyDTjw8/ufQA3rl
L3woABJCtwDBbgDslNEivui+G4XOt/ibcHX3DwZHpuE4ost3eCDX6SFTMZ3b3MPL
shCQVuQIa9wKZYrjdAJoB9uZwoBdiLB2I/XFnTwJQW1IdmmnUBxmMmHoUcqwSd6U
hHzg11xDTAdBWmFgrKOVGPhtKLA0xt84hn0q5iAndWsee/MLtI2czhtilvdDgkGz
7fOGonRTnQ0SNg6jwMPNilEhAqok2oKCKNMNWAGkVMzdlbY1yhie62gGa3hOzgY=
=yoSo
-----END PGP SIGNATURE-----
Hash: SHA1
On Sun, May 03, 2015 at 12:22:41AM +0000, Joonas Lehtonen wrote:
> Hi,
>
> I heavily depend on the fact that source IPs of two distinct VMs do
> never match*.
>
> I noticed that in 3.0-rc1 dispvms do no longer have that property.
>
> Start a dispvm, kill it, start another, will result in the same dispvm
> ID and dispvm IP address.
>
> Is this a bug, or by design? Is it possible to change this behavior to
> match to one in R2 via a config change?
DispVM was replaced by Qubes VM ID, which is assigned to all the VMs
anyway.
But I see your point. In addition to the IP problem, it gives some clue
about number of VMs in the system - QID is assigned to first unused
value, so if you see "disp16" it means you have at least 15 other VMs
(maybe more). Not sure how unique this value could be in generic case,
but I guess values like 128 are pretty unique...
If you don't have better ideas, indeed it looks like restoring R2
behaviour here is the best option.
> thanks,
> Joonas
>
> *) If the use case is relevant for you: The property is important
> because tor's isolation depends on the source IP when deciding whether
> something needs to go on a distinct circuit.
>
> btw: DispVM bootup in R3 is great - thanks for that!
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVRXm4AAoJENuP0xzK19csKCsH/0ByFLBVtXlZ1J3IBx4kdq2r
lh7LKRKI7KKjsmapMj2PfvMSoPf/obM/EmVxUHbcwlYsh+kyWiyDTjw8/ufQA3rl
L3woABJCtwDBbgDslNEivui+G4XOt/ibcHX3DwZHpuE4ost3eCDX6SFTMZ3b3MPL
shCQVuQIa9wKZYrjdAJoB9uZwoBdiLB2I/XFnTwJQW1IdmmnUBxmMmHoUcqwSd6U
hHzg11xDTAdBWmFgrKOVGPhtKLA0xt84hn0q5iAndWsee/MLtI2czhtilvdDgkGz
7fOGonRTnQ0SNg6jwMPNilEhAqok2oKCKNMNWAGkVMzdlbY1yhie62gGa3hOzgY=
=yoSo
-----END PGP SIGNATURE-----
Joonas Lehtonen
May 3, 2015, 4:29:13 AM5/3/15
to qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
>> I heavily depend on the fact that source IPs of two distinct VMs
>> do never match*.
>
>> I noticed that in 3.0-rc1 dispvms do no longer have that
>> property.
>
>> Start a dispvm, kill it, start another, will result in the same
>> dispvm ID and dispvm IP address.
>
>> Is this a bug, or by design? Is it possible to change this
>> behavior to match to one in R2 via a config change?
>
> This was a desired change to get rid of global lock for dispvm
> counter. DispVM was replaced by Qubes VM ID, which is assigned to
> all the VMs anyway.
>
> But I see your point. In addition to the IP problem, it gives some
> clue about number of VMs in the system - QID is assigned to first
> unused value, so if you see "disp16" it means you have at least 15
> other VMs (maybe more). Not sure how unique this value could be in
> generic case, but I guess values like 128 are pretty unique...
Thanks for explicitly mentioning this additional problem!
> If you don't have better ideas, indeed it looks like restoring R2
> behaviour here is the best option.
I opened a github issue for this.
https://github.com/QubesOS/qubes-issues/issues/983
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJVRdxOAAoJENGIB/ssoMC2koYP/ij10ctIPHiVetCfboFIzRqQ
9Yvz2kCp/oBIDYYtPO/DHN2E8p8Q+L4hcky4481KrvUJSb39saKtKloYlooZpTP8
q8+KhBe7YAB9SQZMBF3hIUg4L8rMTaldisGOZDiIuiLaZzb8uW9wJsLEDjr8Udfl
S/rpEDb3Xb35QtAWRU/e7zAvNeYHLxYurQugWhTCxL63rjsKLOSJ2idOPJeRv8/F
R72+/JjqgOf544q7EDZ4m96hhR2NJPXYuC1cqmHGAB9s0itek7vfC8AzFlO0kBn6
RSnIK5hD1y43+e/ot+qGtPWfv+LliwFZbhRwPulQus2Rg1Cf9Amp2QuZdysNiXr+
rZY2ACSfHXsxmbm0GB1Jq6+SEQQwQA+ahtyLzcNKchIdWxfrtCRd8d8RK0N6Ervw
hHZqhv+SnyvQe95Q4hJlagHSe57/9fT+KF3PNq8kK//bL9WUWhFlIBoS9fDS33Xy
Wl/kpkFNMSw9IajNBTDNIWWG7EWVASyyZEoy1TrKC2K9NuadNryZDcescy3Ejqvj
nUnhLpFBZ/cG+PQ6lfgGccPRS8DKymgAm2lizyh/Whc476C7uKJFicdwFWXLoNLj
p+9fcLvlP/nOmk2JTwMmuMhuNOIAD75/yJxXZjl6SeSXsd/fwdXdVHpjBUVs66tB
ZrCW70s1TQvg8fYjgKux
=UQv+
-----END PGP SIGNATURE-----
Hash: SHA512
>> I heavily depend on the fact that source IPs of two distinct VMs
>> do never match*.
>
>> I noticed that in 3.0-rc1 dispvms do no longer have that
>> property.
>
>> Start a dispvm, kill it, start another, will result in the same
>> dispvm ID and dispvm IP address.
>
>> Is this a bug, or by design? Is it possible to change this
>> behavior to match to one in R2 via a config change?
>
> This was a desired change to get rid of global lock for dispvm
> counter. DispVM was replaced by Qubes VM ID, which is assigned to
> all the VMs anyway.
>
> But I see your point. In addition to the IP problem, it gives some
> clue about number of VMs in the system - QID is assigned to first
> unused value, so if you see "disp16" it means you have at least 15
> other VMs (maybe more). Not sure how unique this value could be in
> generic case, but I guess values like 128 are pretty unique...
> If you don't have better ideas, indeed it looks like restoring R2
> behaviour here is the best option.
https://github.com/QubesOS/qubes-issues/issues/983
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJVRdxOAAoJENGIB/ssoMC2koYP/ij10ctIPHiVetCfboFIzRqQ
9Yvz2kCp/oBIDYYtPO/DHN2E8p8Q+L4hcky4481KrvUJSb39saKtKloYlooZpTP8
q8+KhBe7YAB9SQZMBF3hIUg4L8rMTaldisGOZDiIuiLaZzb8uW9wJsLEDjr8Udfl
S/rpEDb3Xb35QtAWRU/e7zAvNeYHLxYurQugWhTCxL63rjsKLOSJ2idOPJeRv8/F
R72+/JjqgOf544q7EDZ4m96hhR2NJPXYuC1cqmHGAB9s0itek7vfC8AzFlO0kBn6
RSnIK5hD1y43+e/ot+qGtPWfv+LliwFZbhRwPulQus2Rg1Cf9Amp2QuZdysNiXr+
rZY2ACSfHXsxmbm0GB1Jq6+SEQQwQA+ahtyLzcNKchIdWxfrtCRd8d8RK0N6Ervw
hHZqhv+SnyvQe95Q4hJlagHSe57/9fT+KF3PNq8kK//bL9WUWhFlIBoS9fDS33Xy
Wl/kpkFNMSw9IajNBTDNIWWG7EWVASyyZEoy1TrKC2K9NuadNryZDcescy3Ejqvj
nUnhLpFBZ/cG+PQ6lfgGccPRS8DKymgAm2lizyh/Whc476C7uKJFicdwFWXLoNLj
p+9fcLvlP/nOmk2JTwMmuMhuNOIAD75/yJxXZjl6SeSXsd/fwdXdVHpjBUVs66tB
ZrCW70s1TQvg8fYjgKux
=UQv+
-----END PGP SIGNATURE-----
Oleg Artemiev
May 6, 2015, 8:51:21 PM5/6/15
to Joonas Lehtonen, qubes...@googlegroups.com
On Sun, May 3, 2015 at 11:29 AM, Joonas Lehtonen
<joonas....@openmailbox.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
>>> I heavily depend on the fact that source IPs of two distinct VMs
>>> do never match*.
>>
>>> I noticed that in 3.0-rc1 dispvms do no longer have that
>>> property.
>>
>>> Start a dispvm, kill it, start another, will result in the same
>>> dispvm ID and dispvm IP address.
>>
>>> Is this a bug, or by design? Is it possible to change this
>>> behavior to match to one in R2 via a config change?
>>
>> This was a desired change to get rid of global lock for dispvm
>> counter. DispVM was replaced by Qubes VM ID, which is assigned to
>> all the VMs anyway.
>>
>> But I see your point. In addition to the IP problem, it gives some
>> clue about number of VMs in the system - QID is assigned to first
>> unused value, so if you see "disp16" it means you have at least 15
>> other VMs (maybe more). Not sure how unique this value could be in
>> generic case, but I guess values like 128 are pretty unique...
>
<joonas....@openmailbox.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
>>> I heavily depend on the fact that source IPs of two distinct VMs
>>> do never match*.
>>
>>> I noticed that in 3.0-rc1 dispvms do no longer have that
>>> property.
>>
>>> Start a dispvm, kill it, start another, will result in the same
>>> dispvm ID and dispvm IP address.
>>
>>> Is this a bug, or by design? Is it possible to change this
>>> behavior to match to one in R2 via a config change?
>>
>> This was a desired change to get rid of global lock for dispvm
>> counter. DispVM was replaced by Qubes VM ID, which is assigned to
>> all the VMs anyway.
>>
>> But I see your point. In addition to the IP problem, it gives some
>> clue about number of VMs in the system - QID is assigned to first
>> unused value, so if you see "disp16" it means you have at least 15
>> other VMs (maybe more). Not sure how unique this value could be in
>> generic case, but I guess values like 128 are pretty unique...
>
>> If you don't have better ideas, indeed it looks like restoring R2
>> behaviour here is the best option.
>
> I opened a github issue for this.
>
> https://github.com/QubesOS/qubes-issues/issues/983
Do they have voting on github? I'd bet that old way was better..
>> behaviour here is the best option.
>
> I opened a github issue for this.
>
> https://github.com/QubesOS/qubes-issues/issues/983
Joonas Lehtonen
May 7, 2015, 1:30:22 PM5/7/15
to qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hash: SHA512
>>> But I see your point. In addition to the IP problem, it gives
>>> some clue about number of VMs in the system - QID is assigned
>>> to first unused value, so if you see "disp16" it means you have
>>> at least 15 other VMs (maybe more). Not sure how unique this
>>> value could be in generic case, but I guess values like 128 are
>>> pretty unique...
>>
>>> If you don't have better ideas, indeed it looks like restoring
>>> R2 behaviour here is the best option.
>>
>> I opened a github issue for this.
>>
>> https://github.com/QubesOS/qubes-issues/issues/983
>
> Do they have voting on github? I'd bet that old way was better..
since this has already been addressed and released by marek in a very
>>> some clue about number of VMs in the system - QID is assigned
>>> to first unused value, so if you see "disp16" it means you have
>>> at least 15 other VMs (maybe more). Not sure how unique this
>>> value could be in generic case, but I guess values like 128 are
>>> pretty unique...
>>
>>> If you don't have better ideas, indeed it looks like restoring
>>> R2 behaviour here is the best option.
>>
>> I opened a github issue for this.
>>
>> https://github.com/QubesOS/qubes-issues/issues/983
>
> Do they have voting on github? I'd bet that old way was better..
short timeframe I'm not sure what 'old way' you actually mean.
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJVS6ElAAoJENGIB/ssoMC2EcoP/2VM5VRoPAJJpas+PdNuDvuI
fFw7AHBpePmgEce7oN/yYO55DZV55hns6Ip99KoGmgsbduqkNr6/nNnt/XVEgyS8
4ybPtFeD34DjNs/OAtvbw0gFaQIW8QmVP4j/Wal/p+Q7dWOKnG43cDuzlXIZ5hJq
pihNBZY/V6Zphpg4P15bGAaNlrhgKS4gkYmdisBSWdaF9Auldl8FrQ8U/SJB4LCW
zZuiSGJbFYIHVGdZxFybzerv5ohYxKZEdNIQZODbtDiPRNHaCwLga7kP19+mmHEt
beWY1myU/idmxgP8x0FNXQrq7WwFMA8jtFCCHvCixSZgnbWnc8RZwucVSDtjUYvW
rr0beWmFR5Dyf5Axh374SBSvF+e1cmFyjYQJFW70R66yN78CcokEDSMEE7FGRcCI
vCPf4lHKYUbKAPSFMxduDycLPuwhiivrsOh41085MIolI6zWV0HVqokq/KM+eoTo
2Rbv7rXrdgsc3pbD/IDqrHC4134ViKIfAVkIdUZduafILPwAM03F2f5Q/QGj+67z
jwDlUR7Q8qS7oOqHTNOMS8T+rd2/Wx0PHNh19qzSlgbXnZQWPnW8zmCHgH2S8Oys
KsWkfeArCqMxsHq6T2JNSP274PavGaMKgiBz3CfHFiogzuMPOPOExGgdnl8/CP5Z
6vtsJ+NYr2AwgveJxuwD
=isxI
-----END PGP SIGNATURE-----
Reply all
Reply to author
Forward
0 new messages