linux-kernel - Re: [RFC PATCH 5/8] mm: Take placement mappings gap into account

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: <b4ecace8453fbff4f6af5799896d75db84afaea4.camel@intel.com>
Date: Tue, 20 Feb 2024 16:48:52 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>
CC: "debug@...osinc.com" <debug@...osinc.com>, "luto@...nel.org"
	<luto@...nel.org>, "x86@...nel.org" <x86@...nel.org>,
	"Liam.Howlett@...cle.com" <Liam.Howlett@...cle.com>, "broonie@...nel.org"
	<broonie@...nel.org>, "keescook@...omium.org" <keescook@...omium.org>,
	"bp@...en8.de" <bp@...en8.de>, "mingo@...hat.com" <mingo@...hat.com>,
	"tglx@...utronix.de" <tglx@...utronix.de>, "akpm@...ux-foundation.org"
	<akpm@...ux-foundation.org>, "linux-mm@...ck.org" <linux-mm@...ck.org>,
	"peterz@...radead.org" <peterz@...radead.org>, "hpa@...or.com"
	<hpa@...or.com>, "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 5/8] mm: Take placement mappings gap into account

On Fri, 2024-02-16 at 17:11 -0800, Rick Edgecombe wrote:
> > Do we care to check if alignment itself would satisfy start_gap
> > requirement?
> 
> Ugh, I think actually the alignment stuff clobbers the guard gap in
> the
> search up scenario. I'm also seeing some weird results as I throw
> test
> values into the existing logic, but very likely I just need to look
> at
> this not late on a Friday. Thanks for pointing it out.

Ok, playing around with the address adjustment math in a separate test
program, I think it is all ok functionally. But there are two gotchas:

1. The existing math for search up assumes that the requested length is
bigger than the alignment mask. If the length is smaller, non-
cannonical addresses can result (more than ->high_limit). I don't think
any callers can call with this combination so it's fine functionally.

2. The newly added code can only hit the scenario you highlight if the
start gap is more than the alignment size. If alignment mask is more
than the start gap, the alignment will only shift the address more than
the adjustment made for the start gap.

So if it skips the start gap adjustment in the case of alignment adding
the necessary gap it won't change the result and just add a branch.
Similarly, if the start gap fulfills the alignment, there is no
adjustment during the alignment step.

I think maybe I'll add a comment covering both gotchas and leave the
logic as is, unless there are any objections. Or maybe a VM_WARN_ON,
hmm.