linux-kernel - Re: [PATCH v4 00/10] riscv: Allow userspace to directly access perf counters

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]

Date:   Tue, 18 Jul 2023 15:48:49 -0700
From:   Atish Patra <atishp@...shpatra.org>
To:     Rémi Denis-Courmont <remi@...lab.net>
Cc:     linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org,
        Aurelien Jarno <aurelien@...el32.net>,
        Mathieu Malaterre <malat@...ian.org>,
        Jan Newger <jannewger@...gle.com>
Subject: Re: [PATCH v4 00/10] riscv: Allow userspace to directly access perf counters

On Tue, Jul 18, 2023 at 12:04 PM Rémi Denis-Courmont <remi@...lab.net> wrote:
>
> Le tiistaina 18. heinäkuuta 2023, 21.45.15 EEST Atish Patra a écrit :
> > > I agree that it's not only insecure but also incorrect. However it mostly
> > > works. In fact I don't disagree with the change as such, but I think that
> > > the commit messages are misleading and confusing. For a start, in one
> > > place it says that it is not breaking user space and in another it says
> > > basically the opposite.
> >
> > Agreed. We will improve the commit message to clarify that. That's also the
> > reason I started this whole thread :)
> >
> > > (Unfortunately, not everybody agrees with the change. I can't seem to get
> > > FFmpeg's checkasm tool fixed:
> > > http://ffmpeg.org/pipermail/ffmpeg-devel/2023-July/312245.html )
> >
> > Why can't rdtime(equivalent of rdtsc) be used instead of rdcycle ?
>
> Isn't RDTIM susceptible to interference from power management and CPU
> frequency scaling? I suppose that RDCYCLE may behave differently depending on
> PM in *some* designs, but that would still be way better than RDTIME for the
> purpose.
>

Yes. But that's what it is probably using for other ISAs ? My point
was it should
just do whatever it does for other ISA. RISC-V is no special in that regard.

> As far as benchmarking is concerned (_excluding_ system security), RDTIME
> seems to have all the problems of RDCYCLE, and then some more, no?
>

Correct. If the application can deal with noisy data, it can use
rdtime similar to
other architectures. Otherwise, it should just use the perf mmap
interface in the beginning
and read the counters whenever required.

> > The perf syscall overhead is just one time setup thing during the
> > start of the application.
> > For counting the cycles before/after a loop, it still provides a
> > direct CSR access in user mode.
>
> I suppose that you allude to mmap() here? The (dumb) FFmpeg code is using the
> ioctl() interface though, but that's just laziness.
>

Yeah. I agree it is more work but just one time effort to get more
reliable data without
compromising the security.

> --
> レミ・デニ-クールモン
> http://www.remlab.net/
>
>
>


-- 
Regards,
Atish