Re: [qubes-devel] Re: qubes-url-redirector

[joeviocoe]

Thanks for the instructions.

At first it would not load as an unpacked extension because manifest.json 
and other references to polyfill.js.  Your git does not include polyfill.js.
So I got one from 
https://raw.githubusercontent.com/GoogleChrome/inert-polyfill/master/inert-polyfill.js

Now, several errors in the extension and the options won't save.

main.js:86 Uncaught ReferenceError: browser is not defined
at main.js:86
(anonymous) @ main.js:86
menus.js:22 Uncaught ReferenceError: browser is not defined
at createMenus (menus.js:22)
at menus.js:95
createMenus @ menus.js:22
(anonymous) @ menus.js:95
webRequest.js:35 Uncaught ReferenceError: browser is not defined
at webRequest.js:35



On Saturday, 14 October 2017 06:56:11 UTC-4, Raffaele Florio wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi,
> I've just uploaded the repo with installation istructions. Yeah I read 
> that method. However I don't consider it suitable for browsers, as you can 
> read from aforesaid motivations.
>
>
> Before update [0], if an user opens a whitelisted URL and the server 
> responds with a HTTP redirection request, the extension treats the 
> redirection according its rules. So it could be redirects to other VM. 
> However I don't consider this behavior good, because actually it doesn't 
> improve anything. After update [0] the extensions permits that type 
> redirection.
>
>
> [0] = 
> https://github.com/raffaeleflorio/qubes-url-redirector/commit/868718dcb0d482e5d20ba3d2752e93da765de45e
>
>
> Best,
> Raffaele.
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQIcBAEBCAAGBQJZ4e02AAoJEI08Rvun9XHutMkP/3lyK7VqzPgVLYvn9CjKGikw
> LMlmtNcsxKdw6c8CkeFcbSU/X6IWUcrkIB8OBOozCbHNbTpJtdtmxDn9KBoadyak
> oYXoq9XzqWyVV6jCaGWB6kEA5f2DM7FYbiajNCJnTTcpd63t/rw+FuZ7GK36QCqS
> 2SO4hFv3w6U7Ifcdd8dn23ou8CjRQzheML8i0ITzMCcFtXQwvbtL1sOPRLHoAevp
> nticJJ9U0XNvF9QbI8EX3V5dxmyjB0NQFwdpuU6l8ohmzVbOqIc/E96lZQZKStAa
> 11z/gnJnf5AkSZgtvymvtSvCM7EpFOMvCd7XZT+CqTjPe62mtv7kEeA0IjCBcL5A
> l9rfPxWBvaEi6LPZPOJ8unvsP8cjYS2xCaZ9k5oujJ7fStVx68cPDt3Y2Rr94peV
> CwMWqmgNX5WKLhT2i5UEoZzfp5FRNjBB77iMnbYXY6+GV29RVVRuppYaLomuzXsL
> JCWGAC2KHB8mvT0a928U+sNkRMCE5TMxyXIK6LPRPK9aOOM439YZWqIzTe4FdUYT
> 7/4zlc8q8rMbQxQDyEhAi0RabRG89lOvQRE38S0+gbmLxNDzyxSfu8MWlLKzIQwE
> 018Iqs3ah6/pH4o6u3DUBnObYRL8pLwAKLTLRzJtygTFGHKLG0xyNsVGnOPqBi/6
> MxmaMQn3kc0yDRWNmp4R
> =Lsmq
> -END PGP SIGNATURE-
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/7174c4cf-6741-4e79-b5fb-64af962186d3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] Re: Template's root volume partition table in Qubes 4.0

[Andrew Clausen]

Hi Leo,

On 14 October 2017 at 22:42, Leo Gaspard  wrote:

> On 10/14/2017 06:06 PM, Marek Marczykowski-Górecki wrote:> Changing it
> to have root filesystem at the end would ease resizing, but
> > may introduce compatibility issues explained before.
>
> Most likely a stupid / already thought of before idea, but... as, to
> migrate from Qubes 3.2 to Qubes 4.0, it will be required to make a
> backup and import from the backup... maybe just having the
> “import-from-backup” tool do the partition shuffling would be a simpler
> way to go than relying on the initramfs?
>

I think the problem we're trying to solve is about TemplateVMs.  Backups
are for AppVMs, not TemplateVMs.  Specifically, backups are for user data
(such as /home), which are stored on separate virtual disks.

Then, rc's for Qubes 4 are already quite far in the works, so maybe it
> is too late.
>

I think the issue is that the tools for building templates would need to be
adapted at the last minute.

Cheers,
Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/CAAXZBWLDpo_ogQZxpnDbvyOUYcwQrgh21tXTxwtdDdxFBS2w5g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] Re: Template's root volume partition table in Qubes 4.0

[Leo Gaspard]

On 10/14/2017 06:06 PM, Marek Marczykowski-Górecki wrote:> Changing it
to have root filesystem at the end would ease resizing, but
> may introduce compatibility issues explained before.

Most likely a stupid / already thought of before idea, but... as, to
migrate from Qubes 3.2 to Qubes 4.0, it will be required to make a
backup and import from the backup... maybe just having the
“import-from-backup” tool do the partition shuffling would be a simpler
way to go than relying on the initramfs?

Then, rc's for Qubes 4 are already quite far in the works, so maybe it
is too late.

Just my two cents,
Leo

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/e2bc3f2c-6c82-a103-f101-4128088ff5ef%40gaspard.io.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-devel] Re: Template's root volume partition table in Qubes 4.0

[Andrew Clausen]

Hi Marek,

On 14 October 2017 at 17:06, Marek Marczykowski-Górecki <
marma...@invisiblethingslab.com> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On Sat, Oct 14, 2017 at 04:29:30PM +0100, Andrew Clausen wrote:
> > Hi Marek,
> >
> > On 14 October 2017 at 15:45, Marek Marczykowski-Górecki <
> > marma...@invisiblethingslab.com> wrote:
> >
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA256
> > >
> > > On Sat, Oct 14, 2017 at 04:01:11PM +0200, Wojtek Porczyk wrote:
> > > > On Sat, Oct 14, 2017 at 03:36:05PM +0200, Marek Marczykowski-Górecki
> > > wrote:
> > > > > Thanks for the explanation.
> > > > > This should be enough for the online resize part. Now, back to the
> main
> > > > > issue here: partition to resize isn't the last one, one need to
> move
> > > two
> > > > > other partitions first. Hmm, maybe parted can do that too?
> > >
> >
> > It used to be able to.  However, when I retired from maintaining Parted,
> > the new maintainers removed support for resizing file systems.  (It's
> > fairly complicated code, and much less socially important now than when I
> > wrote it in the late 90s.)  After some protest, they added it back into
> > libparted, but it's still not available in the parted command-line tool.
> > There is another tool, fatresize, but this isn't very helpful because it
> > doesn't allow you to move the start of the partition.  I believe other
> > front-ends such as Parted Magic and GParted maintain the full
> > functionality, but probably not in a scriptable fashion.
>
> It's not about resizing those other partitions, it's about moving them.
>

Sorry for my esoteric choice of words... I think of moving is a special
case of resizing when the old and new locations don't overlap.  The modern
Parted command line tools can neither move nor resize, although all the
code to do so is still present inside inside libparted (for fat only).


> For resizing main filesystem resize2fs is enough.
>

Right.

> > Can't we change the partition order and add some compatibility to
> initrd?
> > > We
> > > > could support resizing only for "new" templates and leave the
> > > instruction to
> > > > resize older ones in documentation, with a big scary warning that
> it's
> > > better
> > > > to reinstall template than attempt manual resizing.
> > >
> > > This is exactly what this thread is about. The question is what would
> be
> > > more stable/less fragile - supporting two partition layouts, or
> resizing
> > > of the current layout. This question is especially tricky, because
> there
> > > are multiple ways how initrd is distributed:
> > >  - kernel provided by dom0 (so, dom0 package)
> > >  - kernel privided by VM (so, VM package)
> > >
> > > Those packages may be updated independently, and in case of kernel from
> > > dom0, may exists in multiple versions simultaneously. This may lead to
> > > "funny" effect that some templates will work only with some kernel
> > > versions. This may, or may not be a problem.
> > >
> >
> > I'm surprised there isn't a generic initrd standard to avoid this
> problem.
> > How disappointing!  For example, initrd could identify the system
> partition
> > by its name, not its location.
>
> There are few issues with using filesystem label there. The primary one
> is: it is ambiguous, because there are two things in AppVM:
>  - read-only base image, from VM template
>  - read-write copy-on-write image, assembled from the one above
>

Ah, I see.  Can't the AppVM's initrd change the label of the
copy-on-written file-system image?  For example, the original template
might be called "root", and the AppVM's private copy could be renamed to
"root-copy" during boot.  I think this can be implemented with tune2fs.
Whether you use partition labels or filesystem labels boils down to what is
more convenient, e.g. what is easier inside an initrd environment.

Granted, that before assembling the second one (which is done by initrd),
> there is only one. I haven't investigated _partition_ names available
> in GPT (as opposed to filesystem labels). Maybe that would be the way to
> go?
>

Yes, although I don't see how this is conceptually different from
filesystem labels.  (Neither seem to be a problem -- see above.)

Just to clarify the problem: in the long run, you are happy to require that
templates locate the root filesystem at the end of the virtual disk.  But
for now, you think it's too big a change for the imminent Qubes 4.0
release.  But you are willing to change the initramfs scripts for all
templates?  I'm just trying to understand which solutions are easiest for
you to implement.

> Some other options:
> >
> >  (1) Delete the old system partition, and create a new one by copying the
> > files across.  This should be fairly quick, because the system partition
> > shouldn't have much stuff on it, right?  (I doubt it would be slower than
> > libparted's resizer.)
>
> Up to 10GB, in default setup. resize2fs is sufficiently fast, no need to
> copy files. But to do 

Re: [qubes-devel] Re: Template's root volume partition table in Qubes 4.0

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sat, Oct 14, 2017 at 04:29:30PM +0100, Andrew Clausen wrote:
> Hi Marek,
> 
> On 14 October 2017 at 15:45, Marek Marczykowski-Górecki <
> marma...@invisiblethingslab.com> wrote:
> 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > On Sat, Oct 14, 2017 at 04:01:11PM +0200, Wojtek Porczyk wrote:
> > > On Sat, Oct 14, 2017 at 03:36:05PM +0200, Marek Marczykowski-Górecki
> > wrote:
> > > > Thanks for the explanation.
> > > > This should be enough for the online resize part. Now, back to the main
> > > > issue here: partition to resize isn't the last one, one need to move
> > two
> > > > other partitions first. Hmm, maybe parted can do that too?
> >
> 
> It used to be able to.  However, when I retired from maintaining Parted,
> the new maintainers removed support for resizing file systems.  (It's
> fairly complicated code, and much less socially important now than when I
> wrote it in the late 90s.)  After some protest, they added it back into
> libparted, but it's still not available in the parted command-line tool.
> There is another tool, fatresize, but this isn't very helpful because it
> doesn't allow you to move the start of the partition.  I believe other
> front-ends such as Parted Magic and GParted maintain the full
> functionality, but probably not in a scriptable fashion.

It's not about resizing those other partitions, it's about moving them.
For resizing main filesystem resize2fs is enough.

> I could write a small tool especially for Qubes, if you think this is the
> best solution.  But see below...
> 
> > Can't we change the partition order and add some compatibility to initrd?
> > We
> > > could support resizing only for "new" templates and leave the
> > instruction to
> > > resize older ones in documentation, with a big scary warning that it's
> > better
> > > to reinstall template than attempt manual resizing.
> >
> > This is exactly what this thread is about. The question is what would be
> > more stable/less fragile - supporting two partition layouts, or resizing
> > of the current layout. This question is especially tricky, because there
> > are multiple ways how initrd is distributed:
> >  - kernel provided by dom0 (so, dom0 package)
> >  - kernel privided by VM (so, VM package)
> >
> > Those packages may be updated independently, and in case of kernel from
> > dom0, may exists in multiple versions simultaneously. This may lead to
> > "funny" effect that some templates will work only with some kernel
> > versions. This may, or may not be a problem.
> >
> 
> I'm surprised there isn't a generic initrd standard to avoid this problem.
> How disappointing!  For example, initrd could identify the system partition
> by its name, not its location.

There are few issues with using filesystem label there. The primary one
is: it is ambiguous, because there are two things in AppVM:
 - read-only base image, from VM template
 - read-write copy-on-write image, assembled from the one above

Granted, that before assembling the second one (which is done by initrd),
there is only one. I haven't investigated _partition_ names available
in GPT (as opposed to filesystem labels). Maybe that would be the way to
go?

> Some other options:
> 
>  (1) Delete the old system partition, and create a new one by copying the
> files across.  This should be fairly quick, because the system partition
> shouldn't have much stuff on it, right?  (I doubt it would be slower than
> libparted's resizer.)

Up to 10GB, in default setup. resize2fs is sufficiently fast, no need to
copy files. But to do that, you need to resize the partition. And to
resize it, you need to move other two partitions further to the disk end
(in the current partition layout). Let me remind that current layout:

1. xvda1: root filesystem (almost all available space)
2. xvda2: EFI system partition (empty, prepared for PVHv2 boot with VM-provided 
kernel)
3. xvda3: BIOS boot (grub2 installed, used when `kernel=''`)

You don't need to move xvda1. Only xvda2 and xvda3, which are small
(about 200M total).

Changing it to have root filesystem at the end would ease resizing, but
may introduce compatibility issues explained before.

>  (2) Make the virtual hard disk very large (e.g. 100TB) but store it in a
> sparse format.  Put the system partition at the very end, so you never have
> to move it around.

Well, in dom0 it is stored as such (or on LVM thin volume - depending on
configuration). But the volume size is limited on purpose - otherwise
_any_ VM could easily fill the whole disk.

>  (3) Use LVM.
>
> I find option (2) most elegant.  The main difficulty would be: how do you
> enforce space limits?  I worry that an AppVM would have a copy-on-write
> view of the massive template image, and would be able to fill in the sparse
> holes to do a denial-of-service attack on the whole system.

Exactly. This is the reason why it is limited. Unfortunately most (all?)
copy-on-write schemes and sparse 

Re: [qubes-devel] Re: Template's root volume partition table in Qubes 4.0

[Andrew Clausen]

Hi Marek,

On 14 October 2017 at 15:45, Marek Marczykowski-Górecki <
marma...@invisiblethingslab.com> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On Sat, Oct 14, 2017 at 04:01:11PM +0200, Wojtek Porczyk wrote:
> > On Sat, Oct 14, 2017 at 03:36:05PM +0200, Marek Marczykowski-Górecki
> wrote:
> > > Thanks for the explanation.
> > > This should be enough for the online resize part. Now, back to the main
> > > issue here: partition to resize isn't the last one, one need to move
> two
> > > other partitions first. Hmm, maybe parted can do that too?
>

It used to be able to.  However, when I retired from maintaining Parted,
the new maintainers removed support for resizing file systems.  (It's
fairly complicated code, and much less socially important now than when I
wrote it in the late 90s.)  After some protest, they added it back into
libparted, but it's still not available in the parted command-line tool.
There is another tool, fatresize, but this isn't very helpful because it
doesn't allow you to move the start of the partition.  I believe other
front-ends such as Parted Magic and GParted maintain the full
functionality, but probably not in a scriptable fashion.

I could write a small tool especially for Qubes, if you think this is the
best solution.  But see below...

> Can't we change the partition order and add some compatibility to initrd?
> We
> > could support resizing only for "new" templates and leave the
> instruction to
> > resize older ones in documentation, with a big scary warning that it's
> better
> > to reinstall template than attempt manual resizing.
>
> This is exactly what this thread is about. The question is what would be
> more stable/less fragile - supporting two partition layouts, or resizing
> of the current layout. This question is especially tricky, because there
> are multiple ways how initrd is distributed:
>  - kernel provided by dom0 (so, dom0 package)
>  - kernel privided by VM (so, VM package)
>
> Those packages may be updated independently, and in case of kernel from
> dom0, may exists in multiple versions simultaneously. This may lead to
> "funny" effect that some templates will work only with some kernel
> versions. This may, or may not be a problem.
>

I'm surprised there isn't a generic initrd standard to avoid this problem.
How disappointing!  For example, initrd could identify the system partition
by its name, not its location.

Some other options:

 (1) Delete the old system partition, and create a new one by copying the
files across.  This should be fairly quick, because the system partition
shouldn't have much stuff on it, right?  (I doubt it would be slower than
libparted's resizer.)

 (2) Make the virtual hard disk very large (e.g. 100TB) but store it in a
sparse format.  Put the system partition at the very end, so you never have
to move it around.

 (3) Use LVM.

I find option (2) most elegant.  The main difficulty would be: how do you
enforce space limits?  I worry that an AppVM would have a copy-on-write
view of the massive template image, and would be able to fill in the sparse
holes to do a denial-of-service attack on the whole system.

Option (1) is probably quite easy to implement and most robust.

Cheers,
Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/CAAXZBWLAok1d60Ohk8BTo1k01EU1E68PT9CvjBtFwBuh4vx-6g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] Re: Template's root volume partition table in Qubes 4.0

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sat, Oct 14, 2017 at 04:01:11PM +0200, Wojtek Porczyk wrote:
> On Sat, Oct 14, 2017 at 03:36:05PM +0200, Marek Marczykowski-Górecki wrote:
> > Thanks for the explanation.
> > This should be enough for the online resize part. Now, back to the main
> > issue here: partition to resize isn't the last one, one need to move two
> > other partitions first. Hmm, maybe parted can do that too?
> 
> Can't we change the partition order and add some compatibility to initrd? We
> could support resizing only for "new" templates and leave the instruction to
> resize older ones in documentation, with a big scary warning that it's better
> to reinstall template than attempt manual resizing.

This is exactly what this thread is about. The question is what would be
more stable/less fragile - supporting two partition layouts, or resizing
of the current layout. This question is especially tricky, because there
are multiple ways how initrd is distributed:
 - kernel provided by dom0 (so, dom0 package)
 - kernel privided by VM (so, VM package)

Those packages may be updated independently, and in case of kernel from
dom0, may exists in multiple versions simultaneously. This may lead to
"funny" effect that some templates will work only with some kernel
versions. This may, or may not be a problem.

- -- 
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 v2

iQEcBAEBCAAGBQJZ4JG5AAoJENuP0xzK19csPvwH/Rusqx8OMH4iFqa+xcPOwxDL
EBv+PHHO7zg7PewCFSSriRuRNS8sniY0kaJz9mpBsAppd9Y6YALyB91qL3h13ZYJ
WYbzaGFRrZRtBrv+JwEGbEMPHW2CcBO4/3c31iiJGqB1vtva3oNAJ1Z0+e3I0JVU
mLDm7AgNNcrmjDwDTgReaqQawrKEbWEx9lbvVdqs71DZvQOS9GNEUWyxrcRSqe2D
h5lEW4umThbzZOkFXPCaxrOhVsp01jNWf5fZAw0hueaUMONcXtHkE7ge87HkQCIM
SrCBRayJRY6Ey9ZY/EeD0h0Ie3jvdyBJpeGTfVxkYtw7MJuXqfMvoUPG5fUg7jo=
=EI7D
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/20171014144529.GU1059%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] Re: Template's root volume partition table in Qubes 4.0

[Wojtek Porczyk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sat, Oct 14, 2017 at 03:36:05PM +0200, Marek Marczykowski-Górecki wrote:
> Thanks for the explanation.
> This should be enough for the online resize part. Now, back to the main
> issue here: partition to resize isn't the last one, one need to move two
> other partitions first. Hmm, maybe parted can do that too?

Can't we change the partition order and add some compatibility to initrd? We
could support resizing only for "new" templates and leave the instruction to
resize older ones in documentation, with a big scary warning that it's better
to reinstall template than attempt manual resizing.


- -- 
pozdrawiam / best regards   _.-._
Wojtek Porczyk   .-^'   '^-.
Invisible Things Lab |'-.-^-.-'|
 |  |   |  |
 I do not fear computers,|  '-.-'  |
 I fear lack of them.'-._ :  ,-'
-- Isaac Asimov `^-^-_>
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJZ4himAAoJEL9r2TIQOiNRKYgP/2SvBiuC5LNv+WbUOwT40m17
zwVMUzdsuYwhXoJd7sMTM/afWEE/UpuyPXgeScENNxFwkNN1O2moNDFsKo/vl+nj
SQocEWuPaXpN5DNdbbSoVyRLo+w6xXi3qNBfXIX13Q0zgVh6hCAn4QdbHh12xxqh
oeRCmsnw8pdXevbsn7S7beJpCkU2kV25HfShh5OHJWtSrNE1anSICqN5kqoe9K61
BsoM47AXmQZQULFFCHGS03YiWdCbNo5n79Bu0+bO5/A0YPBKzft1HK+R51+fNOLZ
iFYWmPBs7OrvsinH62lhvmIGlzjVo295DAd3xXCaUhgNIMjJ9MqSUIC0OADTmX3M
xElF4dvY3cd7ipCm97yFitt60ig83j8qWZqk2e7gXrsuoNgTzGF+STaRdFl5R0WB
cU7v+FWDVyOXhIQ9eEghagHa8YOMXfrj5rZsrQcF9TEhKi+NTA83zh7HO1TpyEA/
iAUeeZ0ak8RoAuFxtIxO6D05VFsqi+5zBR9lkXuSQt10emjlTuqfunNaT26S7G8B
7ZdbJbS5Iz9NwpI1+wPyIgCa90XQ7Do0prqLJDS5jKCuzXhqiJclzKfAZ2gG1qn4
uvaP7gYNBWSWgK9tQHyOnUi7E0eB4NjJhdBNZGNXeSKYqwK1EctCr2K8L6NkDc7h
FPWRJ0JZ+vhEFjZ/Fn7j
=xwUP
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/20171014140111.GH21553%40invisiblethingslab.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] Re: Template's root volume partition table in Qubes 4.0

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sat, Oct 14, 2017 at 05:42:39AM +0100, Andrew Clausen wrote:
> Hi all,
> 
> On 14 October 2017 at 01:20, Wojtek Porczyk 
> wrote:
> 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > On Sat, Oct 14, 2017 at 02:06:43AM +0200, Wojtek Porczyk wrote:
> > > On Sat, Oct 14, 2017 at 01:40:45AM +0200, Marek Marczykowski-Górecki
> > wrote:
> > > > On Sat, Oct 14, 2017 at 01:21:58AM +0200, Wojtek Porczyk wrote:
> > > > > On Sat, Oct 14, 2017 at 01:20:13AM +0200, Marek Marczykowski-Górecki
> > wrote:
> > > > > > You can't reload partition table while it is used (something from
> > there
> > > > > > is mounted). At least Linux doesn't support it.
> > > > >
> > > > > Just tested with loop device, fdisk, and ext4. Looks like it works.
> > Unless it
> > > > > works only with loop?
> > > >
> > > > No, it doesn't work, at least not directly:
> > > >
> >
> > (snip)
> >
> > > > The kernel still uses the old table. The new table will be used at
> > the next reboot or after you run partprobe(8) or kpartx(8).
> > > >
> > > > I wonder on what conditions partprobe would work. And how would mounted
> > > > filesystem react for it.
> > >
> > > I'm calling bullshit on that. Coredump follows:
> >
> > (...)
> >
> > > [root@qubes-dev tmp]# partprobe /dev/loop0
> > > [root@qubes-dev tmp]# echo $?
> > > 0
> >
> > (...)
> >
> > Look at strace of blockdev --rereadpt and partprobe. The difference is that
> > blockdev (and I assume fdisk also, since both are from util-linux) fires
> > ioctl(fd, BLKRRPART), but partprobe (from GNU parted) does something funny
> > to
> > /sys, which I didn't try to understand, but seems to work.
> >
> > My guess is that this is a missing feature in kernel, which parted works
> > around.
> >
> 
> I am a Qubes user, and coincidentally, the original author of partprobe
> (and parted).  I haven't looked at partprobe/parted since 2005.  The code
> has changed a lot since then, but let me do my best...
> 
> The BLKRRPART ioctl is no good because it can't accommodate busy block
> devices at all, i.e. resizing partition 1 when partition 2 on the same disk
> is mounted.
> 
> Instead, Parted primarily uses the BLKPG family of ioctl to inform the
> kernel of partition table changes.  (It also has "new" support for the
> device mapper -- but that's probably not relevant here.)  You can read
> about the BLKPG ioctl in /usr/include/linux/blkpg.h.  Since 2012, the linux
> kernel supports a new BLKPG feature to do online partition resizing, i.e.
> telling the kernel to modify a mounted partition.  I think this is what is
> being used here.
> 
> The relevant Parted code is in the function linux_disk_commit(), which
> calls _disk_sync_part_table() and _blkpg_resize_partition() inside
> http://git.savannah.gnu.org/cgit/parted.git/tree/libparted/arch/linux.c
> 
> If the BLKPG ioctl fails, then partprobe/parted will throw an exception and
> tell you about it.

Thanks for the explanation.
This should be enough for the online resize part. Now, back to the main
issue here: partition to resize isn't the last one, one need to move two
other partitions first. Hmm, maybe parted can do that too?

- -- 
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 v2

iQEcBAEBCAAGBQJZ4IF0AAoJENuP0xzK19csdS8H/1W/UsGDIIYtkOPr6tyvAYDM
vXPK8MD9pO8EUaYz2iAUJHJyn2crmF0JNiU++ZtAKpxU9QlTc+ZPgJ/2br2NaWKU
jJotIfgtEdJL6jOZjNhbZGb9gtQjalPx8fGj5CR2inxWvY1Q2Twj0yb/os4kdjSM
OtJEft8l5jTfu0GUOaOleohv4VTebQOc6s4Ea1rJvDYBWvj/JE1bOkRoBkk4A2EE
1cGOHLTJpuIjJWhE5prO9DtVB5ppQHTsm2VFslgHdxtO3CorEPnGaltNOZoARffS
yJRAr0FgxaT9KqMRTF0feZjs/DuYf9PzbfRvnBQKRc2p06ASzCLijgNBbgtlMVQ=
=iMtL
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/20171014133605.GR1059%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] Re: Template's root volume partition table in Qubes 4.0

[Wojtek Porczyk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sat, Oct 14, 2017 at 05:42:39AM +0100, Andrew Clausen wrote:
> Hi all,
> 
> On 14 October 2017 at 01:20, Wojtek Porczyk 
> wrote:
> 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > On Sat, Oct 14, 2017 at 02:06:43AM +0200, Wojtek Porczyk wrote:
> > > On Sat, Oct 14, 2017 at 01:40:45AM +0200, Marek Marczykowski-Górecki
> > wrote:
> > > > On Sat, Oct 14, 2017 at 01:21:58AM +0200, Wojtek Porczyk wrote:
> > > > > On Sat, Oct 14, 2017 at 01:20:13AM +0200, Marek Marczykowski-Górecki
> > wrote:
> > > > > > You can't reload partition table while it is used (something from
> > there
> > > > > > is mounted). At least Linux doesn't support it.
> > > > >
> > > > > Just tested with loop device, fdisk, and ext4. Looks like it works.
> > Unless it
> > > > > works only with loop?
> > > >
> > > > No, it doesn't work, at least not directly:
> > > >
> >
> > (snip)
> >
> > > > The kernel still uses the old table. The new table will be used at
> > the next reboot or after you run partprobe(8) or kpartx(8).
> > > >
> > > > I wonder on what conditions partprobe would work. And how would mounted
> > > > filesystem react for it.
> > >
> > > I'm calling bullshit on that. Coredump follows:
> >
> > (...)
> >
> > > [root@qubes-dev tmp]# partprobe /dev/loop0
> > > [root@qubes-dev tmp]# echo $?
> > > 0
> >
> > (...)
> >
> > Look at strace of blockdev --rereadpt and partprobe. The difference is that
> > blockdev (and I assume fdisk also, since both are from util-linux) fires
> > ioctl(fd, BLKRRPART), but partprobe (from GNU parted) does something funny
> > to
> > /sys, which I didn't try to understand, but seems to work.
> >
> > My guess is that this is a missing feature in kernel, which parted works
> > around.
> >
> 
> I am a Qubes user, and coincidentally, the original author of partprobe
> (and parted).  I haven't looked at partprobe/parted since 2005.  The code
> has changed a lot since then, but let me do my best...
> 
> The BLKRRPART ioctl is no good because it can't accommodate busy block
> devices at all, i.e. resizing partition 1 when partition 2 on the same disk
> is mounted.
> 
> Instead, Parted primarily uses the BLKPG family of ioctl to inform the
> kernel of partition table changes.  (It also has "new" support for the
> device mapper -- but that's probably not relevant here.)  You can read
> about the BLKPG ioctl in /usr/include/linux/blkpg.h.  Since 2012, the linux
> kernel supports a new BLKPG feature to do online partition resizing, i.e.
> telling the kernel to modify a mounted partition.  I think this is what is
> being used here.
> 
> The relevant Parted code is in the function linux_disk_commit(), which
> calls _disk_sync_part_table() and _blkpg_resize_partition() inside
> http://git.savannah.gnu.org/cgit/parted.git/tree/libparted/arch/linux.c
> 
> If the BLKPG ioctl fails, then partprobe/parted will throw an exception and
> tell you about it.

Thank you for your insight. I pasted the above to
https://github.com/QubesOS/qubes-issues/issues/3173#issuecomment-336635237.

> Wojtek: what part of your shell transcript was unexpected?  It looked like
> everything worked to me.

Yes, it did. The "bullshit" comment was in reply to Marek's statement about
supposed inability to reread partition table while any partition is mounted.
Well, as you point out, it can't be reloaded using BLKRRPART ioctl, which is
used by fdisk. Marek didn't use the partprobe, and he just took the error
message from fdisk at face value and concluded that we need to reboot.


- -- 
pozdrawiam / best regards   _.-._
Wojtek Porczyk   .-^'   '^-.
Invisible Things Lab |'-.-^-.-'|
 |  |   |  |
 I do not fear computers,|  '-.-'  |
 I fear lack of them.'-._ :  ,-'
-- Isaac Asimov `^-^-_>
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIbBAEBCAAGBQJZ4hJ6AAoJEL9r2TIQOiNRK+cP8QFb36PkY3+hmdlostS1Nqa2
QE1men8VxZmniwMtpUl9XRdWWYZpgsZy3OZ7M+WXncWQGzQNBk+3UIcJUC4chYS7
hR9rTLQpkV5g7fZmP8QCQukgG5SfJFhAcsBvl00WK+b7g46fIeaikWoQ2AgwZuTa
ZNnZLyJPOOp4W/93HxEkeQapgoe/arL+4R0F3SRnPloGI1bac8wHZUpPa5Y69hTO
+evN7Ibkt4VWkRlQm/rjKn6cF070B+VwThvxEvIbQtXc8dMnIifhxoGwjwYCWiWv
q7Tws0Fgqcjr/EaRGrj/pUtPPIJkIiqKg+w6p7mNUyZSm0Ro8eXm5Z4ywJCZjJ55
vC5Z8Nl/zOOcCOIDl2u8rqA5nKR9qN4B7+IgyR6dXzYgqvvRZaNBR/FVQeu5ETMC
VtuI6XgaRNeEC6EVRym+p4wh9ARIiw84QgJF0MJ8GgTXBHvNU10WroQTC68bCJNJ
gSEVHW8jNR5ccUAqvBDfgXcAx7iMEpfeJISXWd7uBYDgKZ1GxjHIJSG3LKWf+uZo
rLwU9IojN6+fu7akreyUEp+BQKAtJYZM29E3jJxAQRKkAPB0nQuIiaXx4K6uNbXZ
7oZLan4Ucnj6O0YI5Jm0RG40rXjLCDrEBaUL3xBf08g48x6kOtGw7rzE+PXHPSvl
g/Hgj6mlAQT1bgjxvE8=
=LFw9
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.

Re: [qubes-devel] Re: qubes-url-redirector

['Raffaele Florio' via qubes-devel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,
I've just uploaded the repo with installation istructions. Yeah I read that 
method. However I don't consider it suitable for browsers, as you can read from 
aforesaid motivations.

Before update [0], if an user opens a whitelisted URL and the server responds 
with a HTTP redirection request, the extension treats the redirection according 
its rules. So it could be redirects to other VM. However I don't consider this 
behavior good, because actually it doesn't improve anything. After update [0] 
the extensions permits that type redirection.

[0] = 
https://github.com/raffaeleflorio/qubes-url-redirector/commit/868718dcb0d482e5d20ba3d2752e93da765de45e

Best,
Raffaele.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJZ4e02AAoJEI08Rvun9XHutMkP/3lyK7VqzPgVLYvn9CjKGikw
LMlmtNcsxKdw6c8CkeFcbSU/X6IWUcrkIB8OBOozCbHNbTpJtdtmxDn9KBoadyak
oYXoq9XzqWyVV6jCaGWB6kEA5f2DM7FYbiajNCJnTTcpd63t/rw+FuZ7GK36QCqS
2SO4hFv3w6U7Ifcdd8dn23ou8CjRQzheML8i0ITzMCcFtXQwvbtL1sOPRLHoAevp
nticJJ9U0XNvF9QbI8EX3V5dxmyjB0NQFwdpuU6l8ohmzVbOqIc/E96lZQZKStAa
11z/gnJnf5AkSZgtvymvtSvCM7EpFOMvCd7XZT+CqTjPe62mtv7kEeA0IjCBcL5A
l9rfPxWBvaEi6LPZPOJ8unvsP8cjYS2xCaZ9k5oujJ7fStVx68cPDt3Y2Rr94peV
CwMWqmgNX5WKLhT2i5UEoZzfp5FRNjBB77iMnbYXY6+GV29RVVRuppYaLomuzXsL
JCWGAC2KHB8mvT0a928U+sNkRMCE5TMxyXIK6LPRPK9aOOM439YZWqIzTe4FdUYT
7/4zlc8q8rMbQxQDyEhAi0RabRG89lOvQRE38S0+gbmLxNDzyxSfu8MWlLKzIQwE
018Iqs3ah6/pH4o6u3DUBnObYRL8pLwAKLTLRzJtygTFGHKLG0xyNsVGnOPqBi/6
MxmaMQn3kc0yDRWNmp4R
=Lsmq
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/a-9LiWyRNL5k8a7ybd1ukUTsqroi-E1HpwBszHUTyWyn5OqnuB1qki_7VnwzwvsqZ4LJwgjZJa8evh73F6LClsLsiY7rzo-AXTWGPjwuXCo%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.