linux-kernel - Re: Correct commit mask for page data size

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]

Date:   Fri, 24 May 2019 07:04:11 -0700
From:   Jason Behmer <jbehmer@...gle.com>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Craig Barabas <craigbarabas@...gle.com>,
        linux-kernel@...r.kernel.org
Subject: Re: Correct commit mask for page data size

Yup, that makes sense, thanks for the response.


On Thu, May 23, 2019 at 7:54 PM Steven Rostedt <rostedt@...dmis.org> wrote:
>
> On Mon, 1 Apr 2019 06:49:07 -0700
> Jason Behmer <jbehmer@...gle.com> wrote:
>
> Hi Jason,
>
> I just noticed this email. I know it's a late response, but since you
> Cc'd LKML, I figured I would respond anyway, and at least have an
> answer in the archives ;-)
>
> > Hi Steven,
> > We're wondering what the correct number of bits to take from the
> > commit field is when determining the size of the page data.  The
> > format file shows the bottom 56 bits not overlapping with anything:
> >
> >         field: local_t commit;  offset:8;       size:8; signed:1;
> >         field: int overwrite;   offset:8;       size:1; signed:1;
> >
> > We first naively interpreted this as the size, but eventually ran into
> > cases where this gave back a nonsense result.  But then in our
> > investigation of what the correct thing to do is, we found conflicting
> > answers.
>
> Yeah, I hated that above, but the format didn't have a good way to show
> the overwrite without breaking existing tools :-/
>
> >
> > In the kernel we see that commit is often updated to write, which is
> > masked against RB_WRITE_MASK.  So it seems taking the bottom 20 bits
> > is correct.  However, in trace-cmd, a fairly authoritative parser, we
> > see that COMMIT_MASK is set to take the bottom 27 bits and set that to
> > the page data size.
>
> The way the kernel uses that number is that the first 20 bits are the
> size. Then we have an internal counter (top 12 bits) used for
> synchronizing when the trace crosses pages. But these internal numbers
> will never be exposed when it is sent off to the reader. Hence, those
> bits are meaningless.
>
> Now I probably could make the trace-cmd header just use those 20 bits,
> as they never will be used for the size. When I wrote that, I just made
> sure that the flags that are added to the page by the reader code was
> not set. Which is why there is a discrepancy between the two masks.
> >
> > Could you provide some guidance?
>
> Thanks for pointing this out. Again, the reason for the difference is
> that they were created from two different perspectives. One was that it
> would use the top 12 bytes for internal purposes, the other was just to
> allow for up to 5 flags by the reader.
>
> Does that make sense?
>
> -- Steve
>