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:   Wed, 28 Jun 2023 15:25:26 +0200
From:   Lukas Wunner <lukas@...ner.de>
To:     Smita Koralahalli <Smita.KoralahalliChannabasappa@....com>
Cc:     linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
        Bjorn Helgaas <bhelgaas@...gle.com>, oohall@...il.com,
        Mahesh J Salgaonkar <mahesh@...ux.ibm.com>,
        Kuppuswamy Sathyanarayanan 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        Yazen Ghannam <yazen.ghannam@....com>,
        Fontenot Nathan <Nathan.Fontenot@....com>,
        Jay Cornwall <Jay.Cornwall@....com>,
        Felix Kuehling <Felix.Kuehling@....com>
Subject: Re: [PATCH v3 2/2] PCI: pciehp: Clear the optional capabilities in
 DEVCTL2 on a hot-plug

On Tue, Jun 27, 2023 at 10:38:54AM -0700, Smita Koralahalli wrote:
> Okay, I see there are no objections except for Bjorn/Jay's comments on
> 
> "But there could be devices where AtomicOps are nominally supported but
> untested or broken.."
> 
> Would this be an issue?

I think you said that BIOS enables AtomicOps on certain AMD machines?
Or did that observation only apply to 10 Bit tags?

If BIOS does enable AtomicOps, it would be interesting to know which
logic BIOS follows, i.e. how does it determine whether to set
AtomicOp Requester Enable on Endpoints?

It would also be interesting to know how far that BIOS has proliferated,
i.e. how much experience with various Endpoint devices exists in the
real world.  If it turns out that BIOS has enabled the feature for
years on a wide range of Endpoints without any issues, I think
that would render concerns mute that enabling it in the kernel
might cause regressions.

I don't know why the spec says that "discovery of AtomicOp Requester
capabilities is outside the scope of this specification".  I imagine
it would be possible to set AtomicOp Requester Enable, then read it
to determine whether the bit is now indeed 1 or hard-wired to 0.
In the latter case, AtomicOp Requester capabilities can be assumed
to be absent.  So that would be a way to make do without any other
specific discovery of AtomicOp Requester capabilities.

Thanks,

Lukas

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ