Re: [Users] X86_BUG_CPU_INSECURE

2018-01-10 Thread Konstantin Khorenko

On 01/10/2018 10:58 PM, Jehan Procaccia wrote:

you were right, waiting overnight for mirrors to get updated, now I do
have an kernel update

# uname -a
Linux  3.10.0-693.11.6.vz7.40.4 #1 SMP Fri Jan 5 21:20:16 MSK 2018
x86_64 x86_64 x86_64 GNU/Linux

# rpm -q --changelog  vzkernel-3.10.0-693.11.6.vz7.40.4.x86_64 | more
* sam. janv. 06 2018 Konstantin Khorenko <khore...@virtuozzo.com>
[3.10.0-693.11.6.vz7.40.4]
- vznetstat: Convert some kmalloc()/kfree() to __vmalloc()/vfree()
(Kirill Tkhai) [PSBM-79502]
- vznetstat: Add protection to venet_acct_set_classes() (Kirill Tkhai)
- ms/mm/mempolicy: Add cond_resched() in queue_pages_pte_range() (Andrey
Ryabinin) [PSBM-79273]
- ms/sctp: do not peel off an assoc from one netns to another one (Xin
Long) [PSBM-79325]
- ve: fix container stopped state check (Stanislav Kinsburskiy) [PSBM-78078]
...

no CVE mentioned , but I guess that these changes are related to
meltdown and spectre !?


We do rebases on new RHEL7 kernels, so our Virtuozzo specific patches will be 
always on top after a rebase,
just look deeper into changelog:

[root@localhost ~]# rpm -qp --changelog 
vzkernel-3.10.0-693.11.6.vz7.40.4.x86_64.rpm |grep CVE-2017-5715 |head -n 3
- [x86] spec_ctrl: Eliminate redundant FEATURE Not Present messages (Andrea 
Arcangeli) [1519795 1519798] {CVE-2017-5715}
- [x86] mm/kaiser: init_tss is supposed to go in the PAGE_ALIGNED per-cpu 
section (Andrea Arcangeli) [1519795 1519798] {CVE-2017-5715}
- [x86] spec_ctrl: svm: spec_ctrl at vmexit needs per-cpu areas functional 
(Andrea Arcangeli) [1519795 1519798] {CVE-2017-5715}

[root@localhost ~]# rpm -qp --changelog 
vzkernel-3.10.0-693.11.6.vz7.40.4.x86_64.rpm |grep CVE-2017-5753 |head -n 3
- [misc] locking/barriers: prevent speculative execution based on Coverity scan 
results (Josh Poimboeuf) [1519788 1519786] {CVE-2017-5753}
- [fs] udf: prevent speculative execution (Josh Poimboeuf) [1519788 1519786] 
{CVE-2017-5753}
- [fs] prevent speculative execution (Josh Poimboeuf) [1519788 1519786] 
{CVE-2017-5753}

[root@localhost ~]# rpm -qp --changelog 
vzkernel-3.10.0-693.11.6.vz7.40.4.x86_64.rpm |grep CVE-2017-5754 |head -n 3
- [x86] spec_ctrl: Prevent unwanted speculation without IBRS (Josh Poimboeuf) 
[1519795 1519798] {CVE-2017-5715 CVE-2017-5754}
- [x86] entry: Remove trampoline check from paranoid entry path (Josh 
Poimboeuf) [1519795 1519798] {CVE-2017-5715 CVE-2017-5754}
- [x86] entry: Fix paranoid_exit() trampoline clobber (Josh Poimboeuf) [1519795 
1519798] {CVE-2017-5715 CVE-2017-5754}

--
Best regards,

Konstantin Khorenko,
Virtuozzo Linux Kernel Team




Thanks

Le 09/01/2018 à 21:51, Konstantin Bukharov a écrit :

Hello Jehan,

Looks reasonable for me.
Your FR mirrors for openvz-os & openvz-updates are just not in sync with out 
last update.

Best regards,
Konstantin

PS. You could see list of required packages by URL provided by Vasiliy below:
https://download.openvz.org/virtuozzo/releases/7.0/x86_64/os/repoview/


-Original Message-
From: Jehan Procaccia [mailto:jehan.procac...@it-sudparis.eu]
Sent: Tuesday, January 9, 2018 23:43
To: OpenVZ users <users@openvz.org>; Konstantin Bukharov <b...@virtuozzo.com>; 
Vasiliy Averin <v...@virtuozzo.com>
Subject: Re: [Users] X86_BUG_CPU_INSECURE

here is my repolist -v , let me know if I miss some repos ?

thanks

# yum repolist -v
Loading "fastestmirror" plugin
Loading "langpacks" plugin
Loading "openvz" plugin
Loading "priorities" plugin
Loading "product-id" plugin
Loading "refresh-packagekit" plugin
Loading "rhsm-auto-add-pools" plugin
Loading "search-disabled-repos" plugin
Not loading "subscription-manager" plugin, as it is disabled
Loading "vzlinux" plugin
Adding en_US.UTF-8 to language list
Config time: 0.069
Yum version: 3.4.3
Trying to discover and attach new pools
Loading mirror speeds from cached hostfile
   * openvz-os: ftp.lip6.fr
   * openvz-updates: ftp.lip6.fr
Setting up Package Sacks
   --> anaconda-21.48.22.121-3.vl7.x86_64 from virtuozzolinux-base
excluded (priority)
   --> anaconda-core-21.48.22.121-3.vl7.x86_64 from virtuozzolinux-base
excluded (priority)
   --> anaconda-dracut-21.48.22.121-3.vl7.x86_64 from virtuozzolinux-base
excluded (priority)
   --> anaconda-gui-21.48.22.121-3.vl7.x86_64 from virtuozzolinux-base
excluded (priority)
   --> anaconda-tui-21.48.22.121-3.vl7.x86_64 from virtuozzolinux-base
excluded (priority)
   --> anaconda-widgets-21.48.22.121-3.vl7.x86_64 from
virtuozzolinux-base excluded (priority)
   --> anaconda-widgets-devel-21.48.22.121-3.vl7.x86_64 from
virtuozzolinux-base excluded (priority)
   --> crit-2.3-2.vl7.x86_64 from virtuozzolinux-base excluded (priority)
   --> criu-2.3-2.vl7.x86_64 from virtuozzolinux-base excluded (priority)
   --> ipxe-bootimgs-20170123-1.git4e85b27.vl7.1.noarch from
virtuozzolinux-base excluded (priority)
   --> ipxe-roms-

Re: [Users] X86_BUG_CPU_INSECURE

2018-01-10 Thread Konstantin Bukharov
Yes, kernel has right version.
To mitigate spectre, please follow 
https://help.virtuozzo.com/customer/portal/articles/2914675
And to mitigate spectre attacks from KVM VMs, please check that qemu-kvm-vz and 
libvirt packages are also updated.

-Original Message-
From: Jehan Procaccia [mailto:jehan.procac...@it-sudparis.eu] 
Sent: Wednesday, January 10, 2018 22:59
To: Konstantin Bukharov <b...@virtuozzo.com>; OpenVZ users <users@openvz.org>; 
Vasiliy Averin <v...@virtuozzo.com>
Subject: Re: [Users] X86_BUG_CPU_INSECURE

you were right, waiting overnight for mirrors to get updated, now I do 
have an kernel update

# uname -a
Linux  3.10.0-693.11.6.vz7.40.4 #1 SMP Fri Jan 5 21:20:16 MSK 2018 
x86_64 x86_64 x86_64 GNU/Linux

# rpm -q --changelog  vzkernel-3.10.0-693.11.6.vz7.40.4.x86_64 | more
* sam. janv. 06 2018 Konstantin Khorenko <khore...@virtuozzo.com> 
[3.10.0-693.11.6.vz7.40.4]
- vznetstat: Convert some kmalloc()/kfree() to __vmalloc()/vfree() 
(Kirill Tkhai) [PSBM-79502]
- vznetstat: Add protection to venet_acct_set_classes() (Kirill Tkhai)
- ms/mm/mempolicy: Add cond_resched() in queue_pages_pte_range() (Andrey 
Ryabinin) [PSBM-79273]
- ms/sctp: do not peel off an assoc from one netns to another one (Xin 
Long) [PSBM-79325]
- ve: fix container stopped state check (Stanislav Kinsburskiy) [PSBM-78078]
...

no CVE mentioned , but I guess that these changes are related to 
meltdown and spectre !?

Thanks

Le 09/01/2018 à 21:51, Konstantin Bukharov a écrit :
> Hello Jehan,
>
> Looks reasonable for me.
> Your FR mirrors for openvz-os & openvz-updates are just not in sync with out 
> last update.
>
> Best regards,
> Konstantin
>
> PS. You could see list of required packages by URL provided by Vasiliy below:
> https://download.openvz.org/virtuozzo/releases/7.0/x86_64/os/repoview/
>
>
> -Original Message-
> From: Jehan Procaccia [mailto:jehan.procac...@it-sudparis.eu]
> Sent: Tuesday, January 9, 2018 23:43
> To: OpenVZ users <users@openvz.org>; Konstantin Bukharov 
> <b...@virtuozzo.com>; Vasiliy Averin <v...@virtuozzo.com>
> Subject: Re: [Users] X86_BUG_CPU_INSECURE
>
> here is my repolist -v , let me know if I miss some repos ?
>
> thanks
>
> # yum repolist -v
> Loading "fastestmirror" plugin
> Loading "langpacks" plugin
> Loading "openvz" plugin
> Loading "priorities" plugin
> Loading "product-id" plugin
> Loading "refresh-packagekit" plugin
> Loading "rhsm-auto-add-pools" plugin
> Loading "search-disabled-repos" plugin
> Not loading "subscription-manager" plugin, as it is disabled
> Loading "vzlinux" plugin
> Adding en_US.UTF-8 to language list
> Config time: 0.069
> Yum version: 3.4.3
> Trying to discover and attach new pools
> Loading mirror speeds from cached hostfile
>    * openvz-os: ftp.lip6.fr
>    * openvz-updates: ftp.lip6.fr
> Setting up Package Sacks
>    --> anaconda-21.48.22.121-3.vl7.x86_64 from virtuozzolinux-base
> excluded (priority)
>    --> anaconda-core-21.48.22.121-3.vl7.x86_64 from virtuozzolinux-base
> excluded (priority)
>    --> anaconda-dracut-21.48.22.121-3.vl7.x86_64 from virtuozzolinux-base
> excluded (priority)
>    --> anaconda-gui-21.48.22.121-3.vl7.x86_64 from virtuozzolinux-base
> excluded (priority)
>    --> anaconda-tui-21.48.22.121-3.vl7.x86_64 from virtuozzolinux-base
> excluded (priority)
>    --> anaconda-widgets-21.48.22.121-3.vl7.x86_64 from
> virtuozzolinux-base excluded (priority)
>    --> anaconda-widgets-devel-21.48.22.121-3.vl7.x86_64 from
> virtuozzolinux-base excluded (priority)
>    --> crit-2.3-2.vl7.x86_64 from virtuozzolinux-base excluded (priority)
>    --> criu-2.3-2.vl7.x86_64 from virtuozzolinux-base excluded (priority)
>    --> ipxe-bootimgs-20170123-1.git4e85b27.vl7.1.noarch from
> virtuozzolinux-base excluded (priority)
>    --> ipxe-roms-20170123-1.git4e85b27.vl7.1.noarch from
> virtuozzolinux-base excluded (priority)
>    --> ipxe-roms-qemu-20170123-1.git4e85b27.vl7.1.noarch from
> virtuozzolinux-base excluded (priority)
>    --> 1:libguestfs-1.28.1-1.55.vl7.7.x86_64 from virtuozzolinux-base
> excluded (priority)
>    --> 1:libguestfs-bash-completion-1.28.1-1.55.vl7.7.noarch from
> virtuozzolinux-base excluded (priority)
>    --> 1:libguestfs-devel-1.28.1-1.55.vl7.7.x86_64 from
> virtuozzolinux-base excluded (priority)
>    --> 1:libguestfs-gobject-1.28.1-1.55.vl7.7.x86_64 from
> virtuozzolinux-base excluded (priority)
>    --> 1:libguestfs-gobject-devel-1.28.1-1.55.vl7.7.x86_64 from
> virtuozzolinux-base excluded (priority)
>    --> 1:libguestfs-gobject-doc-1.28.1-1.55.vl7.7.noarch from
> virtuozzol

Re: [Users] X86_BUG_CPU_INSECURE

2018-01-10 Thread Jehan Procaccia
you were right, waiting overnight for mirrors to get updated, now I do 
have an kernel update


# uname -a
Linux  3.10.0-693.11.6.vz7.40.4 #1 SMP Fri Jan 5 21:20:16 MSK 2018 
x86_64 x86_64 x86_64 GNU/Linux


# rpm -q --changelog  vzkernel-3.10.0-693.11.6.vz7.40.4.x86_64 | more
* sam. janv. 06 2018 Konstantin Khorenko <khore...@virtuozzo.com> 
[3.10.0-693.11.6.vz7.40.4]
- vznetstat: Convert some kmalloc()/kfree() to __vmalloc()/vfree() 
(Kirill Tkhai) [PSBM-79502]

- vznetstat: Add protection to venet_acct_set_classes() (Kirill Tkhai)
- ms/mm/mempolicy: Add cond_resched() in queue_pages_pte_range() (Andrey 
Ryabinin) [PSBM-79273]
- ms/sctp: do not peel off an assoc from one netns to another one (Xin 
Long) [PSBM-79325]

- ve: fix container stopped state check (Stanislav Kinsburskiy) [PSBM-78078]
...

no CVE mentioned , but I guess that these changes are related to 
meltdown and spectre !?


Thanks

Le 09/01/2018 à 21:51, Konstantin Bukharov a écrit :

Hello Jehan,

Looks reasonable for me.
Your FR mirrors for openvz-os & openvz-updates are just not in sync with out 
last update.

Best regards,
Konstantin

PS. You could see list of required packages by URL provided by Vasiliy below:
https://download.openvz.org/virtuozzo/releases/7.0/x86_64/os/repoview/


-Original Message-
From: Jehan Procaccia [mailto:jehan.procac...@it-sudparis.eu]
Sent: Tuesday, January 9, 2018 23:43
To: OpenVZ users <users@openvz.org>; Konstantin Bukharov <b...@virtuozzo.com>; 
Vasiliy Averin <v...@virtuozzo.com>
Subject: Re: [Users] X86_BUG_CPU_INSECURE

here is my repolist -v , let me know if I miss some repos ?

thanks

# yum repolist -v
Loading "fastestmirror" plugin
Loading "langpacks" plugin
Loading "openvz" plugin
Loading "priorities" plugin
Loading "product-id" plugin
Loading "refresh-packagekit" plugin
Loading "rhsm-auto-add-pools" plugin
Loading "search-disabled-repos" plugin
Not loading "subscription-manager" plugin, as it is disabled
Loading "vzlinux" plugin
Adding en_US.UTF-8 to language list
Config time: 0.069
Yum version: 3.4.3
Trying to discover and attach new pools
Loading mirror speeds from cached hostfile
   * openvz-os: ftp.lip6.fr
   * openvz-updates: ftp.lip6.fr
Setting up Package Sacks
   --> anaconda-21.48.22.121-3.vl7.x86_64 from virtuozzolinux-base
excluded (priority)
   --> anaconda-core-21.48.22.121-3.vl7.x86_64 from virtuozzolinux-base
excluded (priority)
   --> anaconda-dracut-21.48.22.121-3.vl7.x86_64 from virtuozzolinux-base
excluded (priority)
   --> anaconda-gui-21.48.22.121-3.vl7.x86_64 from virtuozzolinux-base
excluded (priority)
   --> anaconda-tui-21.48.22.121-3.vl7.x86_64 from virtuozzolinux-base
excluded (priority)
   --> anaconda-widgets-21.48.22.121-3.vl7.x86_64 from
virtuozzolinux-base excluded (priority)
   --> anaconda-widgets-devel-21.48.22.121-3.vl7.x86_64 from
virtuozzolinux-base excluded (priority)
   --> crit-2.3-2.vl7.x86_64 from virtuozzolinux-base excluded (priority)
   --> criu-2.3-2.vl7.x86_64 from virtuozzolinux-base excluded (priority)
   --> ipxe-bootimgs-20170123-1.git4e85b27.vl7.1.noarch from
virtuozzolinux-base excluded (priority)
   --> ipxe-roms-20170123-1.git4e85b27.vl7.1.noarch from
virtuozzolinux-base excluded (priority)
   --> ipxe-roms-qemu-20170123-1.git4e85b27.vl7.1.noarch from
virtuozzolinux-base excluded (priority)
   --> 1:libguestfs-1.28.1-1.55.vl7.7.x86_64 from virtuozzolinux-base
excluded (priority)
   --> 1:libguestfs-bash-completion-1.28.1-1.55.vl7.7.noarch from
virtuozzolinux-base excluded (priority)
   --> 1:libguestfs-devel-1.28.1-1.55.vl7.7.x86_64 from
virtuozzolinux-base excluded (priority)
   --> 1:libguestfs-gobject-1.28.1-1.55.vl7.7.x86_64 from
virtuozzolinux-base excluded (priority)
   --> 1:libguestfs-gobject-devel-1.28.1-1.55.vl7.7.x86_64 from
virtuozzolinux-base excluded (priority)
   --> 1:libguestfs-gobject-doc-1.28.1-1.55.vl7.7.noarch from
virtuozzolinux-base excluded (priority)
   --> 1:libguestfs-java-1.28.1-1.55.vl7.7.x86_64 from
virtuozzolinux-base excluded (priority)
   --> 1:libguestfs-java-devel-1.28.1-1.55.vl7.7.x86_64 from
virtuozzolinux-base excluded (priority)
   --> 1:libguestfs-javadoc-1.28.1-1.55.vl7.7.noarch from
virtuozzolinux-base excluded (priority)
   --> 1:libguestfs-man-pages-ja-1.28.1-1.55.vl7.7.noarch from
virtuozzolinux-base excluded (priority)
   --> 1:libguestfs-man-pages-uk-1.28.1-1.55.vl7.7.noarch from
virtuozzolinux-base excluded (priority)
   --> 1:libguestfs-tools-1.28.1-1.55.vl7.7.noarch from
virtuozzolinux-base excluded (priority)
   --> 1:libguestfs-tools-c-1.28.1-1.55.vl7.7.x86_64 from
virtuozzolinux-base excluded (priority)
   --> libvirt-2.0.0-10.vl7.5.x86_64 from virtuozzolinux-base excluded
(priority)
   --> libvirt-client-2.0.0-10.vl7.5.i686 from virtuozzolinux-base
excluded (priority)
   --

Re: [Users] X86_BUG_CPU_INSECURE

2018-01-09 Thread Konstantin Bukharov
Hello Jehan,

Could you provide output from your system for the next command:
yum repolist -v

From your letter it seems that you have only 'Virtuozzo Linux' repositories 
configured and none for 'Virtuozzo' (aka OpenVZ).

Best regards,
Konstantin


-Original Message-
From: users-boun...@openvz.org [mailto:users-boun...@openvz.org] On Behalf Of 
Jehan Procaccia
Sent: Tuesday, January 9, 2018 21:54
To: OpenVZ users <users@openvz.org>; Vasiliy Averin <v...@virtuozzo.com>
Subject: Re: [Users] X86_BUG_CPU_INSECURE

Does this concern "free/not-licenced" virtuozzo 7 ?
I don't beneficiate of "ready-kernel" in that case, did you issued an 
exeptionnal out of cycle (3 mouths) updates ?

here's my situation that is not clear :

# cat /etc/redhat-release
Virtuozzo Linux release 7.4

# uname -a
Linux myserver.domain.fr 3.10.0-693.1.1.vz7.37.30 #1 SMP Wed Nov 15 
20:42:09 MSK 2017 x86_64 x86_64 x86_64 GNU/Linux

when I issued a yum update I got  kmod  packages , are these a meltdown 
& spectre patches ?
Mise à jour :
  kmod    x86_64 20-15.vl7.6   
virtuozzolinux-base   120 k
  kmod-libs   x86_64 20-15.vl7.6   
virtuozzolinux-base    50 k

not sure regarding changelogs dates :

# rpm -q --changelog kmod-20-15.vl7.6.x86_64 | more
* jeu. nov. 16 2017 Yauheni Kaliuta <ykali...@redhat.com> - 20-15.el7_4.6
- Backport external directories support.
   Related: rhbz#1511943.
...

thanks for your precisions .

regards .


Le 09/01/2018 à 10:22, Vasily Averin a écrit :
> OpenVZ7 update was released.
>
> It includes new kenrel, criu, qemu-kvm and libvirt.
>
> https://download.openvz.org/virtuozzo/releases/openvz-7.0.6-509/
> https://download.openvz.org/virtuozzo/releases/7.0/x86_64/os/repoview/
>
> Thank you,
>   Vasily Averin
>
> On 2018-01-06 14:40, Vasily Averin wrote:
>> We have released fixed RHEL6-based kernel,
>> please update your nodes to 2.6.32-042stab127.2 kernel
>>
>> Thank you,
>>  Vasily Averin
>>
>> On 2018-01-04 06:03, Alex Kobets wrote:
>>> Hi,
>>>
>>>
>>> Virtuozzo will release the kernel with fix asap.
>>>
>>> We have it under testing right now
>>>
>>>
>>> Thank you,
>>>
>>> Alex
>>>
>>> ------
>>> *From:* users-boun...@openvz.org <users-boun...@openvz.org> on behalf of 
>>> Hristo Benev <f...@abv.bg>
>>> *Sent:* Wednesday, January 3, 2018 6:39:10 PM
>>> *To:* zoo...@gmail.com; OpenVZ users
>>> *Subject:* Re: [Users] X86_BUG_CPU_INSECURE
>>>   
>>>>  Оригинално писмо 
>>>> От: Benjamin Henrion zoo...@gmail.com
>>>> Относно: [Users] X86_BUG_CPU_INSECURE
>>>> До: "OpenVZ users list. This is THE list you need." <users@openvz.org>
>>>> Изпратено на: 03.01.2018 03:02
>>>
>>>> Hi,
>>>>
>>>> Just reading this:
>>>>
>>>> https://amp.reddit.com/r/sysadmin/comments/7nl8r0/intel_bug_incoming/
>>>>
>>>> Xen seems to have a pending patch to be release this week, but people
>>>> are speculating now that you could bypass the entire isolation process
>>>> provided by any hypervisor.
>>>>
>>>> Wait and see how this will be exploited, but you can be sure there
>>>> will be exploits soon in the wild.
>>>>
>>>> The patch for software mitigation seems to be big and performance 
>>>> impacting.
>>>>
>>>> But that would probably mean that containers can be bypassed.
>>>>
>>>> Wait and see,
>>>>

Re: [Users] X86_BUG_CPU_INSECURE

2018-01-09 Thread Jehan Procaccia

Does this concern "free/not-licenced" virtuozzo 7 ?
I don't beneficiate of "ready-kernel" in that case, did you issued an 
exeptionnal out of cycle (3 mouths) updates ?


here's my situation that is not clear :

# cat /etc/redhat-release
Virtuozzo Linux release 7.4

# uname -a
Linux myserver.domain.fr 3.10.0-693.1.1.vz7.37.30 #1 SMP Wed Nov 15 
20:42:09 MSK 2017 x86_64 x86_64 x86_64 GNU/Linux


when I issued a yum update I got  kmod  packages , are these a meltdown 
& spectre patches ?

Mise à jour :
 kmod    x86_64 20-15.vl7.6   
virtuozzolinux-base   120 k
 kmod-libs   x86_64 20-15.vl7.6   
virtuozzolinux-base    50 k


not sure regarding changelogs dates :

# rpm -q --changelog kmod-20-15.vl7.6.x86_64 | more
* jeu. nov. 16 2017 Yauheni Kaliuta <ykali...@redhat.com> - 20-15.el7_4.6
- Backport external directories support.
  Related: rhbz#1511943.
...

thanks for your precisions .

regards .


Le 09/01/2018 à 10:22, Vasily Averin a écrit :

OpenVZ7 update was released.

It includes new kenrel, criu, qemu-kvm and libvirt.

https://download.openvz.org/virtuozzo/releases/openvz-7.0.6-509/
https://download.openvz.org/virtuozzo/releases/7.0/x86_64/os/repoview/

Thank you,
Vasily Averin

On 2018-01-06 14:40, Vasily Averin wrote:

We have released fixed RHEL6-based kernel,
please update your nodes to 2.6.32-042stab127.2 kernel

Thank you,
Vasily Averin

On 2018-01-04 06:03, Alex Kobets wrote:

Hi,


Virtuozzo will release the kernel with fix asap.

We have it under testing right now


Thank you,

Alex

--
*From:* users-boun...@openvz.org <users-boun...@openvz.org> on behalf of Hristo Benev 
<f...@abv.bg>
*Sent:* Wednesday, January 3, 2018 6:39:10 PM
*To:* zoo...@gmail.com; OpenVZ users
*Subject:* Re: [Users] X86_BUG_CPU_INSECURE
  

 Оригинално писмо 
От: Benjamin Henrion zoo...@gmail.com
Относно: [Users] X86_BUG_CPU_INSECURE
До: "OpenVZ users list. This is THE list you need." <users@openvz.org>
Изпратено на: 03.01.2018 03:02



Hi,

Just reading this:

https://amp.reddit.com/r/sysadmin/comments/7nl8r0/intel_bug_incoming/

Xen seems to have a pending patch to be release this week, but people
are speculating now that you could bypass the entire isolation process
provided by any hypervisor.

Wait and see how this will be exploited, but you can be sure there
will be exploits soon in the wild.

The patch for software mitigation seems to be big and performance impacting.

But that would probably mean that containers can be bypassed.

Wait and see,

--
Benjamin Henrion (zoobab)
Email: zoobab at gmail.com
Mobile: +32-484-566109
Web: http://www.zoobab.com
FFII.org Brussels
"In July 2005, after several failed attempts to legalise software
patents in Europe, the patent establishment changed its strategy.
Instead of explicitly seeking to sanction the patentability of
software, they are now seeking to create a central European patent
court, which would establish and enforce patentability rules in their
favor, without any possibility of correction by competing courts or
democratically elected legislators."
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users


https://spectreattack.com

States that OpenVZ might be affected.
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users


___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users


___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users


___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users





___

Re: [Users] X86_BUG_CPU_INSECURE

2018-01-09 Thread Vasily Averin
OpenVZ7 update was released.

It includes new kenrel, criu, qemu-kvm and libvirt.

https://download.openvz.org/virtuozzo/releases/openvz-7.0.6-509/
https://download.openvz.org/virtuozzo/releases/7.0/x86_64/os/repoview/

Thank you,
Vasily Averin

On 2018-01-06 14:40, Vasily Averin wrote:
> We have released fixed RHEL6-based kernel,
> please update your nodes to 2.6.32-042stab127.2 kernel
> 
> Thank you,
>   Vasily Averin
> 
> On 2018-01-04 06:03, Alex Kobets wrote:
>> Hi,
>>
>>
>> Virtuozzo will release the kernel with fix asap. 
>>
>> We have it under testing right now
>>
>>
>> Thank you,
>>
>> Alex
>>
>> --
>> *From:* users-boun...@openvz.org <users-boun...@openvz.org> on behalf of 
>> Hristo Benev <f...@abv.bg>
>> *Sent:* Wednesday, January 3, 2018 6:39:10 PM
>> *To:* zoo...@gmail.com; OpenVZ users
>> *Subject:* Re: [Users] X86_BUG_CPU_INSECURE
>>  
>>>  Оригинално писмо  
>>> От: Benjamin Henrion zoo...@gmail.com 
>>> Относно: [Users] X86_BUG_CPU_INSECURE 
>>> До: "OpenVZ users list. This is THE list you need." <users@openvz.org> 
>>> Изпратено на: 03.01.2018 03:02 
>>
>>
>>> Hi, 
>>>
>>> Just reading this: 
>>>
>>> https://amp.reddit.com/r/sysadmin/comments/7nl8r0/intel_bug_incoming/
>>>
>>> Xen seems to have a pending patch to be release this week, but people 
>>> are speculating now that you could bypass the entire isolation process 
>>> provided by any hypervisor. 
>>>
>>> Wait and see how this will be exploited, but you can be sure there 
>>> will be exploits soon in the wild. 
>>>
>>> The patch for software mitigation seems to be big and performance 
>>> impacting. 
>>>
>>> But that would probably mean that containers can be bypassed. 
>>>
>>> Wait and see, 
>>>
>>> -- 
>>> Benjamin Henrion (zoobab) 
>>> Email: zoobab at gmail.com 
>>> Mobile: +32-484-566109 
>>> Web: http://www.zoobab.com
>>> FFII.org Brussels 
>>> "In July 2005, after several failed attempts to legalise software 
>>> patents in Europe, the patent establishment changed its strategy. 
>>> Instead of explicitly seeking to sanction the patentability of 
>>> software, they are now seeking to create a central European patent 
>>> court, which would establish and enforce patentability rules in their 
>>> favor, without any possibility of correction by competing courts or 
>>> democratically elected legislators." 
>>> ___ 
>>> Users mailing list 
>>> Users@openvz.org 
>>> https://lists.openvz.org/mailman/listinfo/users
>>
>>
>> https://spectreattack.com
>>
>> States that OpenVZ might be affected.
>> ___
>> Users mailing list
>> Users@openvz.org
>> https://lists.openvz.org/mailman/listinfo/users
>>
>>
>> ___
>> Users mailing list
>> Users@openvz.org
>> https://lists.openvz.org/mailman/listinfo/users
>>
> 
> ___
> Users mailing list
> Users@openvz.org
> https://lists.openvz.org/mailman/listinfo/users
> 

___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users


Re: [Users] X86_BUG_CPU_INSECURE

2018-01-06 Thread Сергей Мамонов
Thanks a lot!

2018-01-06 14:40 GMT+03:00 Vasily Averin <v...@virtuozzo.com>:

> We have released fixed RHEL6-based kernel,
> please update your nodes to 2.6.32-042stab127.2 kernel
>
> Thank you,
> Vasily Averin
>
> On 2018-01-04 06:03, Alex Kobets wrote:
> > Hi,
> >
> >
> > Virtuozzo will release the kernel with fix asap.
> >
> > We have it under testing right now
> >
> >
> > Thank you,
> >
> > Alex
> >
> > 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> --
> > *From:* users-boun...@openvz.org <users-boun...@openvz.org> on behalf
> of Hristo Benev <f...@abv.bg>
> > *Sent:* Wednesday, January 3, 2018 6:39:10 PM
> > *To:* zoo...@gmail.com; OpenVZ users
> > *Subject:* Re: [Users] X86_BUG_CPU_INSECURE
> >
> >> Оригинално писмо 
> >>От: Benjamin Henrion zoo...@gmail.com
> >>Относно: [Users] X86_BUG_CPU_INSECURE
> >>До: "OpenVZ users list. This is THE list you need." <users@openvz.org>
> >>Изпратено на: 03.01.2018 03:02
> >
> >
> >> Hi,
> >>
> >> Just reading this:
> >>
> >> https://amp.reddit.com/r/sysadmin/comments/7nl8r0/intel_bug_incoming/
> >>
> >> Xen seems to have a pending patch to be release this week, but people
> >> are speculating now that you could bypass the entire isolation process
> >> provided by any hypervisor.
> >>
> >> Wait and see how this will be exploited, but you can be sure there
> >> will be exploits soon in the wild.
> >>
> >> The patch for software mitigation seems to be big and performance
> impacting.
> >>
> >> But that would probably mean that containers can be bypassed.
> >>
> >> Wait and see,
> >>
> >> --
> >> Benjamin Henrion (zoobab)
> >> Email: zoobab at gmail.com
> >> Mobile: +32-484-566109
> >> Web: http://www.zoobab.com
> >> FFII.org Brussels
> >> "In July 2005, after several failed attempts to legalise software
> >> patents in Europe, the patent establishment changed its strategy.
> >> Instead of explicitly seeking to sanction the patentability of
> >> software, they are now seeking to create a central European patent
> >> court, which would establish and enforce patentability rules in their
> >> favor, without any possibility of correction by competing courts or
> >> democratically elected legislators."
> >> ___
> >> Users mailing list
> >> Users@openvz.org
> >> https://lists.openvz.org/mailman/listinfo/users
> >
> >
> > https://spectreattack.com
> >
> > States that OpenVZ might be affected.
> > ___
> > Users mailing list
> > Users@openvz.org
> > https://lists.openvz.org/mailman/listinfo/users
> >
> >
> > ___
> > Users mailing list
> > Users@openvz.org
> > https://lists.openvz.org/mailman/listinfo/users
> >
>
> ___
> Users mailing list
> Users@openvz.org
> https://lists.openvz.org/mailman/listinfo/users
>



-- 
Best Regards,
Sergey Mamonov
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users


Re: [Users] X86_BUG_CPU_INSECURE

2018-01-06 Thread Narcis Garcia
Thank you.


El 06/01/18 a les 12:40, Vasily Averin ha escrit:
> We have released fixed RHEL6-based kernel,
> please update your nodes to 2.6.32-042stab127.2 kernel
> 
> Thank you,
>   Vasily Averin
> 
> On 2018-01-04 06:03, Alex Kobets wrote:
>> Hi,
>>
>>
>> Virtuozzo will release the kernel with fix asap. 
>>
>> We have it under testing right now
>>
>>
>> Thank you,
>>
>> Alex
>>
>> --
>> *From:* users-boun...@openvz.org <users-boun...@openvz.org> on behalf of 
>> Hristo Benev <f...@abv.bg>
>> *Sent:* Wednesday, January 3, 2018 6:39:10 PM
>> *To:* zoo...@gmail.com; OpenVZ users
>> *Subject:* Re: [Users] X86_BUG_CPU_INSECURE
>>  
>>>  Оригинално писмо  
>>> От: Benjamin Henrion zoo...@gmail.com 
>>> Относно: [Users] X86_BUG_CPU_INSECURE 
>>> До: "OpenVZ users list. This is THE list you need." <users@openvz.org> 
>>> Изпратено на: 03.01.2018 03:02 
>>
>>
>>> Hi, 
>>>
>>> Just reading this: 
>>>
>>> https://amp.reddit.com/r/sysadmin/comments/7nl8r0/intel_bug_incoming/
>>>
>>> Xen seems to have a pending patch to be release this week, but people 
>>> are speculating now that you could bypass the entire isolation process 
>>> provided by any hypervisor. 
>>>
>>> Wait and see how this will be exploited, but you can be sure there 
>>> will be exploits soon in the wild. 
>>>
>>> The patch for software mitigation seems to be big and performance 
>>> impacting. 
>>>
>>> But that would probably mean that containers can be bypassed. 
>>>
>>> Wait and see, 
>>>
>>> -- 
>>> Benjamin Henrion (zoobab) 
>>> Email: zoobab at gmail.com 
>>> Mobile: +32-484-566109 
>>> Web: http://www.zoobab.com
>>> FFII.org Brussels 
>>> "In July 2005, after several failed attempts to legalise software 
>>> patents in Europe, the patent establishment changed its strategy. 
>>> Instead of explicitly seeking to sanction the patentability of 
>>> software, they are now seeking to create a central European patent 
>>> court, which would establish and enforce patentability rules in their 
>>> favor, without any possibility of correction by competing courts or 
>>> democratically elected legislators." 
>>> ___ 
>>> Users mailing list 
>>> Users@openvz.org 
>>> https://lists.openvz.org/mailman/listinfo/users
>>
>>
>> https://spectreattack.com
>>
>> States that OpenVZ might be affected.
>> ___
>> Users mailing list
>> Users@openvz.org
>> https://lists.openvz.org/mailman/listinfo/users
>>
>>
>> ___
>> Users mailing list
>> Users@openvz.org
>> https://lists.openvz.org/mailman/listinfo/users
>>
> 
> ___
> Users mailing list
> Users@openvz.org
> https://lists.openvz.org/mailman/listinfo/users
> 

___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users


Re: [Users] X86_BUG_CPU_INSECURE

2018-01-06 Thread Vasily Averin
We have released fixed RHEL6-based kernel,
please update your nodes to 2.6.32-042stab127.2 kernel

Thank you,
Vasily Averin

On 2018-01-04 06:03, Alex Kobets wrote:
> Hi,
> 
> 
> Virtuozzo will release the kernel with fix asap. 
> 
> We have it under testing right now
> 
> 
> Thank you,
> 
> Alex
> 
> --
> *From:* users-boun...@openvz.org <users-boun...@openvz.org> on behalf of 
> Hristo Benev <f...@abv.bg>
> *Sent:* Wednesday, January 3, 2018 6:39:10 PM
> *To:* zoo...@gmail.com; OpenVZ users
> *Subject:* Re: [Users] X86_BUG_CPU_INSECURE
>  
>> Оригинално писмо  
>>От: Benjamin Henrion zoo...@gmail.com 
>>Относно: [Users] X86_BUG_CPU_INSECURE 
>>До: "OpenVZ users list. This is THE list you need." <users@openvz.org> 
>>Изпратено на: 03.01.2018 03:02 
> 
> 
>> Hi, 
>> 
>> Just reading this: 
>> 
>> https://amp.reddit.com/r/sysadmin/comments/7nl8r0/intel_bug_incoming/
>> 
>> Xen seems to have a pending patch to be release this week, but people 
>> are speculating now that you could bypass the entire isolation process 
>> provided by any hypervisor. 
>> 
>> Wait and see how this will be exploited, but you can be sure there 
>> will be exploits soon in the wild. 
>> 
>> The patch for software mitigation seems to be big and performance impacting. 
>> 
>> But that would probably mean that containers can be bypassed. 
>> 
>> Wait and see, 
>> 
>> -- 
>> Benjamin Henrion (zoobab) 
>> Email: zoobab at gmail.com 
>> Mobile: +32-484-566109 
>> Web: http://www.zoobab.com
>> FFII.org Brussels 
>> "In July 2005, after several failed attempts to legalise software 
>> patents in Europe, the patent establishment changed its strategy. 
>> Instead of explicitly seeking to sanction the patentability of 
>> software, they are now seeking to create a central European patent 
>> court, which would establish and enforce patentability rules in their 
>> favor, without any possibility of correction by competing courts or 
>> democratically elected legislators." 
>> ___ 
>> Users mailing list 
>> Users@openvz.org 
>> https://lists.openvz.org/mailman/listinfo/users
> 
> 
> https://spectreattack.com
> 
> States that OpenVZ might be affected.
> ___
> Users mailing list
> Users@openvz.org
> https://lists.openvz.org/mailman/listinfo/users
> 
> 
> ___
> Users mailing list
> Users@openvz.org
> https://lists.openvz.org/mailman/listinfo/users
> 

___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users


Re: [Users] X86_BUG_CPU_INSECURE

2018-01-03 Thread Scott Dowdle
Greetings,

- Original Message -
> Virtuozzo will release the kernel with fix asap.
> We have it under testing right now

That's great... but... if I understood the LWN article that came out today 
entitled, "Notes from the Intelpocalypse" there are three issues:
https://lwn.net/Articles/742702/ (subscription only until freely available at 
the end of next week)


1) Getting around boundary checks
2) Messing with indirect jumps
3) Forcing direct cache loads

#3 is negated by the kernel page table isolation (PPTI) patches that first 
appeared in the 4.15 rc kernels... which is what everyone is backporting to the 
older kernels they support.  There are various ways to fix #2 including 
potential CPU microcode patches from CPU makers and forthcoming a GCC flag... 
but at time of writing, the mainline kernel has no defense.  For #1, no 
straightforward defense has appeared yet.  LWN also predicts that additional 
exploits will appear in coming months that leverage one or more of these 
issues.  Two of the three issues are present in most all CPUs made since 1995 
that include speculative execution including Intel, AMD, ARM... and potentially 
others.  Only one of the three seems to be Intel specific.

While #3 is fixed... I'm guessing it is like fixing only one of three holes in 
a submarine's hull.

Of course any efforts in fixing anything are greatly appreciated.

TYL,
-- 
Scott Dowdle
704 Church Street
Belgrade, MT 59714
(406)388-0827 [home]
(406)994-3931 [work]
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users


Re: [Users] X86_BUG_CPU_INSECURE

2018-01-03 Thread Alex Kobets
Hi,


Virtuozzo will release the kernel with fix asap.

We have it under testing right now


Thank you,

Alex


From: users-boun...@openvz.org <users-boun...@openvz.org> on behalf of Hristo 
Benev <f...@abv.bg>
Sent: Wednesday, January 3, 2018 6:39:10 PM
To: zoo...@gmail.com; OpenVZ users
Subject: Re: [Users] X86_BUG_CPU_INSECURE

> Оригинално писмо 
>От: Benjamin Henrion zoo...@gmail.com
>Относно: [Users] X86_BUG_CPU_INSECURE
>До: "OpenVZ users list. This is THE list you need." <users@openvz.org>
>Изпратено на: 03.01.2018 03:02


> Hi,
>
> Just reading this:
>
> https://amp.reddit.com/r/sysadmin/comments/7nl8r0/intel_bug_incoming/
>
> Xen seems to have a pending patch to be release this week, but people
> are speculating now that you could bypass the entire isolation process
> provided by any hypervisor.
>
> Wait and see how this will be exploited, but you can be sure there
> will be exploits soon in the wild.
>
> The patch for software mitigation seems to be big and performance impacting.
>
> But that would probably mean that containers can be bypassed.
>
> Wait and see,
>
> --
> Benjamin Henrion (zoobab)
> Email: zoobab at gmail.com
> Mobile: +32-484-566109
> Web: http://www.zoobab.com
> FFII.org Brussels
> "In July 2005, after several failed attempts to legalise software
> patents in Europe, the patent establishment changed its strategy.
> Instead of explicitly seeking to sanction the patentability of
> software, they are now seeking to create a central European patent
> court, which would establish and enforce patentability rules in their
> favor, without any possibility of correction by competing courts or
> democratically elected legislators."
> ___
> Users mailing list
> Users@openvz.org
> https://lists.openvz.org/mailman/listinfo/users


https://spectreattack.com

States that OpenVZ might be affected.
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users


Re: [Users] X86_BUG_CPU_INSECURE

2018-01-03 Thread Hristo Benev
> Оригинално писмо  
>От: Benjamin Henrion zoo...@gmail.com 
>Относно: [Users] X86_BUG_CPU_INSECURE 
>До: "OpenVZ users list. This is THE list you need." <users@openvz.org> 
>Изпратено на: 03.01.2018 03:02 


> Hi, 
> 
> Just reading this: 
> 
> https://amp.reddit.com/r/sysadmin/comments/7nl8r0/intel_bug_incoming/ 
> 
> Xen seems to have a pending patch to be release this week, but people 
> are speculating now that you could bypass the entire isolation process 
> provided by any hypervisor. 
> 
> Wait and see how this will be exploited, but you can be sure there 
> will be exploits soon in the wild. 
> 
> The patch for software mitigation seems to be big and performance impacting. 
> 
> But that would probably mean that containers can be bypassed. 
> 
> Wait and see, 
> 
> -- 
> Benjamin Henrion (zoobab) 
> Email: zoobab at gmail.com 
> Mobile: +32-484-566109 
> Web: http://www.zoobab.com 
> FFII.org Brussels 
> "In July 2005, after several failed attempts to legalise software 
> patents in Europe, the patent establishment changed its strategy. 
> Instead of explicitly seeking to sanction the patentability of 
> software, they are now seeking to create a central European patent 
> court, which would establish and enforce patentability rules in their 
> favor, without any possibility of correction by competing courts or 
> democratically elected legislators." 
> ___ 
> Users mailing list 
> Users@openvz.org 
> https://lists.openvz.org/mailman/listinfo/users


https://spectreattack.com

States that OpenVZ might be affected.
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users


Re: [Users] X86_BUG_CPU_INSECURE

2018-01-03 Thread Jeffrey Walton
On Wed, Jan 3, 2018 at 8:41 AM, Scott Dowdle  wrote:
> Greetings,
> ...
> I've also read that while some other CPU arches have hardware specifically to 
> avoid the issue, others may also have a similar issue.  The fix is said to be 
> ported to aarch64 and at least one other arch that I don't recall.  Perhaps 
> they are just trying to be over protective?
>

That's kind of interesting.

Did they specifically mention ARM Trust Zones (or violating them)?

Jeff

___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users


Re: [Users] X86_BUG_CPU_INSECURE

2018-01-03 Thread Scott Dowdle
Greetings,

- Original Message -
> As I understand from dasunsrule32's post, affected CPUs show a flag
> X86_BUG_CPU_INSECURE (?!).
> Does this mean that Intel is distributing CPUs marking them as
> defective?! ...or is this flag from kernel detection?

It is detected by the kernel and not a real CPU flag.  If I understood a LWN 
article on the subject correctly (currently only available to subscribers but 
freely available later this week), the KPTI code in 4.15-rcX can tell whether 
the bug is present or not and use the fix if needed and avoid the fix (and the 
performance penalties it includes) if not needed.  I believe there is also a 
runtime parameter that can be used to manually disable the fix if desired.
 
> + Is somebody listing fixed CPU models?

To the best of my knowledge, Intel hasn't yet released any new CPUs without the 
issue.  They will in the future however.

> Note: I suppose neither OpenVZ 6 nor LXC are affected by this
> hardware bug.

Given the fact that the specifics haven't been publicly released and much of 
the discussion is speculation... it is hard to answer some of the questions 
that have been posed.  Also given that it is supposed to be a very low level 
bug that can violate memory access protections between user mode and kernel 
mode... I would imagine everything is violatable including containers unless 
OpenVZ/Virtuozzo modified kernel page tables and provided their own isolation 
(doubtful).  The bug is believed to allow one VM to spy on another VM so I 
don't know why one container wouldn't be able to spy on another... but again, 
this is all speculation at this point.

It is pretty much a given that Red Hat will backport the KPTI to all of the 
kernels they support.  Upstream is said to be doing it in the 4.15 kernel in 
development as well as backporting it to all LTS kernels so there should be 
good sources for the fix available to Virtuozzo for patching... but of coruse 
they'll have to interweave it with their own container patches and do their own 
QA so there will surely be at the very least a reasonable amount of delay.

Hopefully we'll know more when the bug details are publicly released.

We have seen absolutely horrible Linux kernel bugs in the past and as long as 
one patches their systems immediately after the release of updates, I don't 
think there is much to fear.  Of course the main difference here is that the 
bug is in the hardware and the OSes are having to rewrite their page table code 
to mitigate it.

I've also read that while some other CPU arches have hardware specifically to 
avoid the issue, others may also have a similar issue.  The fix is said to be 
ported to aarch64 and at least one other arch that I don't recall.  Perhaps 
they are just trying to be over protective?

TYL,
-- 
Scott Dowdle
704 Church Street
Belgrade, MT 59714
(406)388-0827 [home]
(406)994-3931 [work]
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users


Re: [Users] X86_BUG_CPU_INSECURE

2018-01-03 Thread Jeffrey Walton
On Wed, Jan 3, 2018 at 4:19 AM, Narcis Garcia  wrote:
> As I understand from dasunsrule32's post, affected CPUs show a flag
> X86_BUG_CPU_INSECURE (?!).
> Does this mean that Intel is distributing CPUs marking them as
> defective?! ...or is this flag from kernel detection?
>
> + Is somebody listing fixed CPU models?
>
> Note: I suppose neither OpenVZ 6 nor LXC are affected by this hardware bug.

As I understand things, it affects Intel processors. AMD processors
are safe, as are other architectures like Aarch64 and SPARC64.

Also see https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/ :


... In an email to the Linux kernel mailing list over Christmas, AMD
said it is not affected. The wording of that message, though, rather
gives the game away as to what the underlying cockup is:

AMD processors are not subject to the types of attacks that the kernel
page table isolation feature protects against. The AMD
microarchitecture does not allow memory references, including
speculative references, that access higher privileged data when
running in a lesser privileged mode when that access would result in a
page fault.


Jeff
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users


Re: [Users] X86_BUG_CPU_INSECURE

2018-01-03 Thread Narcis Garcia
As I understand from dasunsrule32's post, affected CPUs show a flag
X86_BUG_CPU_INSECURE (?!).
Does this mean that Intel is distributing CPUs marking them as
defective?! ...or is this flag from kernel detection?

+ Is somebody listing fixed CPU models?

Note: I suppose neither OpenVZ 6 nor LXC are affected by this hardware bug.



El 03/01/18 a les 02:02, Benjamin Henrion ha escrit:
> Hi,
> 
> Just reading this:
> 
> https://amp.reddit.com/r/sysadmin/comments/7nl8r0/intel_bug_incoming/
> 
> Xen seems to have a pending patch to be release this week, but people
> are speculating now that you could bypass the entire isolation process
> provided by any hypervisor.
> 
> Wait and see how this will be exploited, but you can be sure there
> will be exploits soon in the wild.
> 
> The patch for software mitigation seems to be big and performance impacting.
> 
> But that would probably mean that containers can be bypassed.
> 
> Wait and see,
> 
> --
> Benjamin Henrion (zoobab)
> Email: zoobab at gmail.com
> Mobile: +32-484-566109
> Web: http://www.zoobab.com
> FFII.org Brussels
> "In July 2005, after several failed attempts to legalise software
> patents in Europe, the patent establishment changed its strategy.
> Instead of explicitly seeking to sanction the patentability of
> software, they are now seeking to create a central European patent
> court, which would establish and enforce patentability rules in their
> favor, without any possibility of correction by competing courts or
> democratically elected legislators."
> ___
> Users mailing list
> Users@openvz.org
> https://lists.openvz.org/mailman/listinfo/users
> 
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users


[Users] X86_BUG_CPU_INSECURE

2018-01-02 Thread Benjamin Henrion
Hi,

Just reading this:

https://amp.reddit.com/r/sysadmin/comments/7nl8r0/intel_bug_incoming/

Xen seems to have a pending patch to be release this week, but people
are speculating now that you could bypass the entire isolation process
provided by any hypervisor.

Wait and see how this will be exploited, but you can be sure there
will be exploits soon in the wild.

The patch for software mitigation seems to be big and performance impacting.

But that would probably mean that containers can be bypassed.

Wait and see,

--
Benjamin Henrion (zoobab)
Email: zoobab at gmail.com
Mobile: +32-484-566109
Web: http://www.zoobab.com
FFII.org Brussels
"In July 2005, after several failed attempts to legalise software
patents in Europe, the patent establishment changed its strategy.
Instead of explicitly seeking to sanction the patentability of
software, they are now seeking to create a central European patent
court, which would establish and enforce patentability rules in their
favor, without any possibility of correction by competing courts or
democratically elected legislators."
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users