[prev in list] [next in list] [prev in thread] [next in thread]
List: qubes-devel
Subject: Re: [qubes-devel] Dom0 and processes.
From: drew.qubes () gmail ! com
Date: 2016-09-28 5:55:02
Message-ID: a869c9d7-cf17-44cc-be05-ee2881defd7c () googlegroups ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Wednesday, 28 September 2016 08:09:23 UTC+10, Marek Marczykowski-Górecki
wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Mon, Sep 26, 2016 at 06:35:10PM -0700, drew....@gmail.com <javascript:>
> wrote:
> > On Monday, 26 September 2016 19:38:05 UTC+10, Marek Marczykowski-Górecki
> > wrote:
> > > It is receiver - it receives icons from VM.
> > >
> >
> > Okay, so bear with me on this, maybe I'm just not understanding...
> >
> > You say it's a receiver.. It receives the icons from the VM...
> > The icons are already local to Dom0 via the app-menu synchronisation
> script.
> > So why is it that it needs this running all the time? You have the icons
> > locally, they need not be remote.
> > They are all in the .desktop files in the applications folder are they
> not?
>
> No, this is about different icon - not the one in the menu, but the one
> in window title bar. Application can place there any icon and even
> change it during runtime. For example my IM client has remote user
> avatar there.
>
so if I disable it, then it merely just can't change the icon from the
default that dom0 has set at first?
> > > > > > Why does it have a session id attached to it instead of just
> > > running?
> > > > >
> > > > > This is how desktop environment (KDE?) start applications. In case
> of
> > > > > qubes-manager it is ignored.
> > > > >
> > > >
> > > > 1. I've never seen KDE attach session IDs to processes. Nor any GUI
> in
> > > > Linux.
> > > > 2. I'm using xFCE
> > > > 3. The IDs were there in KDE as well.
> > >
> > > I think this is Qt/KDE thing. I've just tried with "konsole" and when
> it
> > > is restored as part of saved session (not closed on logoff), it also
> > > have "-session xxxxx" parameter.
> > >
> >
> > I have my own App Runner that I use that integrates with Qubes. I ahve
> my
> > own manager that I can use for basic tasks of starting stopping killing
> and
> > more. It uses Qt. Whether on KDE, XFCE or any other WM that I have ever
> > seen, I have NEVER had a "-session xxxxx" on it.
>
> Maybe it depends on some QtApplication object settings.
>
I run Qubes myself, not as a startup, and it has no session on it, no
session id, nothing like that. so it's something that someone at Qubes has
done to do it during boot. (or so I assume since it's been like that since
installation)
> > > > > > 3.
> > > > > > Why is there a
> > > > > > /usr/lib/qubes/qrexec-daemon
> > > > > > running for every virtual?
> > > > > > and a
> > > > > > /usr/sbin/qubesdb-daemon
> > > > > >
> > > > > > Will this be rectified instead of sitting there absorbing system
> > > > > resources
> > > > > > in a future update?
> > > > >
> > > > > No, those are intentionally separate processes (same as before -
> to
> > > make
> > > > > code simpler, which is very important in security critical
> > > components).
> > > > > Both of them together use about 1MB RAM, so it's negligible.
> > > > >
> > > >
> > > > how does it make code simpler? it's the same piece of code for the
> whole
> > > > thing. Multiple processes using identical code.
> > >
> > > Because a single process don't need to worry about message origin - it
> > > talks only to a single VM. No need to policy what should go where.
> > >
> >
> > While that makes sense, it's only a single switch and maybe 2 bytes of
> code
> > that have to be added in to any packet.
>
> It may look simple, but in practice it is not. There are many things in
> a single process that are shared - for example open files, shared memory
> and more. Handling multiple VMs in a single process means you need to
> take care to isolate those things. When having it in multiple processes
> - - operating system does the job for you.
>
Makes sense. Just a shame that they are using so much RAM each.
But that's how Python works since all the libraries that you are loading on
1 instance.
> > > > So if they use 1 MB ram in total, why doe I have 7 qrexec-daemons
> > > running
> > > > at over 2000 kb?
> > > > I also have 7 of the qubesdb-daemon running at over 2800 kb RAM
> usage.
> > >
> > > Still, this is negligible in comparison to 200+ MB per VM.
> > >
> >
> > Okay, look at it this way...
> >
> > If there are 3 per VM.. That's 10 MB per VM. (as a current maximum for
> > those 3 processes)
> > That means when I have 20 VMs started I have 20 MB RAM used. That means
> I
> > have 60 threads running that could all run at the same time causing the
> PC
> > to lag badly.
>
> Those processes _passively_ wait for VM (or dom0) requests.
>
But they are still using RAM, and a lot more than you thought.
So is this just meaning there is something wrong or???
> > If you worry about RAM usage, here is a hint: kill packagekitd in VMs.
> > > The service itself is disabled, but apparently something do start it
> > > from time to time. And it can use 30-50MB or even more.
> > >
> > > qvm-run --all -u root 'killall packagekitd'
> > >
> > >
> > If it was only 3 processes at <3 MB each for all VMs... Then it could
> just
> > receive the task, perform the action without hastle.
> >
> > So instead of adding in a case statement that just says it's this vm it
> is
> > this vms window/task/icon/whatever, you run multiple instances.
> >
> > It really would be simple and cleaner to add in the few lines of code (I
> > assume from what I have seen), rather than running so many processes
> > absorbing RAM and CPU time.
> >
> > At worst case, when it's needed to create another instance to do
> something,
> > it can just spawn a sub daemon that runs and dies.
>
> I think this approach could be used for window icons, as it mostly
> doesn't carry any state (so such "sub daemon" really could die after
> handling request).
> But not qrexec or qubesdb, which do hold some state.
>
> Anyway, probably wont happen anytime soon, unless someone (you?) send a
> patch.
>
What would it take for me to get a full code copy of the last version when
4 comes out and you stop advancing 3.*?
That way I can get a copy and build and all myself.
That way, NOT requiring the technology that is not in my PC, but version 4
will REQUIRE.
Then the older version can continue to advance and remain secure and stable
instead of becoming obsolete.
I think that qrexec could be changed too. they may hold a state, but they
can keep the state internally in maybe 10 bytes of RAM, instead of having
20 MB for separate processes. Since it's only there to pass commands from
dom0 to the virtual?
If the code was commented, I would be able to follow it and find all this
out instead of having to ask.
--
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+unsubscribe@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/a869c9d7-cf17-44cc-be05-ee2881defd7c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Attachment #5 (text/html)]
<div dir="ltr"><br><br>On Wednesday, 28 September 2016 08:09:23 UTC+10, Marek \
Marczykowski-Górecki wrote:<blockquote class="gmail_quote" style="margin: \
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">-----BEGIN PGP \
SIGNED MESSAGE----- <br>Hash: SHA256
<br>
<br>On Mon, Sep 26, 2016 at 06:35:10PM -0700, <a href="javascript:" target="_blank" \
gdf-obfuscated-mailto="9qYkFLsYAQAJ" rel="nofollow" \
onmousedown="this.href='javascript:';return true;" \
onclick="this.href='javascript:';return true;">drew....@gmail.com</a> wrote: \
<br>> On Monday, 26 September 2016 19:38:05 UTC+10, Marek Marczykowski-Górecki \
<br>> wrote: <br>> > It is receiver - it receives icons from VM.
<br>> >
<br>>
<br>> Okay, so bear with me on this, maybe I'm just not understanding...
<br>>
<br>> You say it's a receiver.. It receives the icons from the VM...
<br>> The icons are already local to Dom0 via the app-menu synchronisation script.
<br>> So why is it that it needs this running all the time? You have the icons
<br>> locally, they need not be remote.
<br>> They are all in the .desktop files in the applications folder are they not?
<br>
<br>No, this is about different icon - not the one in the menu, but the one
<br>in window title bar. Application can place there any icon and even
<br>change it during runtime. For example my IM client has remote user
<br>avatar there.
<br></blockquote><div><br>so if I disable it, then it merely just can't change \
the icon from the default that dom0 has set at first?<br><br> </div><blockquote \
class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc \
solid;padding-left: 1ex;">> > > > > Why does it have a session id \
attached to it instead of just <br>> > running?
<br>> > > >
<br>> > > > This is how desktop environment (KDE?) start applications. In \
case of <br>> > > > qubes-manager it is ignored.
<br>> > > >
<br>> > >
<br>> > > 1. I've never seen KDE attach session IDs to processes. Nor \
any GUI in <br>> > > Linux.
<br>> > > 2. I'm using xFCE
<br>> > > 3. The IDs were there in KDE as well.
<br>> >
<br>> > I think this is Qt/KDE thing. I've just tried with \
"konsole" and when it <br>> > is restored as part of saved session \
(not closed on logoff), it also <br>> > have "-session xxxxx" \
parameter. <br>> >
<br>>
<br>> I have my own App Runner that I use that integrates with Qubes. I ahve my
<br>> own manager that I can use for basic tasks of starting stopping killing and
<br>> more. It uses Qt. Whether on KDE, XFCE or any other WM that I have ever
<br>> seen, I have NEVER had a "-session xxxxx" on it.
<br>
<br>Maybe it depends on some QtApplication object settings.
<br></blockquote><div><br>I run Qubes myself, not as a startup, and it has no session \
on it, no session id, nothing like that. so it's something that someone at Qubes \
has done to do it during boot. (or so I assume since it's been like that since \
installation)<br> </div><blockquote class="gmail_quote" style="margin: \
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">> > > \
> > 3. <br>> > > > > Why is there a
<br>> > > > > /usr/lib/qubes/qrexec-daemon
<br>> > > > > running for every virtual?
<br>> > > > > and a
<br>> > > > > /usr/sbin/qubesdb-daemon
<br>> > > > >
<br>> > > > > Will this be rectified instead of sitting there \
absorbing system <br>> > > > resources
<br>> > > > > in a future update?
<br>> > > >
<br>> > > > No, those are intentionally separate processes (same as \
before - to <br>> > make
<br>> > > > code simpler, which is very important in security critical
<br>> > components).
<br>> > > > Both of them together use about 1MB RAM, so it's \
negligible. <br>> > > >
<br>> > >
<br>> > > how does it make code simpler? it's the same piece of code for \
the whole <br>> > > thing. Multiple processes using identical code.
<br>> >
<br>> > Because a single process don't need to worry about message origin - \
it <br>> > talks only to a single VM. No need to policy what should go where.
<br>> >
<br>>
<br>> While that makes sense, it's only a single switch and maybe 2 bytes of \
code <br>> that have to be added in to any packet.
<br>
<br>It may look simple, but in practice it is not. There are many things in
<br>a single process that are shared - for example open files, shared memory
<br>and more. Handling multiple VMs in a single process means you need to
<br>take care to isolate those things. When having it in multiple processes
<br>- - operating system does the job for you.
<br></blockquote><div><br>Makes sense. Just a shame that they are using so much RAM \
each.<br>But that's how Python works since all the libraries that you are loading \
on 1 instance.<br><br><br> </div><blockquote class="gmail_quote" style="margin: \
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">> > > \
So if they use 1 MB ram in total, why doe I have 7 qrexec-daemons <br>> > \
running <br>> > > at over 2000 kb?
<br>> > > I also have 7 of the qubesdb-daemon running at over 2800 kb RAM \
usage. <br>> >
<br>> > Still, this is negligible in comparison to 200+ MB per VM.
<br>> >
<br>>
<br>> Okay, look at it this way...
<br>>
<br>> If there are 3 per VM.. That's 10 MB per VM. (as a current maximum for
<br>> those 3 processes)
<br>> That means when I have 20 VMs started I have 20 MB RAM used. That means I
<br>> have 60 threads running that could all run at the same time causing the PC
<br>> to lag badly.
<br>
<br>Those processes _passively_ wait for VM (or dom0) requests.
<br></blockquote><div><br>But they are still using RAM, and a lot more than you \
thought.<br>So is this just meaning there is something wrong or???<br><br> \
</div><blockquote class="gmail_quote" style="margin: 0;margin-left: \
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">> If you worry about RAM \
usage, here is a hint: kill packagekitd in VMs. <br>> > The service itself is \
disabled, but apparently something do start it <br>> > from time to time. And \
it can use 30-50MB or even more. <br>> >
<br>> > qvm-run --all -u root 'killall packagekitd'
<br>> >
<br>> >
<br>> If it was only 3 processes at <3 MB each for all VMs... Then it could \
just <br>> receive the task, perform the action without hastle.
<br>>
<br>> So instead of adding in a case statement that just says it's this vm it \
is <br>> this vms window/task/icon/whatever, you run multiple instances.
<br>>
<br>> It really would be simple and cleaner to add in the few lines of code (I
<br>> assume from what I have seen), rather than running so many processes
<br>> absorbing RAM and CPU time.
<br>>
<br>> At worst case, when it's needed to create another instance to do \
something, <br>> it can just spawn a sub daemon that runs and dies.
<br>
<br>I think this approach could be used for window icons, as it mostly
<br>doesn't carry any state (so such "sub daemon" really could die \
after <br>handling request).
<br>But not qrexec or qubesdb, which do hold some state.
<br>
<br>Anyway, probably wont happen anytime soon, unless someone (you?) send a
<br>patch.
<br></blockquote><div><br>What would it take for me to get a full code copy of the \
last version when 4 comes out and you stop advancing 3.*?<br>That way I can get a \
copy and build and all myself.<br>That way, NOT requiring the technology that is not \
in my PC, but version 4 will REQUIRE.<br>Then the older version can continue to \
advance and remain secure and stable instead of becoming obsolete.<br><br>I think \
that qrexec could be changed too. they may hold a state, but they can keep the state \
internally in maybe 10 bytes of RAM, instead of having 20 MB for separate processes. \
Since it's only there to pass commands from dom0 to the virtual?<br><br>If the \
code was commented, I would be able to follow it and find all this out instead of \
having to ask.<br><br><br> </div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups \
"qubes-devel" group.<br /> To unsubscribe from this group and stop \
receiving emails from it, send an email to <a \
href="mailto:qubes-devel+unsubscribe@googlegroups.com">qubes-devel+unsubscribe@googlegroups.com</a>.<br \
/> To post to this group, send email to <a \
href="mailto:qubes-devel@googlegroups.com">qubes-devel@googlegroups.com</a>.<br /> To \
view this discussion on the web visit <a \
href="https://groups.google.com/d/msgid/qubes-devel/a869c9d7-cf17-44cc-be05-ee2881defd \
7c%40googlegroups.com?utm_medium=email&utm_source=footer">https://groups.google.com/d/ \
msgid/qubes-devel/a869c9d7-cf17-44cc-be05-ee2881defd7c%40googlegroups.com</a>.<br /> \
For more options, visit <a \
href="https://groups.google.com/d/optout">https://groups.google.com/d/optout</a>.<br \
/>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic