Re: [gentoo-user] Expect a ~15% average slowdown if you use an Intel processor

[Rich Freeman]

On Thu, Jan 4, 2018 at 9:22 PM, R0b0t1  wrote:
>
> I think referring to BPF is a red herring, because it is really the
> processor that is at fault. Not BPF. And yes, I'm aware of what AMD
> claims.

Of course the processor is at fault.  However, in order to exploit the
fault on an AMD processor you have to target a function running in the
correct priv level.  BPF JIT was a way to accomplish this on Linux,
because it can be made to run code.

If the kernel doesn't contain any susceptible code, then it can't be
exploited, because for Spectre to work part of the code has to run
with kernel privs.  Otherwise an AMD CPU will block the memory
accesses before they affect the cache.

The only exploit that works entirely with code in userspace is variant
3 (Meltdown), which is Intel-only, because Intel processors will
speculatively fetch data at the wrong priv level which affects the
cache (though the instruction will not retire).

I'm willing to believe that there could be other functions in the
kernel other than BPF which are also vulnerable, but which haven't
been discovered.  If somebody builds a compiler-level fix for this
then that could address the problem more completely.  I wouldn't be
surprised if they're discovering variants of this for a while.  Short
of disabling cache updates during speculative execution entirely I'm
not sure Spectre can be solved at the hardware level, and that
probably would have a big performance impact.


-- 
Rich

Re: [gentoo-user] Re: old kernels are installed during the upgrade

[Rich Freeman]

On Thu, Jan 4, 2018 at 9:12 PM, Walter Dnes  wrote:
>
>   There are 2 vulnerabities at play here, both caused by speculative
> execution...

Actually, there are 3 related ones, with two names between them.
Can't imagine why there is so much confusion...

> 2) "Spectre" is the reading, by one userland process, of memory
> belonging to another userland process.  Since this does not require
> jumping to kernel privilege level, AMD's ring-level permission checking
> is not invoked, and AMD cpus are vulnerable.  Think "cross-site-scripting
> on steroids", or "cross-process memory access" on your PC.

Spectre describes two variants.  It can be used from userland to
kernel, or between two userland processes.  However, it doesn't
require jumping priv levels - it is a side-channel leak.

Variant 1 requires that code be executed in the context of the process
being attacked.  So, there isn't a cross-priv issue here - just a
"skipped" bounds check.  When the out-of-bounds memory is accessed the
CPU sees that it is running in the correct priv level, which is
probably why AMD is vulnerable.

I'm a little hazy on variant 2, but I believe that this also requires
execution in the target context.  I suspect it doesn't run on AMD64
due to some details of how its CPUs actually work - it might not
speculatively do an indirect call, or it might not get far enough into
it to affect the cache.

>   This is a problem that's associated with "speculative execution".  I
> wonder how much of a performance hit it would be to turn off speculative
> execution.  That would probably require at least a microcode/firmware
> update, if not a new cpu.

Turning it off entirely would be a huge performance hit.  However,
Intel announced that they're going to add instructions to selectively
turn it off, presumably so that compilers can use this in situations
where Spectre is possible.  That will require a microcode change.  It
sounds like there are also workarounds.  For example, Intel suggests
doing an lfence after a bounds check to defeat variant 1, and I've
seen comments that suggest this works for some Intel users.  It
doesn't seem to work on my Phenom II or Ryzen 5.  Go figure, Intel
promoting an Intel-specific fix, though to be fair this is all rushed
and they might not even realize it doesn't work on AMD, or maybe I'm
doing it wrong.  (My code is at:
https://gist.github.com/rich0/056eebebc1f88a624e36680e0de36011 ).

-- 
Rich

Re: [gentoo-user] Expect a ~15% average slowdown if you use an Intel processor

[R0b0t1]

On Thu, Jan 4, 2018 at 10:18 AM, Rich Freeman  wrote:
> On Thu, Jan 4, 2018 at 10:44 AM, R0b0t1  wrote:
>>
>> I am still working through the information myself, but it looks like
>> BPF filters are an easy way to make sure you have something to look
>> for in kernelspace.
>
> My understanding is that for exploit 1 to work you need to have the
> kernel execute some code for you, and BPF is a way to do that because
> it is a JIT compiler.
>
> The bits about finding where BPF is in kernelspace is for exploit 2,
> which requires branching into that code, which requires knowing its
> address.
>

What I think is missing is the full details of the cache behavior,
because I saw some (ad hoc) proposals that the situation may be very,
very bad indeed. I'll see if I can find the explanation involving only
usermode code.

The original recommendation from CERT was to fully replace all
hardware: 
https://webcache.googleusercontent.com/search?q=cache:rzc6iQmgrIcJ:https://www.kb.cert.org/vuls/id/584653+=4=en=clnk=us

>> On Thu, Jan 4, 2018 at 9:44 AM, R0b0t1  wrote:
>>> But, if they do,
>>
>> then AMD processors are susceptible in the same way, and the issue can
>> not be fixed. There are some news pieces and commenters claiming that
>> AMD processors suffer similar issues.
>
> AMD published this:
> https://www.amd.com/en/corporate/speculative-execution
>
> This tends to go along with Google's statement that AMD is vulnerable
> to variant 1, but not 2 or 3.
>
> There is plenty of speculation going on with the hazy info that was
> provided, but none of the original sources suggest that AMD is
> vulnerable to variant 3.  For variants 1/2 Google says that AMD is
> susceptible to only 1, and the white paper says that they're
> vulnerable to either 1/2 but they don't say which specifically.
>
> In any case, short of somebody publishing actual exploit code so that
> people can run their own tests, I'm going to go with AMD.  Nobody
> reputable is outright contradicting their statements.  For variant 1
> the only known vulnerability is BPF which probably next to nobody
> uses, and for variant 2 there really aren't any alternatives available
> right now anyway.
>

I think referring to BPF is a red herring, because it is really the
processor that is at fault. Not BPF. And yes, I'm aware of what AMD
claims.

Cheers,
 R0b0t1

Re: [gentoo-user] Expect a ~15% average slowdown if you use an Intel processor

[Rich Freeman]

On Thu, Jan 4, 2018 at 8:52 PM, Jalus Bilieyich  wrote:
> Is my Pentium D from 2007 affected?
>

Any Intel x86 chip after and including the Pentium Pro should be
affected.  That came out in 1995.  The Pentium D is almost certainly
vulnerable.

-- 
Rich

Re: [gentoo-user] Re: old kernels are installed during the upgrade

[Walter Dnes]

On Thu, Jan 04, 2018 at 11:10:01AM -0500, Rich Freeman wrote
> On Thu, Jan 4, 2018 at 11:02 AM, Holger Hoffstätte
>  wrote:
> > On Wed, 03 Jan 2018 15:53:07 -0500, Rich Freeman wrote:
> >
> >> On Wed, Jan 3, 2018 at 3:35 PM, Wols Lists  
> >> wrote:
> >>>
> >>> And as I understand it the code can be disabled with either a compile
> >>> time option or command line switch to the kernel.
> >>
> >> I suspect the compile-time option is PAGE_TABLE_ISOLATION (which was
> >> newly added in 4.14.11).  The command line option nopti will disable
> >> it at runtime.
> >>
> >> Rumor has it that it will be disabled on AMD CPUs in 4.14.12, but I
> >
> > That's not a rumor and it can be easily verified either here:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-4.14/x86-cpu-x86-pti-do-not-enable-pti-on-amd-processors.patch
> >
> > or in mainline git, respectively.
> >
> 
> Not back when I made my post, as is evident from the timestamps.
> 
> All the info around these vulnerabilities is rapidly evolving, so take
> anything you hear with some skepticism until the dust settles...

  There are 2 vulnerabities at play here, both caused by speculative
execution...

1) "Meltdown" is the reading, by userland processes, of kernel memory.
This includes stuff like passwords, ssh and gpg keys, and other similar
sensitive stuff.  Intel is vulnerable; AMD is not, thanks to AMD's
ring-level permission checking.

2) "Spectre" is the reading, by one userland process, of memory
belonging to another userland process.  Since this does not require
jumping to kernel privilege level, AMD's ring-level permission checking
is not invoked, and AMD cpus are vulnerable.  Think "cross-site-scripting
on steroids", or "cross-process memory access" on your PC. 

  The most obvious attack vector would be web assembler or java plugin
or javascript, executing a 3rd-party ad in your browser.  By the way,
Adobe Flash is scripted by "Ecmascript", a variant of javascript.

  This is a problem that's associated with "speculative execution".  I
wonder how much of a performance hit it would be to turn off speculative
execution.  That would probably require at least a microcode/firmware
update, if not a new cpu.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] Expect a ~15% average slowdown if you use an Intel processor

[Jalus Bilieyich]

Is my Pentium D from 2007 affected?

On 01/03/2018 09:34 PM, Adam Carter wrote:
>>
>> Project Zero (Google) found it;
>> https://googleprojectzero.blogspot.com.au/2018/01/
>> reading-privileged-memory-with-side.html
>>
>> Phoronix has done some benchmarks on the impact of the kernel based
>> workaround ([Kernel] Page Table Isolation (PSI) nee Kaiser)
>> https://www.phoronix.com/scan.php?page=article=linux-
>> more-x86pti=1
>>
>>
> Re:AMD  - Looks like Linus agrees that PTI is not required for AMD CPUs.
> Note that the project zero blog mentions that some AMD chips are subject to
> some issues*. *There's three CVEs
> *.*
> 
> From:
> https://www.phoronix.com/scan.php?page=news_item=Linux-Tip-Git-Disable-x86-PTI
> *"Update:* Linus Torvalds has now ended up pulling
> 
> the latest PTI fixes that also include the change to disable page table
> isolation for now on all AMD CPUs. The commit is in mainline for Linux 4.15
> along with a few basic fixes and ensuring PAGE_TABLE_ISOLATION is enabled
> by default. "
> 

Re: [gentoo-user] Re: Expect a ~15% average slowdown if you use an Intel processor

[Adam Carter]

>
> The settings relevant to Spectre are:
> CONFIG_BPF_JIT - this being set to y is enough to make Intel
> processors vulnerable to variant 1/2.  This being set to y is
> necessary, but not sufficient, for making AMD vulnerable to variant 1.
> net.core.bpf_jit_enable - this being set to 1 along with the config
> option being set is sufficient to make AMD vulnerable to variant 1.
> This setting has no effect on making Intel vulnerable to variant 1 or
> 2.  I suspect this sysctl item won't appear unless it is loaded into
> the kernel in the first place.


Thanks for the clarification. I checked my three systemd systems and all
are;
# CONFIG_BPF_JIT is not set

systemd ebuild is looking for;
$ grep -i bpf /usr/portage/sys-apps/systemd/systemd-2*
/usr/portage/sys-apps/systemd/systemd-235-r1.ebuild:kernel_is -ge 4
10 && CONFIG_CHECK+=" ~CGROUP_BPF"
/usr/portage/sys-apps/systemd/systemd-236-r4.ebuild:kernel_is -ge 4
10 && CONFIG_CHECK+=" ~CGROUP_BPF"

Re: [gentoo-user] Re: Expect a ~15% average slowdown if you use an Intel processor

[Rich Freeman]

On Thu, Jan 4, 2018 at 7:51 PM, Adam Carter  wrote:
> On Fri, Jan 5, 2018 at 8:39 AM, Nikos Chantziaras  wrote:
>>
>> On 04/01/18 18:18, Rich Freeman wrote:
>>>
>>> For variant 1 the only known vulnerability is BPF which probably
>>> next to nobody uses
>>
>>
>> I had to enable various BPF settings in the kernel because systemd
>> wouldn't shut up about it. It prints warning messages during boot that the
>> system doesn't support BPF. After enabling it, systemd was happy and stopped
>> barking at me.
>>
>
> The vulnerability specifically mentions EBPF and JIT so I'd say its
> CONFIG_HAVE_EBPF_JIT, but there's also CONFIG_BPF_JIT.
>
> I notice EBPF_JIT is =y in my .config, grepping the sysctl -a output for bpf
> only returns;
> kernel.unprivileged_bpf_disabled = 0

The settings relevant to Spectre are:
CONFIG_BPF_JIT - this being set to y is enough to make Intel
processors vulnerable to variant 1/2.  This being set to y is
necessary, but not sufficient, for making AMD vulnerable to variant 1.
net.core.bpf_jit_enable - this being set to 1 along with the config
option being set is sufficient to make AMD vulnerable to variant 1.
This setting has no effect on making Intel vulnerable to variant 1 or
2.  I suspect this sysctl item won't appear unless it is loaded into
the kernel in the first place.

I believe CONFIG_HAVE_EBPF_JIT isn't actually modifiable via make
config - it is a dependency and I think it is there to indicate
whether the feature is supported (maybe it is arch-specific, or there
is some complex rule for it being available - I didn't dig through the
Makefiles).

I don't think either of these need to be set for systemd.  The
settings referenced in that issue are CONFIG_CGROUP_BPF and
CONFIG_BPF_SYSCALL.  I wouldn't be surprised if at some point BPF_JIT
gets patched to block Spectre, but that hasn't happened yet.

-- 
Rich

Re: [gentoo-user] Re: Expect a ~15% average slowdown if you use an Intel processor

[Adam Carter]

On Fri, Jan 5, 2018 at 8:39 AM, Nikos Chantziaras  wrote:

> On 04/01/18 18:18, Rich Freeman wrote:
>
>> For variant 1 the only known vulnerability is BPF which probably
>> next to nobody uses
>>
>
> I had to enable various BPF settings in the kernel because systemd
> wouldn't shut up about it. It prints warning messages during boot that the
> system doesn't support BPF. After enabling it, systemd was happy and
> stopped barking at me.
>
>
The vulnerability specifically mentions EBPF and JIT so I'd say its
CONFIG_HAVE_EBPF_JIT, but there's also CONFIG_BPF_JIT.

I notice EBPF_JIT is =y in my .config, grepping the sysctl -a output for
bpf only returns;
kernel.unprivileged_bpf_disabled = 0
And
https://github.com/linuxkit/linuxkit/commit/720fb219cea1fea99c2bba1d01f771eb43b2000b
"On 4.9.x and 4.14.x kernels ebpf verifier bugs allow ebpf programs to
access (read/write) random memory. Setting
kernel.unprivileged_bpf_disabled=1 mitigates this somewhat until it is
fixed upstream."

[gentoo-user] Re: Expect a ~15% average slowdown if you use an Intel processor

[Nikos Chantziaras]

On 04/01/18 23:39, Nikos Chantziaras wrote:

On 04/01/18 18:18, Rich Freeman wrote:

For variant 1 the only known vulnerability is BPF which probably
next to nobody uses


I had to enable various BPF settings in the kernel because systemd 
wouldn't shut up about it. It prints warning messages during boot that 
the system doesn't support BPF. After enabling it, systemd was happy and 
stopped barking at me.


https://github.com/systemd/systemd/issues/7188

[gentoo-user] Re: Expect a ~15% average slowdown if you use an Intel processor

[Nikos Chantziaras]

On 04/01/18 18:18, Rich Freeman wrote:

For variant 1 the only known vulnerability is BPF which probably
next to nobody uses


I had to enable various BPF settings in the kernel because systemd 
wouldn't shut up about it. It prints warning messages during boot that 
the system doesn't support BPF. After enabling it, systemd was happy and 
stopped barking at me.

Re: [gentoo-user] Re: Spectre and Meltdown summary

[Andrey F.]

Thanks for the great summary! Having 2FA enabled for all accounts will
go a long way as well.

On Thu, Jan 4, 2018 at 4:21 AM, Adam Carter  wrote:
> Browser stuff
>
> I'm guessing this relates to Variant1;
> @hackerfantastic "Blackhats will be weaponizing spectre to steal session
> cookies from additional websites opened in the browser, especially financial
> sites. Enable site isolation in Chrome now.
> https://support.google.com/chrome/answer/7623121?hl=en-GB;
>
> Sounds like Mozilla will make some changes in Firefox 57 to make the attacks
> more difficult;
> "Our internal experiments confirm that it is possible to use similar
> techniques from Web content to read private information"
> https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/
>

Re: [gentoo-user] Fail to configure polari and gnome-documents with portage. (SOLVED)

[Personal]

El jue, 04-01-2018 a las 12:04 -0600, Corbin Bird escribió:
> 
> On 01/04/2018 10:31 AM, Personal wrote:
> > Hi list.
> > 
> > I can't install polari and gnome-documents using portage. Using
> > ./configure by myself there is no problem. I post the polari
> > output:
> > ...
> 
> > I tested changing the PYTHON_TARGETS and PYTHON_SINGLE_TARGETS vars
> > with no success.
> > I think is something with gjs, python or meson but in the end I
> > can't
> > determinate and solve the problem.
> > The problem started after the change to 17 profile.
> > I asked on the web and the IRC channel with no success.
> > 
> > Thank you in advance.
> > 
> > -- 
> > Will 
>  be a stupid question 
> 
> If Profile 17 is the cause ... have you tried disabling both PIE /
> PIC
> for a test emerge?
> ( Both PIE / PIC gcc switches are enforced by Profile 17 )
> 
> Corbin

Thank you Corbin.

I finally found the solution.

The problem was that, for any cause, the user  can't access to
 some directory. So the solution was to unset the XDG_DATA_DIRS and
emerge again.

Thank you so much.

-- 
Will 

Re: [gentoo-user] Fail to configure polari and gnome-documents with portage.

[Corbin Bird]

On 01/04/2018 10:31 AM, Personal wrote:
> Hi list.
>
> I can't install polari and gnome-documents using portage. Using
> ./configure by myself there is no problem. I post the polari output:
>
 Emerging (1 of 1) net-irc/polari-3.22.2::gentoo
>  * polari-3.22.2.tar.xz BLAKE2B SHA512 size ;-)
> ...
>   [ ok ]
 Unpacking source...
 Unpacking polari-3.22.2.tar.xz to /var/tmp/portage/net-irc/polari-
> 3.22.2/work
 Source unpacked in /var/tmp/portage/net-irc/polari-3.22.2/work
 Preparing source in /var/tmp/portage/net-irc/polari-
> 3.22.2/work/polari-3.22.2 ...
>  * Disabling deprecation warnings
> ...
> [ ok ]
>  * Running elibtoolize in: polari-3.22.2/
>  *   Applying ppc64le/2.4.4 patch ...
>  * Running elibtoolize in: polari-3.22.2/build-aux/
>  *   Applying portage/1.2.0 patch ...
>  *   Applying sed/1.5.6 patch ...
>  *   Applying as-needed/2.4.3 patch ...
 Source prepared.
 Configuring source in /var/tmp/portage/net-irc/polari-
> 3.22.2/work/polari-3.22.2 ...
>  * econf: updating polari-3.22.2/build-aux/config.sub with
> /usr/share/gnuconfig/config.sub
>  * econf: updating polari-3.22.2/build-aux/config.guess with
> /usr/share/gnuconfig/config.guess
> ./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-
> linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --
> datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --
> disable-dependency-tracking --disable-silent-rules --
> docdir=/usr/share/doc/polari-3.22.2 --htmldir=/usr/share/doc/polari-
> 3.22.2/html --libdir=/usr/lib64 --disable-maintainer-mode --disable-
> schemas-compile --enable-compile-warnings=minimum
> checking for a BSD-compatible install...
> /usr/lib/portage/python2.7/ebuild-helpers/xattr/install -c
> checking whether build environment is sane... yes
> checking for a thread-safe mkdir -p... /bin/mkdir -p
> checking for gawk... gawk
> checking whether make sets $(MAKE)... yes
> checking whether make supports nested variables... yes
> checking whether UID '250' is supported by ustar format... yes
> checking whether GID '250' is supported by ustar format... yes
> checking how to create a ustar tar archive... gnutar
> checking whether make supports nested variables... (cached) yes
> checking whether to enable maintainer-specific portions of Makefiles...
> no
> checking for x86_64-pc-linux-gnu-pkg-config... /usr/bin/x86_64-pc-
> linux-gnu-pkg-config
> checking pkg-config is at least version 0.9.0... yes
> checking for gobject-introspection... yes
> checking whether to enable debugging... no
> checking for style of include used by make... GNU
> checking for x86_64-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc
> checking whether the C compiler works... yes
> checking for C compiler default output file name... a.out
> checking for suffix of executables... 
> checking whether we are cross compiling... no
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether x86_64-pc-linux-gnu-gcc accepts -g... yes
> checking for x86_64-pc-linux-gnu-gcc option to accept ISO C89... none
> needed
> checking whether x86_64-pc-linux-gnu-gcc understands -c and -o
> together... yes
> checking dependency style of x86_64-pc-linux-gnu-gcc... none
> checking how to run the C preprocessor... x86_64-pc-linux-gnu-gcc -E
> checking for grep that handles long lines and -e... /bin/grep
> checking for egrep... /bin/grep -E
> checking for ANSI C header files... yes
> checking for sys/types.h... yes
> checking for sys/stat.h... yes
> checking for stdlib.h... yes
> checking for string.h... yes
> checking for memory.h... yes
> checking for strings.h... yes
> checking for inttypes.h... yes
> checking for stdint.h... yes
> checking for unistd.h... yes
> checking minix/config.h usability... no
> checking minix/config.h presence... no
> checking for minix/config.h... no
> checking whether it is safe to define __EXTENSIONS__... yes
> checking for a sed that does not truncate output... /bin/sed
> checking whether C compiler accepts -Werror=unknown-warning-option...
> no
> checking whether C compiler accepts -fno-strict-aliasing... yes
> checking whether C compiler accepts -Wall... yes
> checking whether C compiler accepts -Wextra... yes
> checking whether C compiler accepts -Wundef... yes
> checking whether C compiler accepts -Wnested-externs... yes
> checking whether C compiler accepts -Wwrite-strings... yes
> checking whether C compiler accepts -Wpointer-arith... yes
> checking whether C compiler accepts -Wmissing-declarations... yes
> checking whether C compiler accepts -Wmissing-prototypes... yes
> checking whether C compiler accepts -Wstrict-prototypes... yes
> checking whether C compiler accepts -Wredundant-decls... 

Re: [gentoo-user] Spectre CPU flaws

[Andrey F.]

ALL CPUs are vulnerable to Spectre. The vuln described in your link is
Meltdown and only Intel is vulnerable to that.

https://meltdownattack.com

I don't believe there is a fix for Spectre, but it is also much tougher to
mount and attack. Meltdown on the other-hand has a fix that will likely
reduce performace, but only needs to be applied for Intel CPUs.

On Jan 4, 2018 01:46, "Mick"  wrote:

> On Thursday, 4 January 2018 05:50:59 GMT the...@sys-concept.com wrote:
> > New bug resurface.
> > What is the command to test AMD CUP's if flag: X86_BUG_CPU_INSECURE is
> > enabled?
> >
> > From:
> > https://lkml.org/lkml/2017/12/27/2
>
> grep bugs /proc/cpuinfo
>
> --
> Regards,
> Mick

[gentoo-user] Fail to configure polari and gnome-documents with portage.

[Personal]

Hi list.

I can't install polari and gnome-documents using portage. Using
./configure by myself there is no problem. I post the polari output:

>>> Emerging (1 of 1) net-irc/polari-3.22.2::gentoo
 * polari-3.22.2.tar.xz BLAKE2B SHA512 size ;-)
...
  [ ok ]
>>> Unpacking source...
>>> Unpacking polari-3.22.2.tar.xz to /var/tmp/portage/net-irc/polari-
3.22.2/work
>>> Source unpacked in /var/tmp/portage/net-irc/polari-3.22.2/work
>>> Preparing source in /var/tmp/portage/net-irc/polari-
3.22.2/work/polari-3.22.2 ...
 * Disabling deprecation warnings
...
[ ok ]
 * Running elibtoolize in: polari-3.22.2/
 *   Applying ppc64le/2.4.4 patch ...
 * Running elibtoolize in: polari-3.22.2/build-aux/
 *   Applying portage/1.2.0 patch ...
 *   Applying sed/1.5.6 patch ...
 *   Applying as-needed/2.4.3 patch ...
>>> Source prepared.
>>> Configuring source in /var/tmp/portage/net-irc/polari-
3.22.2/work/polari-3.22.2 ...
 * econf: updating polari-3.22.2/build-aux/config.sub with
/usr/share/gnuconfig/config.sub
 * econf: updating polari-3.22.2/build-aux/config.guess with
/usr/share/gnuconfig/config.guess
./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-
linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --
datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --
disable-dependency-tracking --disable-silent-rules --
docdir=/usr/share/doc/polari-3.22.2 --htmldir=/usr/share/doc/polari-
3.22.2/html --libdir=/usr/lib64 --disable-maintainer-mode --disable-
schemas-compile --enable-compile-warnings=minimum
checking for a BSD-compatible install...
/usr/lib/portage/python2.7/ebuild-helpers/xattr/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether UID '250' is supported by ustar format... yes
checking whether GID '250' is supported by ustar format... yes
checking how to create a ustar tar archive... gnutar
checking whether make supports nested variables... (cached) yes
checking whether to enable maintainer-specific portions of Makefiles...
no
checking for x86_64-pc-linux-gnu-pkg-config... /usr/bin/x86_64-pc-
linux-gnu-pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for gobject-introspection... yes
checking whether to enable debugging... no
checking for style of include used by make... GNU
checking for x86_64-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether x86_64-pc-linux-gnu-gcc accepts -g... yes
checking for x86_64-pc-linux-gnu-gcc option to accept ISO C89... none
needed
checking whether x86_64-pc-linux-gnu-gcc understands -c and -o
together... yes
checking dependency style of x86_64-pc-linux-gnu-gcc... none
checking how to run the C preprocessor... x86_64-pc-linux-gnu-gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking for a sed that does not truncate output... /bin/sed
checking whether C compiler accepts -Werror=unknown-warning-option...
no
checking whether C compiler accepts -fno-strict-aliasing... yes
checking whether C compiler accepts -Wall... yes
checking whether C compiler accepts -Wextra... yes
checking whether C compiler accepts -Wundef... yes
checking whether C compiler accepts -Wnested-externs... yes
checking whether C compiler accepts -Wwrite-strings... yes
checking whether C compiler accepts -Wpointer-arith... yes
checking whether C compiler accepts -Wmissing-declarations... yes
checking whether C compiler accepts -Wmissing-prototypes... yes
checking whether C compiler accepts -Wstrict-prototypes... yes
checking whether C compiler accepts -Wredundant-decls... yes
checking whether C compiler accepts -Wno-unused-parameter... yes
checking whether C compiler accepts -Wno-missing-field-initializers...
yes
checking whether C compiler accepts -Wdeclaration-after-statement...
yes
checking whether C 

Re: [gentoo-user] Expect a ~15% average slowdown if you use an Intel processor

[Rich Freeman]

On Thu, Jan 4, 2018 at 10:44 AM, R0b0t1  wrote:
>
> I am still working through the information myself, but it looks like
> BPF filters are an easy way to make sure you have something to look
> for in kernelspace.

My understanding is that for exploit 1 to work you need to have the
kernel execute some code for you, and BPF is a way to do that because
it is a JIT compiler.

The bits about finding where BPF is in kernelspace is for exploit 2,
which requires branching into that code, which requires knowing its
address.

> On Thu, Jan 4, 2018 at 9:44 AM, R0b0t1  wrote:
>> But, if they do,
>
> then AMD processors are susceptible in the same way, and the issue can
> not be fixed. There are some news pieces and commenters claiming that
> AMD processors suffer similar issues.

AMD published this:
https://www.amd.com/en/corporate/speculative-execution

This tends to go along with Google's statement that AMD is vulnerable
to variant 1, but not 2 or 3.

There is plenty of speculation going on with the hazy info that was
provided, but none of the original sources suggest that AMD is
vulnerable to variant 3.  For variants 1/2 Google says that AMD is
susceptible to only 1, and the white paper says that they're
vulnerable to either 1/2 but they don't say which specifically.

In any case, short of somebody publishing actual exploit code so that
people can run their own tests, I'm going to go with AMD.  Nobody
reputable is outright contradicting their statements.  For variant 1
the only known vulnerability is BPF which probably next to nobody
uses, and for variant 2 there really aren't any alternatives available
right now anyway.

-- 
Rich

Re: [gentoo-user] Re: old kernels are installed during the upgrade

[Rich Freeman]

On Thu, Jan 4, 2018 at 11:02 AM, Holger Hoffstätte
 wrote:
> On Wed, 03 Jan 2018 15:53:07 -0500, Rich Freeman wrote:
>
>> On Wed, Jan 3, 2018 at 3:35 PM, Wols Lists  wrote:
>>>
>>> And as I understand it the code can be disabled with either a compile
>>> time option or command line switch to the kernel.
>>
>> I suspect the compile-time option is PAGE_TABLE_ISOLATION (which was
>> newly added in 4.14.11).  The command line option nopti will disable
>> it at runtime.
>>
>> Rumor has it that it will be disabled on AMD CPUs in 4.14.12, but I
>
> That's not a rumor and it can be easily verified either here:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-4.14/x86-cpu-x86-pti-do-not-enable-pti-on-amd-processors.patch
>
> or in mainline git, respectively.
>

Not back when I made my post, as is evident from the timestamps.

All the info around these vulnerabilities is rapidly evolving, so take
anything you hear with some skepticism until the dust settles...

-- 
Rich

[gentoo-user] Re: old kernels are installed during the upgrade

[Holger Hoffstätte]

On Wed, 03 Jan 2018 15:53:07 -0500, Rich Freeman wrote:

> On Wed, Jan 3, 2018 at 3:35 PM, Wols Lists  wrote:
>>
>> And as I understand it the code can be disabled with either a compile
>> time option or command line switch to the kernel.
> 
> I suspect the compile-time option is PAGE_TABLE_ISOLATION (which was
> newly added in 4.14.11).  The command line option nopti will disable
> it at runtime.
> 
> Rumor has it that it will be disabled on AMD CPUs in 4.14.12, but I

That's not a rumor and it can be easily verified either here:

https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-4.14/x86-cpu-x86-pti-do-not-enable-pti-on-amd-processors.patch

or in mainline git, respectively.

-h

Re: [gentoo-user] Expect a ~15% average slowdown if you use an Intel processor

[R0b0t1]

On Thu, Jan 4, 2018 at 9:44 AM, R0b0t1  wrote:
> But, if they do,

then AMD processors are susceptible in the same way, and the issue can
not be fixed. There are some news pieces and commenters claiming that
AMD processors suffer similar issues.

Re: [gentoo-user] Expect a ~15% average slowdown if you use an Intel processor

[R0b0t1]

On Thu, Jan 4, 2018 at 8:17 AM, Rich Freeman  wrote:
> On Thu, Jan 4, 2018 at 8:44 AM, Corbin Bird  wrote:
>>
>> According to the Project Zero documentation  having BPF JIT enabled
>> is the key to the exploit.
>>
>> The way the docs read ... can it be assumed that by having BPF JIT
>> disabled on an AMD, that blocks this exploit?
>>
>
> I'm still working through the details, but AMD seems to only be
> vulnerable to variant 1 (based on AMD's reports), and for Linux that
> requires that BPF JIT be both built into the kernel (compile-time),
> and enabled in sysctl (net.core.bpf_jit_enable).  From what I can tell
> variant 1 requires that the vulnerable code actually be executed in
> the kernel security context.  I'm sure a fix to BPF will be made to
> close that.  There might also be some other code that can be tricked
> in the kernel but there are no reports of this.
>
> For variant 2 (not exploitable on AMD), it sounds like the BPF code
> need merely be present in kernel virtual memory while running in user
> security context.  That would mean that it would need to be built at
> compile-time, and loaded (if in a module), but it wouldn't have to be
> enabled in sysctl.  I didn't see any mention of it but I would think
> that the PTI fixes might close this hole on Intel, since then when the
> CPU is in user security context the BPF code would not be present in
> virtual memory.  Intel posted a separate compile-time fix to lkml
> yesterday as well, with an amusing response from Linus in his usual
> style, and an even more amusing subsequent joke about needing to add a
> perl interpreter to the kernel.
>
> Variant 1 does exploit CPU behavior, but I suspect it could be fixed
> with a change to gcc to recognize these kinds of indirect memory
> references and ensure they're not executed speculatively.  That fix
> would be applicable to anything that runs untrusted code in a sandbox,
> such as browsers.  That variant isn't about crossing CPU privilege
> boundaries so much as getting code that is legitimately being run to
> leak state through the cache as a backchannel.
>
> Note: I'm not an expert on any of this stuff, and if somebody wants to
> chime in with details/adjustments to the above I'm all ears.
>

I think this is missing the point - this specific attack may be tied
to BPF, but disabling BPF does not remove the underlying cause, which
is speculatively executed instructions modifying the processor state.
When news pieces are claiming that there is no way to fix this problem
save changing the hardware or taking a huge execution penalty they are
right.

I am still working through the information myself, but it looks like
BPF filters are an easy way to make sure you have something to look
for in kernelspace. Since you have something to look for, you can then
start asking yes or no questions about what is in cache that is
mirroring kernelspace memory. Once you find it, you can start to look
for other kernel structures that may contain more interesting
information (private keys), and then ask questions like "are the bytes
of the private key at position X equal to Y?" Eventually, you can read
arbitrary memory.

There are pieces claiming the details of the full attack allows
writing to kernel memory, and I suspect it is far easier in practice
to do the things detailed above. If AMD is not susceptible to one of
the attacks, that is because speculatively executed instructions do
not update the cache. But, if they do,

It is likely we will need to wait for the full details to be released
once the problem is addressed in secret.

Cheers,
 R0b0t1

Re: [gentoo-user] Expect a ~15% average slowdown if you use an Intel processor

[Corbin Bird]

On 01/04/2018 08:17 AM, Rich Freeman wrote:
> On Thu, Jan 4, 2018 at 8:44 AM, Corbin Bird  wrote:
>> According to the Project Zero documentation  having BPF JIT enabled
>> is the key to the exploit.
>>
>> The way the docs read ... can it be assumed that by having BPF JIT
>> disabled on an AMD, that blocks this exploit?
>>
> I'm still working through the details, but AMD seems to only be
> vulnerable to variant 1 (based on AMD's reports), and for Linux that
> requires that BPF JIT be both built into the kernel (compile-time),
> and enabled in sysctl (net.core.bpf_jit_enable).  From what I can tell
> variant 1 requires that the vulnerable code actually be executed in
> the kernel security context.  I'm sure a fix to BPF will be made to
> close that.  There might also be some other code that can be tricked
> in the kernel but there are no reports of this.
>
> For variant 2 (not exploitable on AMD), it sounds like the BPF code
> need merely be present in kernel virtual memory while running in user
> security context.  That would mean that it would need to be built at
> compile-time, and loaded (if in a module), but it wouldn't have to be
> enabled in sysctl.  I didn't see any mention of it but I would think
> that the PTI fixes might close this hole on Intel, since then when the
> CPU is in user security context the BPF code would not be present in
> virtual memory.  Intel posted a separate compile-time fix to lkml
> yesterday as well, with an amusing response from Linus in his usual
> style, and an even more amusing subsequent joke about needing to add a
> perl interpreter to the kernel.
>
> Variant 1 does exploit CPU behavior, but I suspect it could be fixed
> with a change to gcc to recognize these kinds of indirect memory
> references and ensure they're not executed speculatively.  That fix
> would be applicable to anything that runs untrusted code in a sandbox,
> such as browsers.  That variant isn't about crossing CPU privilege
> boundaries so much as getting code that is legitimately being run to
> leak state through the cache as a backchannel.
>
> Note: I'm not an expert on any of this stuff, and if somebody wants to
> chime in with details/adjustments to the above I'm all ears.
>

So  kill all BPF JIT support / leave BPF JIT out of the kernel / no
kernel modules either == attack Variant #1 fails.
The "current workaround" ( for AMD CPU's ) is how I read it.

Thanks for the info.

Corbin

Re: [gentoo-user] Expect a ~15% average slowdown if you use an Intel processor

[Rich Freeman]

On Thu, Jan 4, 2018 at 8:44 AM, Corbin Bird  wrote:
>
> According to the Project Zero documentation  having BPF JIT enabled
> is the key to the exploit.
>
> The way the docs read ... can it be assumed that by having BPF JIT
> disabled on an AMD, that blocks this exploit?
>

I'm still working through the details, but AMD seems to only be
vulnerable to variant 1 (based on AMD's reports), and for Linux that
requires that BPF JIT be both built into the kernel (compile-time),
and enabled in sysctl (net.core.bpf_jit_enable).  From what I can tell
variant 1 requires that the vulnerable code actually be executed in
the kernel security context.  I'm sure a fix to BPF will be made to
close that.  There might also be some other code that can be tricked
in the kernel but there are no reports of this.

For variant 2 (not exploitable on AMD), it sounds like the BPF code
need merely be present in kernel virtual memory while running in user
security context.  That would mean that it would need to be built at
compile-time, and loaded (if in a module), but it wouldn't have to be
enabled in sysctl.  I didn't see any mention of it but I would think
that the PTI fixes might close this hole on Intel, since then when the
CPU is in user security context the BPF code would not be present in
virtual memory.  Intel posted a separate compile-time fix to lkml
yesterday as well, with an amusing response from Linus in his usual
style, and an even more amusing subsequent joke about needing to add a
perl interpreter to the kernel.

Variant 1 does exploit CPU behavior, but I suspect it could be fixed
with a change to gcc to recognize these kinds of indirect memory
references and ensure they're not executed speculatively.  That fix
would be applicable to anything that runs untrusted code in a sandbox,
such as browsers.  That variant isn't about crossing CPU privilege
boundaries so much as getting code that is legitimately being run to
leak state through the cache as a backchannel.

Note: I'm not an expert on any of this stuff, and if somebody wants to
chime in with details/adjustments to the above I'm all ears.

-- 
Rich

[gentoo-user] Switching from Seamonkey to Firefox and Thunderbird

[Dale]

Howdy,

I have been using Seamonkey as my main web browser and email program for
many years.  Thing is, some sites either don't work right or won't load
at all.  Those same sites work fine in Firefox.  Just the other day,
LastPass started acting weird and I had to remove it.  My plan was to
remove it and then reinstall it, hopefully with a newer version or it
would fix some weird corruption problem.  Well, Seamonkey is no longer
supported.  It won't install at all now. 

Given some of the problems, one recent and some long term, I'm thinking
of switching to Thunderbird and Firefox and removing Seamonkey
completely.  I'm not concerned with Firefox as my browser as I do use it
for certain things.  I know I can export and import my bookmarks and
such and it should be easy.  My concern is moving my emails from
Seamonkey to Thunderbird.  I have tens of thousands of emails going back
a long ways.  I've googled and haven't been able to find anything
recent that talks about doing this.  I suspect it will be easy, either a
export and import or just a hand copy from Seamonkey to Thunderbird.  It
may be that it would use the same directory Seamonkey uses and just
works.  That said, I'd like to see if anyone has done this in say the
past year or so since that should work the same, barring some huge
change I'm not aware of. 

Has anyone moved from Seamonkey to Thunderbird recently?  Anyone know of
a howto that I missed?  Anyone know of a reason this just won't work?

Thanks much. 

Dale

:-)  :-) 

Re: [gentoo-user] Expect a ~15% average slowdown if you use an Intel processor

[Corbin Bird]

On 01/03/2018 09:34 PM, Adam Carter wrote:
>
> Project Zero (Google) found it;
> 
> https://googleprojectzero.blogspot.com.au/2018/01/reading-privileged-memory-with-side.html
> 
> 
>
>
> Phoronix has done some benchmarks on the impact of the kernel
> based workaround ([Kernel] Page Table Isolation (PSI) nee Kaiser)
> 
> https://www.phoronix.com/scan.php?page=article=linux-more-x86pti=1
> 
> 
>
>
> *
> *
> Re:AMD  - Looks like Linus agrees that PTI is not required for AMD
> CPUs. Note that the project zero blog mentions that some AMD chips are
> subject to some issues*. *There's three CVEs*.
> *
> *
> *
> From:
> https://www.phoronix.com/scan.php?page=news_item=Linux-Tip-Git-Disable-x86-PTI*
> *
> *"Update:* Linus Torvalds has now ended up pulling
> 
> the latest PTI fixes that also include the change to disable page
> table isolation for now on all AMD CPUs. The commit is in mainline for
> Linux 4.15 along with a few basic fixes and ensuring
> PAGE_TABLE_ISOLATION is enabled by default. "

According to the Project Zero documentation  having BPF JIT enabled
is the key to the exploit.

The way the docs read ... can it be assumed that by having BPF JIT
disabled on an AMD, that blocks this exploit?

Corbin

[gentoo-user] Re: Spectre and Meltdown summary

[Adam Carter]

Browser stuff

I'm guessing this relates to Variant1;
@hackerfantastic "Blackhats will be weaponizing spectre to steal session
cookies from additional websites opened in the browser, especially
financial sites. Enable site isolation in Chrome now.
https://support.google.com/chrome/answer/7623121?hl=en-GB;

Sounds like Mozilla will make some changes in Firefox 57 to make the
attacks more difficult;
"Our internal experiments confirm that it is possible to use similar
techniques from Web content to read private information"
https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/

[gentoo-user] Spectre and Meltdown summary

[Adam Carter]

No guarantees on accuracy...

Meltdown CVE-2017-5754 (Variant3) - userspace reads kernel memory. Intel
vulnerable, AMD not vulnerable. Issue is mitigated with KPTI (in kernel
4.14.11, Security Options -> Remove the kernel mapping in user mode
(CONFIG_PAGE_TABLE_ISOLATION), on by default for all archs in this version,
disabled by default for AMD CPUs in git 4.15). KPTI incurs a performance
hit.

Spectre CVE-2017-5753 (Variant1) and CVE-2017-5715 (Variant2) -
applications read other applications memory. Intel, AMD, ARM all
vulnerable.
Re Variant1, AMD says "Resolved by software / OS updates to be made
available by system vendors and manufacturers. Negligible performance
impact expected."
Re Variant2, AMD says "Differences in AMD architecture mean there is a near
zero risk of exploitation of this variant. Vulnerability to Variant 2 has
not been demonstrated on AMD processors to date."

Ref:
http://www.amd.com/en/corporate/speculative-execution
https://meltdownattack.com/
http://www.tomshardware.com/forum/id-3609004/cpu-security-vulnerabilities-information.html

Re: [gentoo-user] Spectre CPU flaws

[Mick]

On Thursday, 4 January 2018 05:50:59 GMT the...@sys-concept.com wrote:
> New bug resurface.
> What is the command to test AMD CUP's if flag: X86_BUG_CPU_INSECURE is
> enabled?
> 
> From:
> https://lkml.org/lkml/2017/12/27/2

grep bugs /proc/cpuinfo

-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] old kernels are installed during the upgrade

[Alan McKinnon]

On 04/01/2018 08:40, Wols Lists wrote:
> On 03/01/18 22:09, Alan McKinnon wrote:
>> On 04/01/2018 00:02, Stroller wrote:
>>>
 On 3 Jan 2018, at 21:55, Wols Lists  wrote:
  
 What would be nice, would be if "emerge --depclean" had the smarts to
 recognise that /usr/src/linux pointed to the current active kernel, and
 didn't wipe that when it cleaned out everything else :-) That way, at
 most you could have the current and latest kernel sources available
 pretty easily.
>>>
>>> You've jogged a long-hibernating memory - the accidental removal of the 
>>> current sources tree in an accident like this may be the exact reason why I 
>>> refuse to allow kernel versions to be actively emerged.
>>
>> I think that's a mountain and a molehill. You still have the image in
>> /boot, config in /boot or in the running kernel, libs in /lib/modules
>> and the bootloader is intact.
>>
>> Delete the sources?
>> - Re-emerge them. 90 seconds.
>> - Re-compile using existing config. 20 minutes
>>
>> So deleting the sources for the running kernel is a doh! moment. But no
>> biggie, and certainly not cause for changing your routine (all in my own
>> not at all humble opinion, of course)
>>
> But it's a royal pain, especially if you don't realise that's what's
> happened, because a general emerge is likely to have a lot of grief.

Yes there is that

> 
> Dunno how many ebuilds actually refer to /usr/src/linux for some of
> their header files, but I doubt it's negligible. It's certainly caused
> me grief in the past.

It's a decidedly non-trivial number of ebuilds.

On Gentoo /usr/src is a symlink to the *configured* kernel sources, on
binary distros the same dir usually contains headers for the running kernel

> (Yes I think they're not supposed to, but what's that saying about
> theory and practice?)

I don't know of any documentation in Gentoo that says ebuilds shouldn't
do that but I can't think of any realistic alternatives. Gentoo needs
access to the kernel config not just the sources and we can't rely on a
config being present in /boot like binary distros can

> 
> I don't like it when well-known problems cause general breakage that is
> likely to cause havoc for unsuspecting users...

Gentoo has always had a fallback excuse position for devs:

By running Gentoo you give up all right to claiming to be an
"unsuspecting user"

Harsh I know, and sucky when it hits you, but it is what it is.
Gentoo is not for the faint-hearted



-- 
Alan McKinnon
alan.mckin...@gmail.com