linux-kernel - Re: [RFC][PATCH 1/8] x86/mm: clarify hardware vs. software "error

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6f75823d-ce8b-d483-6046-4efbe20d0410@linux.intel.com>
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?