Nope, it'll just give well-executed fakes a veneer of legitimacy. A state-level actor will have easy access to the signing keys. Non-state-level actors could potentially extract them from a device or bribe an engineer at a third-tier Chinese OEM. A reasonably competent hardware hacker could desolder the CCD from a signed device and feed whatever video signal they like into it.

I created a raid-Z zpool in 2010 on FreeBSD and those same bits, with two different drives, are still floating around intact 6 years later, across multiple different operating systems.

[1] https://www.wikiwand.com/en/Microsoft_POSIX_subsystem

[2] https://www.wikiwand.com/en/Windows_Services_for_UNIX

As long as property taxes do not outstrip my interest rate, that ratio should stay in my favor going forward.

Tax being 1/3rd of rent indicates rather low rents or rather high tax.

My property taxes this year were ~$4200 on an average sized lot and home, or roughly $350/month.

My last apartment cost $1050/month for a small two bedroom condo rental.

So you take a mortgage and you're happy and there is a chance that you'll stay happy because your present reckoning may remain as good in the future as it is now. But it also may not. By mortgaging you become a sitting duck against the change, and that rental business of $1700/month seems attractive enough to invite further involvement and development thus driving the prices much lower not only compared to its current figure but also with the praised rental figure. What would you do then if this happens? Refinance in order to stretch that mortgage for more than 30 years?

Also, it seems a bit odd to hedge against downturns in the housing market by investing in the stock market. The latter is far more volatile.

But there is also the opportunity cost. Having a mortgage may be equivalent financially, but it's a liability when considering your freedom to change or to invest in something profitable that may pop up along the way.

IIUC SMEP is on Sandy Bridge processors too.

EDIT:

    [chris@f23m cve20160728]$ ./cve_2016_0728 PP_KEY
    uid=1000, euid=1000
    Increfing...
    finished increfing
    forking...
    finished forking
    caling revoke...
    uid=1000, euid=1000
    sh-4.3$

  grep commit_creds /proc/kallsyms
  grep prepare_kernel_cred /proc/kallsyms

  _commit_creds commit_creds = 0xffffffff81094250;
  _prepare_kernel_cred prepare_kernel_cred = 0xffffffff81094550;

As a normal user, grepping these values I actually get 0000000000000000. I can't imagine these being the actual values. Is it possible that because I remount my /proc with the hidepid=2 option the values are not visible for normal non-root accounts?

  /proc/sys/kernel/kptr_restrict

Just for curiosity's sake, from searching around it seems that this particular security feature (hide kernel pointers for unprivileged users) seems to have originated from this commit (which in itself implements a broader and more general security feature): http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g... - but it's often not enabled.

So it's not ASLR or anything to do with filesystem options (per se), but rather a custom "kptr_restrict" kernel vs. userspace security feature provided by the kernel:

"[...] The %pK format specifier is designed to hide exposed kernel pointers, specifically via /proc interfaces. Exposing these pointers provides an easy target for kernel write vulnerabilities, since they reveal the locations of writable structures containing easily triggerable function pointers." (Dan Rosenberg, 2011-01-13 - nice.) (Of course if there's no ASLR and one knows which distro is being targeted, it's possible to find those values on another machine and to just bake them into the exploit, as others have pointed out. Also, other channels exist for finding these addresses, etc.)

EDIT: The obvious question I should have asked is which distro you are running. Also, as others have pointed out, hoping that the attacker can't read kallsyms from the machine he's attacking is not really a good defense plan.

Exploiting from root to root doesn't make a lot of sense. If the values are not retrievable as normal user this exploit can't be used.. Right?

Think of it like the manual of a nuclear missile launcher. Obviously they don't want to give that out to everyone. But if you can break into the room with the launcher's control panel, you've still caused a major security breach even if you have no idea what to do next. Having the manual just makes your job easier, but the attack was that you broke in in the first place; they can't count on you being unable to figure out how to work the panel.

Also, if you're running a binary kernel (for instance, a kernel built by your Linux distro), the addresses in kallsyms are going to be constant for everyone running that distro. Hiding kallsyms for non-root users is primarily useful for people who build custom kernels.

Production-level malware often also has code that doesn't depend on having access to kallsyms and is more advanced (e.g., starting from the system call interrupt vector and disassembling it and seeing what addresses are jumped to). Using kallsyms is good for keeping a simple proof-of-concept exploit readable.

Suppose you have a vulnerable CentOS 7 system that you want to exploit - you could get the proper addresses from your own CentOS 7 VM running the same kernel, apply those to a modified exploit compilation, and run that compilation on your target host.

Also, it is not bullet proof because apparently there are lots of info leaks in linux and I think linux also does not reboot after a panic (http://www.cyberciti.biz/tips/reboot-linux-box-after-a-kerne...) so if the entropy for KASLR is small enough you can retry very aggressively. Though in this particular instance if you have to wait 30 minutes between each try that would kill brute forcing.

^-- this version should do that automatically

If programming was that unforgiving I'd have to buy a new system every time I wrote a function.

Put them in _any_ standing water. Old tires are a notorious mosquito breeding ground: small, hard to individually find, hold water, don't degrade.

It was in no way clear that Red Hat's second release included Florian's fixes - I found out from Mark Cox's post on this Twitter thread - https://twitter.com/lcamtuf/status/516297412579581952