Re: [DNG] Meltdown and linux kernel KPTI patch

[Adam Borowski]

On Fri, Jan 05, 2018 at 01:30:13PM -0800, Rick Moen wrote:
> Quoting Renaud (Ron) OLGIATI (ren...@olgiati-in-paraguay.org):
> 
> > ISTR that AMDs are not affected by Meltdown, but affected by Spectre
> 
> _Possibly_.  Quoting the Meltdown FAQ:  'At the moment, it is unclear
> whether ARM and AMD processors are also affected by Meltdown.'
> https://meltdownattack.com/#faq

AMD engineers say none of their x86 CPUs are affected, as they check
permissions before speculating into.

A minority of ARM CPUs do suffer from Meltdown, see:
https://developer.arm.com/support/security-update
for details.  Variant 3 is Meltdown.  Among these, only Cortex-A75 is
affected by attacks believed to be exploitable.

Intel's PR campaign keeps saying everywhere that AMD is affected, but that's
a bold-faced lie that hinges on the fact that one of experimental processors
by AMD (ARM-based Opteron A) is Cortex-A57 which has variant 3a.


On the other hand, indeed AMD (all or almost all) are affected by Spectre.


Basically only in-order CPUs are free of Spectre.  Pinebook FTW!


Meow!
-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable And Non-Discriminatory prices.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Meltdown and linux kernel KPTI patch

[Rick Moen]

Quoting Renaud (Ron) OLGIATI (ren...@olgiati-in-paraguay.org):

> ISTR that AMDs are not affected by Meltdown, but affected by Spectre

_Possibly_.  Quoting the Meltdown FAQ:  'At the moment, it is unclear
whether ARM and AMD processors are also affected by Meltdown.'
https://meltdownattack.com/#faq

Section 6.4 of the Meltdown research paper gives details:

  We also tried to reproduce the Meltdown bug on several ARM and AMD
  CPUs. However, we did not manage to successfully leak kernel memory
  with the attack described in Section 5, neither on ARM nor on AMD. 
  The reasons for this can be manifold.  First of all, our implementation
  might simply be too slow and a more optimized version might succeed.
  For instance, a more shallow out-of-order execution pipeline could tip
  the race condition towards against the data leakage.  Similarly, if
  the processor lacks certain features, e.g., no re-order buffer, our
  current implementation might not be able to leak data.  However, for
  both ARM and AMD, the toy example as described in Section 3 works
  reliably, indicating that out-of-order execution generally occurs and
  instructions past illegal memory accesses are also performed.

https://meltdownattack.com/meltdown.pdf
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Meltdown and linux kernel KPTI patch

[Renaud (Ron) OLGIATI]

On Fri, 5 Jan 2018 21:52:48 +0100
viverna  wrote:

> When the KPTI patch will be in ascii and jessie?
> With AMD processor is possible to ignore patch?
> 
> According with:
> https://meltdownattack.com/
> "it is unclear whether ARM and AMD processors are
> also affected by Meltdown."
> and AMD wrote:
> https://www.amd.com/en/corporate/speculative-execution
> "Zero AMD vulnerability due to AMD architecture differences."

ISTR that AMDs are not affected by Meltdown, but affected by Spectre
 
Cheers,
 
Ron.
-- 
When we can't dream any longer we die.
   -- Emma Goldman

   -- http://www.olgiati-in-paraguay.org --
 
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Meltdown and linux kernel KPTI patch

[viverna]

When the KPTI patch will be in ascii and jessie?
With AMD processor is possible to ignore patch?

According with:
https://meltdownattack.com/
"it is unclear whether ARM and AMD processors are
also affected by Meltdown."
and AMD wrote:
https://www.amd.com/en/corporate/speculative-execution
"Zero AMD vulnerability due to AMD architecture differences."

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] initial elogind package ready / RFC

[Andreas Messer]

Hi there,

I finally managed to prepare inital devuan packages for elogind. 
I have split up the stuff in multiple packages, sysv init script
for elogind is prepared. Also a libpam-elogind package is build
which sets field "Provides: libpam-systemd". Thus I was able to 
install (and run) Gnome 3 Desktop (gnome-session) with skipping some 
"Recommends"

If anyone like to try it out, checkout branch suites/experimental
from https://git.devuan.org/amesser/elogind.git and build with 
debbuild. This is my first package, comments are welcome.

I have already found several issues with using it:

When using elogind, consolekit might not working anymore 
(ck-list-sessions is empty for me). Maybe this is an lightdm 
issue, for tty logins the session shows up in consolekit
and in loginctl.

The Shutdown/Reboot buttons and filesystem mounting 
neither work in KDE5 nor in Gnome 3. The mounting might be
related to udisks. I think we have to modify udisks package
to support elogind (instead of systemd). In Archlinux AUR there
is udisks2-elogind which has some patch included.

I have no clue about the power buttons, especially KDE5. Because
KDE already sayis in its console out, that it found logind.
When using loginctl from commandline I can halt/reboot the 
system. So its not a general problem of logind.

There are some things with package file structure which might 
be improved. I'm building elogind with the options recommended
in autogen.sh. But this implies that commands and libs are 
installed to /bin and /lib and some very obscure thing, elogind 
itself is installed to /lib/elogind/elogind. I suggest to install
it to /usr/bin, /usr/sbin and /usr/lib as usual and dropping that
weird /lib/elogind folder? Oppinions?

cheers,
Andreas
-- 
gnuPG keyid: 8C2BAF51
fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51


signature.asc
Description: PGP signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] request: please evaluate/provide elogind-or-other ASAP

[Andreas Messer]

On Fri, Jan 05, 2018 at 11:54:09AM +0100, Svante Signell wrote:
> On Fri, 2018-01-05 at 07:55 +0100, Andreas Messer wrote:
> > Hi Adam,
> > 
> > On Thu, Jan 04, 2018 at 11:44:25PM +0100, Adam Borowski wrote:
> > > [...]
> > > Thus: could you guys please prioritize work on elogind or some 
> > > alternative?
> > 
> > Just started yesterday: https://git.devuan.org/amesser/elogind. There was
> > already some work by shwsh but that seem to be stalled. (All the devuan
> > packet stuff is missing there as well.)
> > 
> > Depends on my time, but I think I will have a basic setup running with 
> > sysv init script within the next week. I have to sort out how to handle 
> > openrc
> > because this is a compile time setting in elogind. Maybe i have to build
> > different packages.
> 
> As I wrote on IRC I'm willing to help you with packagin of elogind. One
> confusing thing of elogind is that there exists three repos on github:

Sorry, din't see that. 
 
> https://github.com/elogind/elogind
> https://github.com/wingo/elogind
> https://github.com/shwsh/elogind
> Which one did you pull from?

The shwsh fork's changes have been merged back into elogind. I'm currently
using elogind as base, this is the original project and I think we should
go with it. I didn't look at other forks.

-- 
gnuPG keyid: 8C2BAF51
fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51


signature.asc
Description: PGP signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] request: please evaluate/provide elogind-or-other ASAP

[Irrwahn]

Irrwahn wrote on 05.01.2018 08:32:
[...]
> From https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394
> I gather that it is possible to configure this in sd-logind, 
> so I simply assume the same holds for elogind as well. 
> 
> However, in message #256 in that same thread Martin Steigerwald 
> asserts that this setting breaks shutdown (in the sense of not 
> behaving exactly the way it used to with sysvinit). Will elogind 
> suffer from the same regression, or will that issue be taken 
> care of?

After reading the elogind README once again, I think the following 
quote actually answers my question:

 +
 | For shutdown, reboot, and kexec, elogind shells out to "halt",
 | "reboot",and "kexec" binaries.
 +

AIUI, elogind calls "halt", which in turn would call "shutdown", 
which executes the equivalent of "init 0". Thus, assuming PID1 is 
SysV-init, the traditional behavior would be preserved, correct?

Urban
-- 
Sapere aude!
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] request: please evaluate/provide elogind-or-other ASAP

[Svante Signell]

On Fri, 2018-01-05 at 07:55 +0100, Andreas Messer wrote:
> Hi Adam,
> 
> On Thu, Jan 04, 2018 at 11:44:25PM +0100, Adam Borowski wrote:
> > [...]
> > Thus: could you guys please prioritize work on elogind or some alternative?
> 
> Just started yesterday: https://git.devuan.org/amesser/elogind. There was
> already some work by shwsh but that seem to be stalled. (All the devuan
> packet stuff is missing there as well.)
> 
> Depends on my time, but I think I will have a basic setup running with 
> sysv init script within the next week. I have to sort out how to handle openrc
> because this is a compile time setting in elogind. Maybe i have to build
> different packages.

As I wrote on IRC I'm willing to help you with packagin of elogind. One
confusing thing of elogind is that there exists three repos on github:

https://github.com/elogind/elogind
https://github.com/wingo/elogind
https://github.com/shwsh/elogind

Which one did you pull from?
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] request: please evaluate/provide elogind-or-other ASAP

[Andreas Messer]

On Fri, Jan 05, 2018 at 08:32:10AM +0100, Irrwahn wrote:
> [...] 
> Having that out of the way: First off, I appreciate any effort 
> made in that direction! However, I have one question I deem 
> important, namely: Will elogind display the same behavior as 
> systemd-logind regarding killing long running processes upon 
> user logout? IMNSHO it should not, i.e. it should follow the 
> principle of least surprise by not killing background user 
> processes on logout. 
> 
> From https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394
> I gather that it is possible to configure this in sd-logind, 
> so I simply assume the same holds for elogind as well. 

elogind has same behavior and configuration options as systemd's 
logind. So it has an option where this behavior can be enabled 
or disabled.

BUT: I had a short look into the source. It seems that the killing
is implemented by sending a dbus request to systemd to stop a unit.

I dont know if systemd-shim implement the StopUnit interface at 
all?

cheers,
Andreas
-- 
gnuPG keyid: 8C2BAF51
fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51


signature.asc
Description: PGP signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] request: please evaluate/provide elogind-or-other ASAP

[Adam Borowski]

On Fri, Jan 05, 2018 at 08:44:55AM +, KatolaZ wrote:
> On Fri, Jan 05, 2018 at 09:33:43AM +0100, Adam Borowski wrote:
> > Simon McVittie said:
> > 
> > # Now that we have versioned Provides,
> > # one way to achieve that might be for implementations of the logind API
> > # to add Provides: logind (= v) where v is the version of systemd whose
> > # logind API is implemented (currently 219 for elogind and 236 for systemd),
> > # and for depending packages to depend on
[...]
> > # default-logind | logind (>= v) (with default-logind
> > # provided by libpam-systemd on Debian)
> > 
> 
> That would definitely be a great solution, indeed. And would avoid a
> lot of useless work to Devuan and to other distros. In particular the
> latter proposal is very interesting, since it would allow a drop-in
> replacement of systemd-logind based on letting elogind Provides:
> default-logind
> 
> If there is anything we can do to support the inclusion of that
> Provides in Debian, please let us know.

Working elogind package[s], it seems.

Something fit for experimental would allow replacing dependencies in
individual packages that want logind.  And once that's tested, -shim could
be sent to a nice pasture.


Meow!
-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable And Non-Discriminatory prices.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Packaging problem with rxvt-unicode [was Re: ROXterm flickers in ascii]

[Adam Borowski]

On Fri, Jan 05, 2018 at 09:12:48AM +0100, Didier Kryn wrote:
> Le 02/01/2018 à 22:42, Dr. Nikolaus Klepp a écrit :
> > Terminator on ascii is 1.90 and depends on gtk3 - I was not very
> > surprised to find it not functional any more.  But Terminator from
> > jessie (0.97, gtk2) still works on ascii.
> > 
> > Anyway, nothing beats urxvt:-)
> 
>     In a fist try, I wasn't able to find urxvt on Ascii, but I got it today,
> simply searching for rxvt*. Stupid me!
> 
>     This terminal emulator is maybe the only one not depending on libvte,
> not speaking of libcairo, which several others depend on.

I'm afraid that you didn't look too closely -- there's not exactly a dearth
of terminal emulators (north of 50).  _Good_ terminal emulators might be
less plentiful, but everyone has their own opinion here.

>     There are several versions available on Ascii: rxvt-unicode,
> rxvt-unicode-256color, rxvt-unicode-lite. All 3 package are incompatible,
> but this incompatibility shows up in a bizarre way in Synaptic: when you
> select one for installation and another one is already installed, you are
> not prompted with the mesage that this other should be removed; instead the
> new package or both are marked as broken. I'm not expert in .deb, but there
> seems to be a mess in package dependencies.

A bug of this kind would be caught by automated piuparts testing, or
reported (with a RC severity) by a human, thus I'm quite certain there's
something else broken on your system.

This said, in buster/beowulf the mess of rxvt packages got culled literally
yesterday: there's only rxvt-unicode now which ships what used to be
rxvt-unicode-256color.  All the rest, including non-Unicode rxvt, aterm, etc
has been replaced with dummy packages depending on rxvt-unicode.

This was done for a number of reasons:
* a terminal that doesn't support UTF-8 is worthless.  I'm for one pushing
  for removal of encoding freedom, as there's no reason to use ancient
  encodings for a system locale anymore, and not supporting them saves a
  lot of code.
* non-256color variants used a non-standard color palette incompatible with
  any other terminal emulator.  There's no way to sniff the palette used,
  even assuming that "rxvt" means 88color would break on most other distros,
  and many terminals don't support setting your own palette.
* aterm's patches have been merged into rxvt-unicode ages ago
* variants other than rxvt-unicode have been dead upstream since forever


Meow!
-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable And Non-Discriminatory prices.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] request: please evaluate/provide elogind-or-other ASAP

[KatolaZ]

On Fri, Jan 05, 2018 at 09:33:43AM +0100, Adam Borowski wrote:

[cut]

> Simon McVittie said:
> 
> # It looks as though elogind is a fork of systemd-logind with reduced
> # functionality, no dependency on systemd as pid 1, and logind's D-Bus API
> # (so, basically systemd-shim done right), so it should be possible for
> # most of those to talk to elogind's logind-compatible API without code
> # changes (via libsystemd, even). Now that we have versioned Provides,
> # one way to achieve that might be for implementations of the logind API
> # to add Provides: logind (= v) where v is the version of systemd whose
> # logind API is implemented (currently 219 for elogind and 236 for systemd),
> # and for depending packages to depend on libpam-systemd (>= v) | logind
> # (>= v), or even on default-logind | logind (>= v) (with default-logind
> # provided by libpam-systemd on Debian) to be nice to anti-systemd
> # derivatives. Obviously >= v can be omitted if recent logind features
> # are not required.
> 
> which sounds like a good solution to me.
> 
> 

That would definitely be a great solution, indeed. And would avoid a
lot of useless work to Devuan and to other distros. In particular the
latter proposal is very interesting, since it would allow a drop-in
replacement of systemd-logind based on letting elogind Provides:
default-logind

If there is anything we can do to support the inclusion of that
Provides in Debian, please let us know.

Thanks

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


signature.asc
Description: Digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] request: please evaluate/provide elogind-or-other ASAP

[Adam Borowski]

On Fri, Jan 05, 2018 at 07:52:07AM +, KatolaZ wrote:
> elogind has been in Devuan's radar for quite a while, and I guess will
> become a priority just after ASCII gets out. I have not studied it in
> depth, but my understanding is that the most promising path would be
> to let it become a drop-in replacement to systemd-logind, e.g. by
> letting it Provides: SOMETHING. This is somwhow different from the
> case of udev/eudev since there is no independent Debian package (so
> far) for logind, and I don't know if there is a specific capability
> that can be used in a Provides: . Maybe you have a better knowledge on
> that.

Simon McVittie said:

# It looks as though elogind is a fork of systemd-logind with reduced
# functionality, no dependency on systemd as pid 1, and logind's D-Bus API
# (so, basically systemd-shim done right), so it should be possible for
# most of those to talk to elogind's logind-compatible API without code
# changes (via libsystemd, even). Now that we have versioned Provides,
# one way to achieve that might be for implementations of the logind API
# to add Provides: logind (= v) where v is the version of systemd whose
# logind API is implemented (currently 219 for elogind and 236 for systemd),
# and for depending packages to depend on libpam-systemd (>= v) | logind
# (>= v), or even on default-logind | logind (>= v) (with default-logind
# provided by libpam-systemd on Debian) to be nice to anti-systemd
# derivatives. Obviously >= v can be omitted if recent logind features
# are not required.

which sounds like a good solution to me.


Meow!
-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable And Non-Discriminatory prices.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Packaging problem with rxvt-unicode [was Re: ROXterm flickers in ascii]

[Didier Kryn]

Le 02/01/2018 à 22:42, Dr. Nikolaus Klepp a écrit :

Terminator on ascii is 1.90 and depends on gtk3 - I was not very surprised to 
find it not functional any more. But Terminator from jessie (0.97, gtk2) still 
works on ascii.

Anyway, nothing beats urxvt:-)

Nik


    In a fist try, I wasn't able to find urxvt on Ascii, but I got it 
today, simply searching for rxvt*. Stupid me!


    This terminal emulator is maybe the only one not depending on 
libvte, not speaking of libcairo, which several others depend on.


    There are several versions available on Ascii: rxvt-unicode, 
rxvt-unicode-256color, rxvt-unicode-lite. All 3 package are 
incompatible, but this incompatibility shows up in a bizarre way in 
Synaptic: when you select one for installation and another one is 
already installed, you are not prompted with the mesage that this other 
should be removed; instead the new package or both are marked as broken. 
I'm not expert in .deb, but there seems to be a mess in package 
dependencies.


        Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng