These were the links I was referring to that never made it past moderation/spam...
> Alfred Hegemeier <molybdanstahl...@yahoo.co.uk> saith: > just encrypt the whole hard drive with Geli. GELI works under your control for what you store on the drive, and you can even enable the AES encryption feature of the drive itself as a no cost to performance extra freebie underneath that. However since the raw device interface is still accessible, neither of them do anything to block firmware updates. > Karl Denninger <k...@denninger.net> saith: > 1. The BIOS (which reads the boot sector) has not been compromised. > 2. Once the drive code has been tampered with These cases were addressed earlier... " Obviously. This is only meant to help protect clean systems, or prevent subsequent malicious commands if they happen to go through a user to firmware path that has for some reason not yet been compromised (say through the usual /dev to driver to hardware path). In all cases, having the logging capability for non production opcodes without having to postfilter them out of some debugging stream would be nice. Obviously again caveat parts of the system that have not been compromised. " > how many of these attacks are going to be loaded into your machine > through a _*running*_ modern BSD-style system? These for starters, then all the public hacker malware versions of the same thing both extant and coming... https://www.schneier.com/blog/archives/2014/01/iratemonk_nsa_e.html http://leaksource.files.wordpress.com/2013/12/nsa-ant-iratemonk.jpg https://www.schneier.com/blog/archives/2014/02/swap_nsa_exploi.html http://leaksource.files.wordpress.com/2013/12/nsa-ant-swap.jpg http://leaksource.files.wordpress.com/2013/12/nsa-ant-sierramontana.jpg http://25zbkz3k00wn2tp5092n6di7b5k.wpengine.netdna-cdn.com/files/2015/02/Equation_group_questions_and_answers.pdf > I suspect the answer is > "few" and a false sense of security is worse than none at all. Defense in depth is not a false defense, even when thrown at the few. Given a clean system, the ability to block these opcodes would seem defensive. _______________________________________________ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
