linux-kernel - Re: [PATCH v6 02/13] user_events: Add minimal support for trace

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: <20211209201112.GB21676@kbox>
Date:   Thu, 9 Dec 2021 12:11:12 -0800
From:   Beau Belgrave <beaub@...ux.microsoft.com>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     mhiramat@...nel.org, linux-trace-devel@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 02/13] user_events: Add minimal support for
 trace_event into ftrace

On Thu, Dec 09, 2021 at 02:57:38PM -0500, Steven Rostedt wrote:
> On Thu, 9 Dec 2021 11:42:35 -0800
> Beau Belgrave <beaub@...ux.microsoft.com> wrote:
> 
> > User program task:
> > CPU0: ioctl(fd, REG)
> > CPU1: close(fd)
> > 
> > IE: Some program registers and then immediately calls close on the file.
> > If the CPU migrates right between the 2 and the close swaps, it is
> > possible this could occur.
> > 
> > This could be attempted in tight loops maliciously as well.
> > 
> > I assume with a mutex there that some barrier is imposed to ensure
> > correct reads in this condition? (By virtue of the mutex acquire/check)
> 
> But as I stated before, the ioctl() uses fdget() which will prevent he
> close from calling the release. Even if they get swapped. If close goes
> first and starts down the path of the release, then the ioctl is guaranteed
> to return -EBADF. If it gets the fd, then close will be a nop, and the exit
> of the ioctl will call the release.
> 
> If this wasn't the case, then the race I was concerned about would be an
> issue.
> 
> Because we are both confused by this, add the mutex! :-)
> 
> -- Steve

Agreed, I will add the mutex. :)

I guess I am being paranoid about an architecture that does not have
automatic cache consistency and while the write / read don't happen at
the exact time, they happen close together. Close enough that one CPU
reads the old value from a cache line and gets it wrong.

I don't believe that is possible on Intel, but I don't know if it's
possible on other architectures (especially older ones).

Thanks,
-Beau