linux-kernel - Re: Commit 25f12ae45fc1 ("maccess: rename probe_kernel_address to get_kernel

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: <alpine.DEB.2.22.394.2006200640370.2845@xps-7390>
Date:   Sat, 20 Jun 2020 06:46:27 -0700 (PDT)
From:   "Kenneth R. Crudup" <kenny@...ix.com>
To:     Christoph Hellwig <hch@....de>
cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        linux-kernel@...r.kernel.org
Subject: Re: Commit 25f12ae45fc1 ("maccess: rename probe_kernel_address to
 get_kernel_nofault") causing several OOPSes


> > Thing is, there's other examples of the previous version in the kernel tree- any
> > chance there's a usage conflict (Thunderbolt has a ROM in it, maybe something in
> > "probe_roms.c"? (Just guessing, no idea):

On Fri, 19 Jun 2020, Christoph Hellwig wrote:

> Maybe.  But nothing looks strange there.  Just to re-reconfirm, you had to
> revert "maccess: rename probe_kernel_address to get_kernel_nofault",
> "maccess: make get_kernel_nofault() check for minimal type compatibility"
> wasn't enough?

Yeah, the only commit I had to revert was this one. BUT:

> Below is a patch to do a "partial revert" for probe_roms.c.  I'd be
> totally surprised if it changes anything from staring at it for while,
> but anyway..

So, be totally surprised :) I've just booted with "maccess: rename
probe_kernel_address to get_kernel_nofault" intact and your probe_roms.c
patch with no issues.

(Perhaps there's some sort of compiler optimization going on?)

	-Kenny

-- 
Kenneth R. Crudup  Sr. SW Engineer, Scott County Consulting, Orange County CA