lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 4 Apr 2017 09:29:37 -0700
From:   Samuel Sieb <>
To:     Joerg Roedel <>
Cc:     Linux Kernel <>
Subject: Re: AMD IOMMU causing filesystem corruption

On 04/04/2017 12:32 AM, Joerg Roedel wrote:
> On Tue, Apr 04, 2017 at 12:11:31AM -0700, Samuel Sieb wrote:
>> Unfortunately, that turned out to be a bit premature.  After
>> compiling a kernel on it remotely over ssh (not interacting with the
>> logged in desktop), a reboot failed with endless completion-wait
>> loop timeout messages and after a force poweroff and restart it
>> won't boot.  The EFI filesystem was even destroyed, probably because
>> the kernel installation modified a file on there.
> Yeah, please boot the machine with amd_iommu=off during re-installation
> and when you install the modified kernel. And then boot into the patches
> kernel with amd_iommu=on (which is the default).
That's what I did.  While running with iommu=off, I compiled and 
installed a 4.11rc kernel with the patch.  I rebooted to use that kernel 
and then compiled and installed a 4.10 kernel with that patch and 
another unrelated patch.  That is what I described above.  The 
filesystem destruction happened while running the 4.11rc kernel with 
that patch.  Is there any way to verify that the patch was actually 
having any effect?  Can I check if ATS is enabled or not?  I will have 
to rebuild the system before I can test again.

Powered by blists - more mailing lists