linux-kernel - Re: [PATCH v4 02/24] powerpc/pseries: Fix alignment of PLPKS structures and buffers

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: <871qngtfkg.fsf@mpe.ellerman.id.au>
Date:   Fri, 27 Jan 2023 21:52:31 +1100
From:   Michael Ellerman <mpe@...erman.id.au>
To:     Segher Boessenkool <segher@...nel.crashing.org>
Cc:     Andrew Donnellan <ajd@...ux.ibm.com>,
        linuxppc-dev@...ts.ozlabs.org, linux-integrity@...r.kernel.org,
        sudhakar@...ux.ibm.com, bgray@...ux.ibm.com, erichte@...ux.ibm.com,
        gregkh@...uxfoundation.org, nayna@...ux.ibm.com,
        linux-kernel@...r.kernel.org, zohar@...ux.ibm.com,
        gjoyce@...ux.ibm.com, joel@....id.au, ruscur@...sell.cc,
        gcwilson@...ux.ibm.com
Subject: Re: [PATCH v4 02/24] powerpc/pseries: Fix alignment of PLPKS
 structures and buffers

Segher Boessenkool <segher@...nel.crashing.org> writes:
> On Thu, Jan 26, 2023 at 12:09:53AM +1100, Michael Ellerman wrote:
>> Andrew Donnellan <ajd@...ux.ibm.com> writes:
>> > A number of structures and buffers passed to PKS hcalls have alignment
>> > requirements, which could on occasion cause problems:
>> >
>> > - Authorisation structures must be 16-byte aligned and must not cross a
>> >   page boundary
>> >
>> > - Label structures must not cross page boundaries
>> >
>> > - Password output buffers must not cross page boundaries
>> >
>> > Round up the allocations of these structures/buffers to the next power of
>> > 2 to make sure this happens.
>> 
>> It's not the *next* power of 2, it's the *nearest* power of 2, including
>> the initial value if it's already a power of 2.
>
> It's not the nearest either, the nearest power of two to 65 is 64.  You
> could say "but, round up" to which I would say "round?"  :-P

OK you got me there :)

The function name makes it pretty clear that it will round *up* to the
nearest power of 2 but you're right the comment should also make that
clear.

> "Adjust the allocation size to be the smallest power of two greater than
> or equal to the given size."
>
> "Pad to a power of two" in shorthand.  "Padded to a power of two if
> necessary" if you want to emphasise it can be a no-op.

The initial wording implied that it would always over-allocate so yes I
think it's important to make it clear that it doesn't round up if it
doesn't need to.

cheers