linux-kernel - Re: [PATCH v3 10/16] ipmi: kcs_bmc: Don't enforce single-open policy in the kernel

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:   Mon, 24 May 2021 10:09:22 +0930
From:   "Andrew Jeffery" <andrew@...id.au>
To:     "Corey Minyard" <minyard@....org>
Cc:     openipmi-developer@...ts.sourceforge.net, openbmc@...ts.ozlabs.org,
        devicetree@...r.kernel.org, "Tomer Maimon" <tmaimon77@...il.com>,
        linux-aspeed@...ts.ozlabs.org,
        "Avi Fishman" <avifishman70@...il.com>,
        "Patrick Venture" <venture@...gle.com>,
        linux-kernel@...r.kernel.org, "Tali Perry" <tali.perry1@...il.com>,
        "Rob Herring" <robh+dt@...nel.org>,
        "Chia-Wei, Wang" <chiawei_wang@...eedtech.com>,
        linux-arm-kernel@...ts.infradead.org,
        "Benjamin Fair" <benjaminfair@...gle.com>,
        "Arnd Bergmann" <arnd@...db.de>, "Zev Weiss" <zweiss@...inix.com>
Subject: Re: [PATCH v3 10/16] ipmi: kcs_bmc: Don't enforce single-open policy in the kernel



On Sat, 22 May 2021, at 03:00, Corey Minyard wrote:
> On Mon, May 10, 2021 at 03:12:07PM +0930, Andrew Jeffery wrote:
> > Soon it will be possible for one KCS device to have multiple associated
> > chardevs exposed to userspace (for IPMI and raw-style access). However,
> > don't prevent userspace from:
> > 
> > 1. Opening more than one chardev at a time, or
> > 2. Opening the same chardev more than once.
> > 
> > System behaviour is undefined for both classes of multiple access, so
> > userspace must manage itself accordingly.
> 
> I don't understand why you want to allow this.  If the second open won't
> work right, then why allow it?  Why remove code that causes the second
> open to error?

Really I was just shifting the problem to userspace so it wasn't 
something I needed to address in the kernel. It seems I'm alone in 
thinking this is a good idea, as yourself, Zev, William and Joel 
(privately) have pushed back against it. Initially the idea was tied up 
in how I was doing some interrupt handling, but in revising the code 
that problem has gone away.

I'll just drop this patch and save everyone the heartburn of arguing 
about it :)

Andrew