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: <1dbc9402-5baf-4a92-96b3-8b3a9c108f01@intel.com>
Date:   Mon, 6 Feb 2023 09:10:53 -0800
From:   Dave Hansen <dave.hansen@...el.com>
To:     Jakob Koschel <jkl820.git@...il.com>,
        Jarkko Sakkinen <jarkko@...nel.org>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        x86@...nel.org, "H. Peter Anvin" <hpa@...or.com>
Cc:     linux-sgx@...r.kernel.org, linux-kernel@...r.kernel.org,
        Pietro Borrello <borrello@...g.uniroma1.it>,
        Cristiano Giuffrida <c.giuffrida@...nl>,
        "Bos, H.J." <h.j.bos@...nl>
Subject: Re: [PATCH] x86/sgx: Avoid using iterator after loop in
 sgx_mmu_notifier_release()

On 2/6/23 02:39, Jakob Koschel wrote:
> If &encl_mm->encl->mm_list does not contain the searched 'encl_mm',
> 'tmp' will not point to a valid sgx_encl_mm struct.
> 
> Since the code within the guarded block is just called when the element
> is found, it can simply be moved into the list iterator.
> Within the list iterator 'tmp' is guaranteed to point to a valid
> element.
> 
> Signed-off-by: Jakob Koschel <jkl820.git@...il.com>
> ---
> Linus proposed to avoid any use of the list iterator variable after the
> loop, in the attempt to move the list iterator variable declaration into
> the marcro to avoid any potential misuse after the loop.
> Using it in a pointer comparision after the loop is undefined behavior
> and should be omitted if possible [1].

I think there's a big difference between "undefined behavior" and
"someone wants to flip a switch to *make* this undefined behavior".  My
understanding is that this patch avoids behavior which _is_ defined today.

Is there some effort to change this behavior across the tree that I missed?

In any case, this patch also kinda breaks the rule that you're supposed
to make the common path through the code at the lowest nesting level.
It makes the common case look like some kind of error handling.  Would
something like the attached patch work?
View attachment "sgxmm.patch" of type "text/x-patch" (900 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ