linux-kernel - Re: [Patch v3 2/3] Drivers: hv: add Azure Blob driver

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:   Thu, 15 Jul 2021 10:19:26 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Long Li <longli@...rosoft.com>
Cc:     "longli@...uxonhyperv.com" <longli@...uxonhyperv.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
        Jonathan Corbet <corbet@....net>,
        KY Srinivasan <kys@...rosoft.com>,
        Haiyang Zhang <haiyangz@...rosoft.com>,
        Stephen Hemminger <sthemmin@...rosoft.com>,
        Wei Liu <wei.liu@...nel.org>, Dexuan Cui <decui@...rosoft.com>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Hans de Goede <hdegoede@...hat.com>,
        "Williams, Dan J" <dan.j.williams@...el.com>,
        Maximilian Luz <luzmaximilian@...il.com>,
        Mike Rapoport <rppt@...nel.org>,
        Ben Widawsky <ben.widawsky@...el.com>,
        Jiri Slaby <jirislaby@...nel.org>,
        Andra Paraschiv <andraprs@...zon.com>,
        Siddharth Gupta <sidgup@...eaurora.org>,
        Hannes Reinecke <hare@...e.de>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>
Subject: Re: [Patch v3 2/3] Drivers: hv: add Azure Blob driver

On Wed, Jul 14, 2021 at 09:14:13PM +0000, Long Li wrote:
> > Subject: Re: [Patch v3 2/3] Drivers: hv: add Azure Blob driver
> > 
> > On Tue, Jul 13, 2021 at 07:45:21PM -0700, longli@...uxonhyperv.com wrote:
> > > From: Long Li <longli@...rosoft.com>
> > >
> > > Azure Blob storage provides scalable and durable data storage for Azure.
> > >
> > (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fazu
> > > re.microsoft.com%2Fen-
> > us%2Fservices%2Fstorage%2Fblobs%2F&amp;data=04%7
> > >
> > C01%7Clongli%40microsoft.com%7C950a81a410c54c2475a308d946ec0c09%7C
> > 72f9
> > >
> > 88bf86f141af91ab2d7cd011db47%7C1%7C0%7C637618801920394272%7CUnk
> > nown%7C
> > >
> > TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL
> > CJXVC
> > >
> > I6Mn0%3D%7C1000&amp;sdata=iLDP6EYsoCDlLvToJB31hIQxW3NdCnR0UH31
> > FRDwvRI%
> > > 3D&amp;reserved=0)
> > >
> > > This driver adds support for accelerated access to Azure Blob storage.
> > > As an alternative to REST APIs, it provides a fast data path that uses
> > > host native network stack and secure direct data link for storage server
> > access.
> > 
> > So it goes around the block layer?  Why?
> 
> Azure Blob is object-oriented storage solution designed for cloud environments.
> While it's entirely possible to go through block layer, it's not as efficient as using
> its native APIs for data access. Some of the security features (authentication, 
> tokens, lifecycle management) are not easily integrated into block layer. The
> object model in Azure Blob is designed to be scalable and doesn't have many
> limitations that block layer enforces (e.g. number of sectors).

What does the kernel's filesystem and block developers and maintainers
think about this end-run around that subsystem?  Do they agree with this
one-off-custom-ioctl api?  Who has reviewed this api to assure you that
it is sane and actually works properly?

And are you sure that the block layer is not efficient?  You just lost
all use of caching and io_uring and loads of other kernel infrastructure
that has been developed and relied on for decades.  You also just
abandoned the POSIX model and forced people to use a
random-custom-library just to access their storage devices, breaking all
existing programs in the world.

What programs today use this new api?  Where is the api published and
what ensures that it will remain stable?  What happens when it changes
over time, do we have to rebuild all userspace applications?  What
happens to the kernel code over time, how do you handle changes to the
api there?

You are going to need a lot of people to agree that this is ok to
circumvent in order to allow this to be accepted, have you done that
yet?

> Please refer to this link for different storage models in Azure:
> https://docs.microsoft.com/en-us/azure/storage/common/storage-introduction#core-storage-services

Links are not good for changelogs as the kernel changelog is for
forever, while random company urls we have no control over.

thanks,

greg k-h