linux-kernel - Re: [PATCH 4/4] PCI/sysfs: Allow userspace to query and set device reset mechanism

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:   Fri, 19 Mar 2021 14:48:12 +0100
From:   "Enrico Weigelt, metux IT consult" <info@...ux.net>
To:     Leon Romanovsky <leon@...nel.org>,
        "Enrico Weigelt, metux IT consult" <info@...ux.net>
Cc:     Alex Williamson <alex.williamson@...hat.com>,
        Amey Narkhede <ameynarkhede03@...il.com>,
        raphael.norwitz@...anix.com, linux-pci@...r.kernel.org,
        bhelgaas@...gle.com, linux-kernel@...r.kernel.org,
        alay.shah@...anix.com, suresh.gumpula@...anix.com,
        shyam.rajendran@...anix.com, felipe@...anix.com
Subject: Re: [PATCH 4/4] PCI/sysfs: Allow userspace to query and set device
 reset mechanism

On 19.03.21 13:59, Leon Romanovsky wrote:

>> I really doubt we can influence that by any technical decision here in
>> the kernel.
> 
> There are subsystems that succeeded to do it, for example netdev, RDMA e.t.c.

I'd guess either hi-end / server or embedded products - already
mentioned that these are different fields. I've been talking about the
average consumer products.

OTOH, there're also very expensive vendors that are exceptionally bad,
eg. National instruments (who even are capable of breaking rpm so badly
with their proprietary packages that they open up 0day holes - i once
filed a report @FD on such a case).

>> IMHO, the expensive ones don't care either.
>>
>> Does eg. Dell publish board schematics ? Do they even publish exact part
>> lists (exact chipsets) along with their brochures, so customers can
>> check wether their HW is supported, before buying and trying out ?
> 
> They do it because they are allowed to do it and not because they
> explicitly want to annoyance their customers.

Yes, they're just ignorant. They can still do that, because buy their
pretty expensive cheap-hardware. And that's mostly driven by purchase
people inside the customer organisations, who just don't care how much
damage they do to their own employers, by dictating purchase of
expensive broken-by-design hardware. ... but that's nothing we here have
any influence on - except for dissuasion and purchase boycott ...

In any case, I still fail to see why giving operators an debug knob
should make anything worse.

>> [ And often, even a combination of them isn't enough. Did you know that
>>    even Google doesn't get all specs necessary to replace away the ugly
>>    FSP blob ? (it's the same w/ AMD, but meanwhile I'm pissed enought to
>>    reverse engineer their AGESA blob). ]
> 
> I don't know about this specific Google case, but from my previous experience.
> The reasons why vendor says no to Google are usually due to licensing and legal
> issues and not open source vs. proprietary.

In short words: Google did (still does?) build their own mainboards and
FW (IIRC that's where LinuxBoot came from), but even with their HUGE
quantities (they buy cpus in quantities of truck loads) they still did
not manage to get any specs for writing their own early init w/o the
proprietary FSP.

The licensing / legal issues can either be:

a) we, the mightly Intel Corp., have been so extremly stupid for
    licensing some vital IP stuff (what exactly could that be, in exactly
    the prime domain of Intel ?) and signing such insane crontracts, that
    we're not allowed to tell anybody how to actually use our own
    products (yes: initializing the CPU and built-in interfaces belongs
    exactly into that category)
b) we, the mighty Intel Corp., couldn't build something on our own, but
    just stolen IP (in our primary domain) and are scared that anybody
    could find out from just reading some early setup code.
c) we, the mighty Intel Corp., rule the world and we give a phrack on
    what some tiny Customers like Google want from us.
d) we, the mightly Intel Corp., did do what our name tells: INTEL,
    and we don't want anybody raise unpleasant questions.

choose your poison :P

--mtx

-- 
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@...ux.net -- +49-151-27565287