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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 18 Sep 2020 13:40:44 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Arvind Sankar <nivedita@...m.mit.edu>
Cc:     Matthew Wilcox <willy@...radead.org>,
        "Gustavo A. R. Silva" <gustavoars@...nel.org>,
        Dennis Zhou <dennis@...nel.org>, Tejun Heo <tj@...nel.org>,
        Christoph Lameter <cl@...ux.com>,
        Linux-MM <linux-mm@...ck.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Kees Cook <keescook@...omium.org>
Subject: Re: [GIT PULL] percpu fix for v5.9-rc6

On Fri, Sep 18, 2020 at 1:29 PM Arvind Sankar <nivedita@...m.mit.edu> wrote:
>
> In general (i.e. outside the implementation of the macro itself), what
> is the preferred way of getting the size of just the header?
>   1) offsetof(typeof(s),flex)
>   2) struct_size(s, flex, 0)

I think those two should end up being equivalent.

>   3) sizeof(s)

This works right now, but exactly *because* it works, we're not seeing
the questionable cases.

Of course, _also_ exactly because it just silently works, I also don't
know if there may be thousands of perfectly fine uses where people
really do want the header, and a "sizeof()" is simpler than
alternatives 1-2.

It's possible that there really are a lot of "I want to know just the
header size" cases. It sounds odd, but I could _imagine_ situations
like that, even though no actual case comes to mind.

>   4) new macro that's easier to read than 1 or 2, but makes it clear
>      what you're doing?

I don't think this would have any real advantage, would it?

Now what might be good is if we can make "struct_size()" also actually
verify that the member that is passed in is that last non-sized
member. I'm not sure how to do that.

I know how to check that it's *not* that last unsized member (just do
"sizeof(s->flex)", and it should error), but I don't see how to assert
the reverse of that).

Because that kind of "yes, we actually pass in the right member" check
would be good to have too.

              Linus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ