> unlikely to affect a somewhat security-conscious Linux user Obviously the reported malware is Windows specific, but there's no fundamental roadblock to impl

> unlikely to affect a somewhat security-conscious Linux user Obviously the reported malware is Windows specific, but there's no fundamental roadblock to implement something similar in Linux. - malware injected in the boot process: Have a patched grub/syslinux/gummiboot that, after loading the Linux kernel, patches in the first stages of a rootkit. Common syscall tables and important system functions (kalloc, ...) are easy to identify, as long as the API doesn't radically change. - secret, encrypted, storage vault in the registry is surely harder to hide, because there's typically not ONE huge monolithic binary configuration database. So, probably one would have to find a feature of ext4/btrfs/xfs/... to hide things in some internally used filesystem object that's not visible to userspace (you can, after all, patch the fs kernel module if necessary) - patching the SSD or harddrive is surely doable, just have a look at the hdparm manpage for inspiration. (--fwdownload is the official undocumented API :-)). [just thinking about the parallels, a sophisticated attacker will surely spend some time tailoring his rootkit/malware better] But obviously it would be much harder to persist on a machine, given that internal APIs are much more unstable and bootloader frequently overwritten on OS updates (the Win Bootloader/boot partition, afaik, never...). On the other hand, the targeted users (industrial/military corporations) will probably stick with yesteryear's RedHat Enterprise, rather than "bleeding edge" Arch/gentoo.