similar to: boot issue with latest kernel

Young, Gregory wrote: > > Is this a VM running on top of Hyper-V by chance? There seems to be an > issue with the combination of: - Windows 10 1708 or newer. > - Hyper-V config version 8.2 - 9.0. > - Microsoft's Fix for Spectre and Meltdown. > - Newer Intel Hardware (Sandy Lake/Kaby Lake, etc.) > > The workaround seems to be to remove "rhgb" and

Hi Keith, Is this a VM running on top of Hyper-V by chance? There seems to be an issue with the combination of: - Windows 10 1708 or newer. - Hyper-V config version 8.2 - 9.0. - Microsoft's Fix for Spectre and Meltdown. - Newer Intel Hardware (Sandy Lake/Kaby Lake, etc.) The workaround seems to be to remove "rhgb" and "quiet" from the kernel line in the GRUB config (you

I got a new laptop as my old one died: an HP Probook 470 G4.? I installed Centos 7 1511. The laptop has a Kaby Lake i5 CPU and an? 01:00.0 3D controller: NVIDIA Corporation Device 134e (rev a2).? Fedora recognizes it as a GM108M/930MX. This may give some hints, but it is not that the standard kernel does not support it, this output comes from the 4.8.7 mainline kernel which should support this

On Sat, 2016-11-12 at 15:34 -0500, Fred Smith wrote: > On Sat, Nov 12, 2016 at 09:15:22PM +0100, Louis Lagendijk wrote: > > > > I got a new laptop as my old one died: an HP Probook 470 G4.? > > I installed Centos 7 1511. > > The laptop has a Kaby Lake i5 CPU and an? > > 01:00.0 3D controller: NVIDIA Corporation Device 134e (rev a2).? > > Fedora recognizes it

Hi Ilia, many thanks for answering my mail. Tonight I tried to see what happens if I generate a xorg.conf file and place it in /etc/X11/xorg.conf, as described here: https://askubuntu.com/questions/4662/where-is-the-x-org-config-file-how-do-i-configure-x-there When I do that X starts without the framebuffer error. X starts with a backtrace list in the shell and then stops with the error:

On Mon, 2016-11-14 at 06:48 -0600, Johnny Hughes wrote: > On 11/12/2016 02:39 PM, Louis Lagendijk wrote: > > > > On Sat, 2016-11-12 at 15:34 -0500, Fred Smith wrote: > > > > > > On Sat, Nov 12, 2016 at 09:15:22PM +0100, Louis Lagendijk wrote: > > > > > > > > > > > > I got a new laptop as my old one died: an HP Probook 470

Hi Ben, David and Daniel , First of all happy new year. Based on advice of Greg K-H herewith a mail about a number of Nouveau issues with my laptop. I installed various Kali linux versions up to Linux 4.20.0-rc7 (downloaded, compiled and installed) on a Samsung NP900X5N laptop and have an issue with the driver after loading. My configuration: - i7 7500 - 16 gb / 256 gb ssd - nvidia 940MX

On Mon, Sep 09, 2019 at 03:19:55PM +0800, Jason Wang wrote: > > On 2019/9/8 ??7:05, Michael S. Tsirkin wrote: > > iovec addresses coming from vhost are assumed to be > > pre-validated, but in fact can be speculated to a value > > out of range. > > > > Userspace address are later validated with array_index_nospec so we can > > be sure kernel info does not

On Mon, Sep 09, 2019 at 03:19:55PM +0800, Jason Wang wrote: > > On 2019/9/8 ??7:05, Michael S. Tsirkin wrote: > > iovec addresses coming from vhost are assumed to be > > pre-validated, but in fact can be speculated to a value > > out of range. > > > > Userspace address are later validated with array_index_nospec so we can > > be sure kernel info does not

Hi Johnny, Thank you for your reply. It seems to me that my message may have came around as offensive but that was not my intend. I have basic understanding how things work and when I said CentOS I actually meant Red Hat and all its derivatives. I asked CentOS community because that's the community I'm member of. Not to say that CentOS is not secure or anything like that. Anyway,

iovec addresses coming from vhost are assumed to be pre-validated, but in fact can be speculated to a value out of range. Userspace address are later validated with array_index_nospec so we can be sure kernel info does not leak through these addresses, but vhost must also not leak userspace info outside the allowed memory table to guests. Following the defence in depth principle, make sure the

iovec addresses coming from vhost are assumed to be pre-validated, but in fact can be speculated to a value out of range. Userspace address are later validated with array_index_nospec so we can be sure kernel info does not leak through these addresses, but vhost must also not leak userspace info outside the allowed memory table to guests. Following the defence in depth principle, make sure the

By now, we're sure most everyone have heard of the Meltdown and Spectre attacks. If not, head over to https://meltdownattack.com/ and get an overview. Additional technical details are available from Google Project Zero. https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html The FreeBSD Security Team was notified of the issue in late December and received a

By now, we're sure most everyone have heard of the Meltdown and Spectre attacks. If not, head over to https://meltdownattack.com/ and get an overview. Additional technical details are available from Google Project Zero. https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html The FreeBSD Security Team was notified of the issue in late December and received a

I have a clean install, fully updated CentOS 6 32-bit. When I run the Red Hat detection script: https://access.redhat.com/sites/default/files/spectre-meltdown--a79614b.sh it finds that the system is vulnerable. Is this false positive or there is no patches for CentOS 6 32-bit systems? Thank you, -- Peter

Hi, I am very sorry to do this on short notice, but obviously Meltdown and Spectre are a lot more than anyone was really expecting to come down the pipeline. Xen 4.4 has been EOL upstream for about a year now and I have personally been reviewing and backporting patches based on the 4.5 versions made available upstream. Given that 4.5 is now also reaching EOL, backporting to 4.4 will become

On 11/5/2017 10:45 PM, Sorin Srbu wrote: > What would you consider be a tested and proven working, newish chipset? its really the CPU now that matters, rather than the 'chipset', as most all the base IO devices are in the CPU (ethernet, sata, video). I think Kaby Lake support is still a sketchy, thats Core gen 7. (i-7xxx). I'm not sure what the state of Skylake is (gen 6)

On Tue, Oct 1, 2019 at 10:47 AM Mika Westerberg <mika.westerberg at linux.intel.com> wrote: > > On Mon, Sep 30, 2019 at 06:36:12PM +0200, Karol Herbst wrote: > > On Mon, Sep 30, 2019 at 6:30 PM Mika Westerberg > > <mika.westerberg at linux.intel.com> wrote: > > > > > > On Mon, Sep 30, 2019 at 06:05:14PM +0200, Karol Herbst wrote: > > > >

On Mon, Oct 21, 2019 at 04:49:09PM +0200, Karol Herbst wrote: > On Mon, Oct 21, 2019 at 4:09 PM Mika Westerberg > <mika.westerberg at intel.com> wrote: > > > > On Mon, Oct 21, 2019 at 03:54:09PM +0200, Karol Herbst wrote: > > > > I really would like to provide you more information about such > > > > workaround but I'm not aware of any ;-) I have

On Tue, Sep 10, 2019 at 09:52:10AM +0800, Jason Wang wrote: > > On 2019/9/9 ??10:45, Michael S. Tsirkin wrote: > > On Mon, Sep 09, 2019 at 03:19:55PM +0800, Jason Wang wrote: > > > On 2019/9/8 ??7:05, Michael S. Tsirkin wrote: > > > > iovec addresses coming from vhost are assumed to be > > > > pre-validated, but in fact can be speculated to a value