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]
Date:   Mon, 2 Oct 2023 15:22:17 +0200
From:   Ingo Molnar <mingo@...nel.org>
To:     Uros Bizjak <ubizjak@...il.com>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>, x86@...nel.org,
        linux-kernel@...r.kernel.org, Andy Lutomirski <luto@...nel.org>,
        Nadav Amit <namit@...are.com>, Brian Gerst <brgerst@...il.com>,
        Denys Vlasenko <dvlasenk@...hat.com>,
        "H . Peter Anvin" <hpa@...or.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Borislav Petkov <bp@...en8.de>,
        Josh Poimboeuf <jpoimboe@...hat.com>
Subject: Re: [RFC PATCH 0/4] x86/percpu: Use segment qualifiers


* Uros Bizjak <ubizjak@...il.com> wrote:

> > > Clang isn't much better, but at least it doesn't generate bad code. It
> > > just crashes with an internal compiler error on the above trivial
> > > test-case:
> > >
> > >     fatal error: error in backend: cannot lower memory intrinsic in
> > > address space 257
> > >
> > > which at least tells the user that they can't copy memory from that
> > > address space. But once again shows that no, this feature is not ready
> > > for prime-time.
> > >
> > > If literally the *first* thing I thought to test was this broken, what
> > > else is broken in this model?
> > >
> > > And no, the kernel doesn't currently do the above kinds of things.
> > > That's not the point. The point was "how well is this compiler support
> > > tested". The answer is "not at all".
> 
> I don't agree with the above claims. The generated code was the product 
> of a too limited selection of available copy algorithms in unusual 
> circumstances, but even in the case of generic fallback code, the 
> generated code was *correct*. As said in the previous post, and 
> re-confirmed by the patch in the PR, the same code in GCC handles 
> implicit (__thread) and named address spaces. At the end of the day, the 
> problematic code was merely a missing-optimization (the bug with the 
> lowest severity in GCC).

Yeah, so the feature generated really crappy code for Linus's
testcase. That's never a good sign for compiler features, full stop.

Do we want the kernel to be at the bleeding edge of an 
unusual compiler feature that is only used internally by the
compiler in a very specific fashion?

Maybe, but Linus's reluctance and caution is justified IMHO,
and at minimum this feature needs some careful evaluation of 
long-time suitability [*] ...

Thanks,

	Ingo


[*] euphemism for: "I have no idea how to evaluate this risk"... :-/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ