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]
Date:   Wed, 5 Aug 2020 15:14:12 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Ilia Lin <ilia.lin@...nel.org>
Cc:     David Miller <davem@...emloft.net>, ilial@...eaurora.org,
        kuba@...nel.org, jiri@...lanox.com, edumazet@...gle.com,
        ap420073@...il.com, xiyou.wangcong@...il.com, maximmi@...lanox.com,
        netdev@...r.kernel.org, open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] net: dev: Add API to check net_dev readiness

> > Well, until the user of this new API is ready, we will not accept the
> > patch.
> OK, but once we submit the change in the driver, is it good to go?

No. You really do need to explain why it is needed, and why it is
safe.

> > You also need to explain "For HW performance reasons". Why is this
> > driver special that it can do things which no over driver does?
> There are very strict KPI requirements. E.g. automotive rear mirror
> must be online 3 sec since boot.

Which does not explain why this driver is special. What you really
should be thinking about is having the required drivers for this use
case built in, and the rest as modules. Get your time critical parts
running, and then load the rest of the driver moduless and kick off
additional user space in a second phase.

You are breaking all sorts of assumptions by loading network drivers
before the stack is ready. You need to expect all sorts of nasty bugs.
If this was just in your vendor kernel, we would not care too much, it
is your problem to solve. But by doing this in mainline, you are
setting a precedent for others to do it as well. And then we really do
need to care about the broken assumptions. I doubt we are ready to
allow this.

      Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ