lists.openwall.net | 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 linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 10 Sep 2018 13:07:38 -0700 From: Dave Hansen <dave.hansen@...ux.intel.com> To: Andy Lutomirski <luto@...capital.net> Cc: linux-kernel@...r.kernel.org, sean.j.christopherson@...el.com, peterz@...radead.org, tglx@...utronix.de, x86@...nel.org, luto@...nel.org Subject: Re: [RFC][PATCH 1/8] x86/mm: clarify hardware vs. software "error_code" On 09/07/2018 03:48 PM, Andy Lutomirski wrote: >> >> For part of the page fault handler, "error_code" does exactly >> match PFEC. But, during later parts, it diverges and starts to >> mean something a bit different. >> >> Give it two names for its two jobs. > How hard would it be to just remove sw_error_code instead? It seems > like it adds little value and much confusion. I think it would be really nice to have hw_error_code stand by itself and be limited in scope to just __do_page_fault() and then have FAULT_FLAG_* for everything else. But, I was a little scared off of that. For one, I think we fill in signal info with error_code, which makes it nominally part of the ABI. So, I wanted to muck with it as little as possible in this set. But, if we just said that 1. hw_error_code goes out to userspace, always, and 2. We drive all kernel behavior off of FAULT_FLAG_*, not error_code, I think we can get away with it. > I’m also unconvinced that the warning is terribly useful. We’re going > to oops when this happens anyway. One thing I wanted to get out of the warning was the contents of hw_error_code before we go screwing with it. I also don't mind a nice, clarifying warning showing up just before an oops. Maybe it could be a pr_warn/err() instead of a full warning?
Powered by blists - more mailing lists