linux-kernel - Re: [patch V2.1 05/20] x86/extable: Rework the exception table mechanics

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] [day] [month] [year] [list]

Message-ID: <87y28883hq.ffs@tglx>
Date:   Tue, 07 Sep 2021 23:44:49 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        the arch/x86 maintainers <x86@...nel.org>,
        Al Viro <viro@...iv.linux.org.uk>,
        Tony Luck <tony.luck@...el.com>,
        Song Liu <songliubraving@...com>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Peter Ziljstra <peterz@...radead.org>
Subject: Re: [patch V2.1 05/20] x86/extable: Rework the exception table
 mechanics

Linus,

On Tue, Sep 07 2021 at 13:37, Linus Torvalds wrote:
> On Tue, Sep 7, 2021 at 1:24 PM Thomas Gleixner <tglx@...utronix.de> wrote:
>>
>> Rework the exception fixup mechanics by storing a fixup type number instead
>> of the handler address and invoke the proper handler for each fixup
>> type. Also teach the extable sort to leave the type field alone.
>
> I see why you do this, but it does make the exception handlers less
> flexible. It used to be that you could just make up any exception
> handler without having to inform some centralized place about it.
>
> But I guess that's also a downside, and maybe we don't want the extra
> flexibility.
>
> The bpf case was an example where somebody was able to add their own
> specialized handler, and didn't need to serialize with anybody else.

Yes, I'm aware of that downside. OTOH, the need for special handlers is
rare and not something which happens every other day. Being able to have
more fine granular types without adding a zoo of new handlers seems to
be more useful to me.

> So I don't hate this, I'm just ambivalent about it. On the one hand I
> like the more strict format, on the other hand it's kind of sad.

Yes, but one thing I learned in almost 20 years of maintainership is
that being strict about stuff is absolutely not the worst choice. People
tend to be think that their problem is special - most of the time for
the very wrong reasons - and just add magic crap left and right because
they can. Making the rules more strict forces them to think at least a
bit harder - most of the time with the wrong outcome which is especially
true for out of tree crap, sigh...

> The other reaction I have is that the handler type is now wasteful and
> pointless. I think you could make it be about which *section* the
> exception thing is in, and not need that extra ".long" argument to
> hold a couple of bits of data.
>
> So _ASM_EXTABLE_TYPE() could instead do something like this:
>
>   # define _ASM_EXTABLE_TYPE(from, to, type)                     \
>           .pushsection "__ex_table." #type ,"a" ;                         \
>           .balign 4 ;                                             \
>           .long (from) - . ;                                      \
>           .long (to) - . ;                                        \
>           .popsection
>
> and we'd not have any 'type' field in there at all, because the type
> would be determined by the section is is in.
>
> Hmm?

I actually thought about that, but then I looked at the total extable
storage size of about 6k with a distro config build which in turn made
my lazy alter ego decide that spending the time necessary to teach all
the related code about subsections is better spent for my woodworking
projects and garden fountain experiments.

Thanks,

        tglx