tor with --expensive-hardening is using way too much memory

tor with --expensive-hardening is using way too much memory

[ng0]

[-- Attachment #1: Type: text/plain, Size: 1706 bytes --]

I noticed this before the contribution entered master, so this message
is not really a news.

To quote myself from earlier today:

<ng0>      I think we should revert one piece of the tor hardened build.. 3 hours
           uptime: 684.3 MiB + 753.0 KiB = 685.1 MiB       tor

Comparison: my Chromium with 55 tabs open uses 2.2GB.

 Private  +   Shared  =  RAM used       Program
… 
 12.4 MiB +   1.1 MiB =  13.4 MiB       vim
 15.5 MiB + 959.0 KiB =  16.4 MiB       Xorg
 17.3 MiB +   5.6 MiB =  22.9 MiB       guix substitute
 22.8 MiB +   1.3 MiB =  24.1 MiB       shepherd
 26.7 MiB + 551.5 KiB =  27.3 MiB       emacs-25.2
131.1 MiB +   6.2 MiB = 137.3 MiB       .guix-real
732.7 MiB + 932.0 KiB = 733.6 MiB       tor
…
uptime: 6:24h

Now I wouldn't consider tor to be problematic when this would be the
default for tor. But it isn't, and --enable-expensive-hardening is an
experimental function which is not enabled by default from upstream (as
all our recently added config options for tor (not sure right now if all
are experimental, but they are not standard).

Comparison, Debian running for a very long time (months) and using the
same config:

 40.6 MiB + 486.0 KiB =  41.1 MiB       tor


I'm convinced that removing --enable-expensive-hardening will improve
the situation, I have watched an VM with tor without this config switch.
Whoever needs or wants this switch can make use of the easy way to
create custom packages in Guix.

If someone else can confirm my observations, I'll prepare an patch.
-- 
ng0
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://n0is.noblogs.org/my-keys
https://www.infotropique.org https://krosos.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: tor with --expensive-hardening is using way too much memory

[Kei Kebreau]

[-- Attachment #1: Type: text/plain, Size: 1823 bytes --]

ng0 <ng0@infotropique.org> writes:

> I noticed this before the contribution entered master, so this message
> is not really a news.
>
> To quote myself from earlier today:
>
> <ng0>      I think we should revert one piece of the tor hardened build.. 3 hours
>            uptime: 684.3 MiB + 753.0 KiB = 685.1 MiB       tor
>
> Comparison: my Chromium with 55 tabs open uses 2.2GB.
>
>  Private  +   Shared  =  RAM used       Program
> … 
>  12.4 MiB +   1.1 MiB =  13.4 MiB       vim
>  15.5 MiB + 959.0 KiB =  16.4 MiB       Xorg
>  17.3 MiB +   5.6 MiB =  22.9 MiB       guix substitute
>  22.8 MiB +   1.3 MiB =  24.1 MiB       shepherd
>  26.7 MiB + 551.5 KiB =  27.3 MiB       emacs-25.2
> 131.1 MiB +   6.2 MiB = 137.3 MiB       .guix-real
> 732.7 MiB + 932.0 KiB = 733.6 MiB       tor
> …
> uptime: 6:24h
>
> Now I wouldn't consider tor to be problematic when this would be the
> default for tor. But it isn't, and --enable-expensive-hardening is an
> experimental function which is not enabled by default from upstream (as
> all our recently added config options for tor (not sure right now if all
> are experimental, but they are not standard).
>
> Comparison, Debian running for a very long time (months) and using the
> same config:
>
>  40.6 MiB + 486.0 KiB =  41.1 MiB       tor
>
>
> I'm convinced that removing --enable-expensive-hardening will improve
> the situation, I have watched an VM with tor without this config switch.
> Whoever needs or wants this switch can make use of the easy way to
> create custom packages in Guix.
>
> If someone else can confirm my observations, I'll prepare an patch.

The top(1) command tells me that tor is taking up just short of a
gigabyte of RAM. I haven't tried disabling the --enable-expensive-hardening
flag, yet.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: tor with --expensive-hardening is using way too much memory

[ng0]

[-- Attachment #1: Type: text/plain, Size: 2221 bytes --]

I will prepare a patch and open a new bug at guix-patches, I see no one
in favor of keeping it the way it is.

Kei Kebreau transcribed 2.8K bytes:
> ng0 <ng0@infotropique.org> writes:
> 
> > I noticed this before the contribution entered master, so this message
> > is not really a news.
> >
> > To quote myself from earlier today:
> >
> > <ng0>      I think we should revert one piece of the tor hardened build.. 3 hours
> >            uptime: 684.3 MiB + 753.0 KiB = 685.1 MiB       tor
> >
> > Comparison: my Chromium with 55 tabs open uses 2.2GB.
> >
> >  Private  +   Shared  =  RAM used       Program
> > … 
> >  12.4 MiB +   1.1 MiB =  13.4 MiB       vim
> >  15.5 MiB + 959.0 KiB =  16.4 MiB       Xorg
> >  17.3 MiB +   5.6 MiB =  22.9 MiB       guix substitute
> >  22.8 MiB +   1.3 MiB =  24.1 MiB       shepherd
> >  26.7 MiB + 551.5 KiB =  27.3 MiB       emacs-25.2
> > 131.1 MiB +   6.2 MiB = 137.3 MiB       .guix-real
> > 732.7 MiB + 932.0 KiB = 733.6 MiB       tor
> > …
> > uptime: 6:24h
> >
> > Now I wouldn't consider tor to be problematic when this would be the
> > default for tor. But it isn't, and --enable-expensive-hardening is an
> > experimental function which is not enabled by default from upstream (as
> > all our recently added config options for tor (not sure right now if all
> > are experimental, but they are not standard).
> >
> > Comparison, Debian running for a very long time (months) and using the
> > same config:
> >
> >  40.6 MiB + 486.0 KiB =  41.1 MiB       tor
> >
> >
> > I'm convinced that removing --enable-expensive-hardening will improve
> > the situation, I have watched an VM with tor without this config switch.
> > Whoever needs or wants this switch can make use of the easy way to
> > create custom packages in Guix.
> >
> > If someone else can confirm my observations, I'll prepare an patch.
> 
> The top(1) command tells me that tor is taking up just short of a
> gigabyte of RAM. I haven't tried disabling the --enable-expensive-hardening
> flag, yet.



-- 
ng0
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://n0is.noblogs.org/my-keys
https://www.infotropique.org https://krosos.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]