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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sun, 2 Aug 2020 14:14:06 -0500
From:   Bjorn Helgaas <>
To:     Borislav Petkov <>
Cc:     Saheed Bolarinwa <>,,
        Kalle Valo <>,
        "David S. Miller" <>,
        Jakub Kicinski <>,
        Wolfgang Grandegger <>,
        Marc Kleine-Budde <>,
        Miquel Raynal <>,
        Richard Weinberger <>,
        Vignesh Raghavendra <>,
        Joerg Roedel <>,,,,,,,,,,,,,,,,,,,,,
Subject: Re: [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value

On Sun, Aug 02, 2020 at 08:46:48PM +0200, Borislav Petkov wrote:
> On Sun, Aug 02, 2020 at 07:28:00PM +0200, Saheed Bolarinwa wrote:
> > Because the value ~0 has a meaning to some drivers and only
> No, ~0 means that the PCI read failed. For *every* PCI device I know.

Wait, I'm not convinced yet.  I know that if a PCI read fails, you
normally get ~0 data because the host bridge fabricates it to complete
the CPU load.

But what guarantees that a PCI config register cannot contain ~0?
If there's something about that in the spec I'd love to know where it
is because it would simplify a lot of things.

I don't think we should merge any of these patches as-is.  If we *do*
want to go this direction, we at least need some kind of macro or
function that tests for ~0 so we have a clue about what's happening
and can grep for it.


Powered by blists - more mailing lists