linux-kernel - Re: [PATCH 12/15] hyperv: move VMBus connection ids to uapi

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]

Message-ID: <20161221095049.6fdc3145@xeon-e3>
Date:   Wed, 21 Dec 2016 09:50:49 -0800
From:   Stephen Hemminger <stephen@...workplumber.org>
To:     Christoph Hellwig <hch@...radead.org>
Cc:     Paolo Bonzini <pbonzini@...hat.com>,
        Roman Kagan <rkagan@...tuozzo.com>,
        Radim Krčmář <rkrcmar@...hat.com>,
        "K. Y. Srinivasan" <kys@...rosoft.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>, kvm@...r.kernel.org,
        "Denis V . Lunev" <den@...nvz.org>,
        Haiyang Zhang <haiyangz@...rosoft.com>, x86@...nel.org,
        linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>, devel@...uxdriverproject.org,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 12/15] hyperv: move VMBus connection ids to uapi

On Wed, 21 Dec 2016 07:43:48 -0800
Christoph Hellwig <hch@...radead.org> wrote:

> On Wed, Dec 21, 2016 at 04:39:18PM +0100, Paolo Bonzini wrote:
> > That said, there are precedents in using UAPI this way for PV
> > interfaces.  See for example include/uapi/linux/virtio*.h and
> > arch/x86/include/uapi/asm/kvm_para.h.  
> 
> We have all kinds of historical examples, but most of them turned
> into a major pain sooner or later - my favourite example are the
> SCSI protocol headers.
> 
> Protocols needs to stay compatible on the (virtual) wire, but not
> on the language level.  Locking us into the strict UABI policies
> for them just make someone life horrible further down the road.

If the the protocols come from external sources (like the current NDIS definitions),
then it is not a big deal. There is some overlap already where NDIS is used multiple
places and there are multiple header files with same definition. That could be
fixed.

The bigger problem is that some of the API's between guest and host could be
implemented multiple ways and don't want userspace ABI files constraining how
something like atomic bit operation for wakeup is done.

The other problem with the hyperv headers is they were initially done with
only the Linux driver usage in mind. This made perfect sense at the time,
the problem is that they mix internal state with protocol definitions.

Lastly, there is licensing issues on headers. It would be good to have any
userspace ABI headers licensed with a more liberal license so that BSD and DPDK drivers
could use them directly. Right now each one reinvents.