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]
Message-ID: <OSBPR01MB2037621D4E6E65832DD9C95D80BA9@OSBPR01MB2037.jpnprd01.prod.outlook.com>
Date:   Thu, 30 Jun 2022 09:43:36 +0000
From:   "tarumizu.kohei@...itsu.com" <tarumizu.kohei@...itsu.com>
To:     'Dave Hansen' <dave.hansen@...el.com>,
        Linus Walleij <linus.walleij@...aro.org>
CC:     Greg KH <gregkh@...uxfoundation.org>,
        "catalin.marinas@....com" <catalin.marinas@....com>,
        "will@...nel.org" <will@...nel.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "bp@...en8.de" <bp@...en8.de>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "x86@...nel.org" <x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>,
        "rafael@...nel.org" <rafael@...nel.org>,
        "lenb@...nel.org" <lenb@...nel.org>,
        "mchehab+huawei@...nel.org" <mchehab+huawei@...nel.org>,
        "eugenis@...gle.com" <eugenis@...gle.com>,
        "tony.luck@...el.com" <tony.luck@...el.com>,
        "pcc@...gle.com" <pcc@...gle.com>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "marcos@...a.pet" <marcos@...a.pet>,
        "marcan@...can.st" <marcan@...can.st>,
        "nicolas.ferre@...rochip.com" <nicolas.ferre@...rochip.com>,
        "conor.dooley@...rochip.com" <conor.dooley@...rochip.com>,
        "arnd@...db.de" <arnd@...db.de>, "ast@...nel.org" <ast@...nel.org>,
        "peter.chen@...nel.org" <peter.chen@...nel.org>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
        Paolo Valente <paolo.valente@...more.it>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: RE: [PATCH v5 0/6] Add hardware prefetch control driver for A64FX and
 x86

Hi Dave,

> They run their fortran app.  Change the MSRs.  Run it again.  See if it
> simulated the nuclear weapon blast any faster or slower.  Rinse.  Repeat.
> 
> One thing that is missing from the changelog and cover letter here: On x86,
> there's a 'wrmsr(1)' tool.  That took pokes at Model Specific Registers (MSRs)
> via the /dev/cpu/X/msr interface.  That interface is a very, very thinly-veiled
> wrapper around the WRMSR (WRite MSR) instruction.
> 
> In other words, on x86, our current interface allows userspace programs to
> arbitrarily poke at our most sensitive hardware configuration registers.  One of
> the most common reasons users have reported doing this (we have
> pr_warn()ings about it) is controlling the prefetch hardware.
> 
> This interface would take a good chunk of the x86 wrmsr(1) audience and
> convert them over to a less dangerous interface.  That's a win on x86.
> We don't even *remotely* have line-of-sight for a generic solution for the kernel
> to figure out a single "best" value for these registers.

Thank you for mentioning wrmsr tool.

This is one of the reason why I want to add the sysfs interface. I
will add the description that this interface can be used instead of
wrmsr tool (or MSR driver) for hardware prefetch control usage to the
cover letter.

I read below that we should not accesse any MSR directly from
userspace without restriction.
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/about/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ