linux-kernel - Re: [PATCH v7] drivers/staging: Gasket driver framework + Apex 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] [day] [month] [year] [list]

Message-ID: <20180630150746.38d69e92@alans-desktop>
Date:   Sat, 30 Jun 2018 15:07:46 +0100
From:   Alan Cox <gnomes@...rguk.ukuu.org.uk>
To:     Simon Que <sque@...omium.org>
Cc:     linux-kernel@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Ben Chan <benchan@...omium.org>,
        Chun-Ta Lin <itspeter@...omium.org>,
        Zhongze Hu <frankhu@...omium.org>,
        Joe Perches <joe@...ches.com>,
        Randy Dunlap <rdunlap@...radead.org>,
        Rob Springer <rspringer@...gle.com>,
        John Joseph <jnjoseph@...gle.com>, linux-fpga@...nel.org
Subject: Re: [PATCH v7] drivers/staging: Gasket driver framework + Apex
 driver

> The Gasket (Google ASIC Software, Kernel Extensions, and Tools) kernel
> framework is a generic, flexible system that supports thin kernel
> drivers. Gasket kernel drivers are expected to handle opening and
> closing devices, mmap'ing BAR space as requested, a small selection of
> ioctls, and handling page table translation (covered below). Any other
> functions should be handled by userspace code.

So it seems to me that we shouldn't have one random layer for Google
ASIC, another chunk of code for FPGA and so on. This all really ought to
be unified including where possible making things meaningfully self
describe.

You also don't seem to consider partitioning of an ASIC, eg if it
implements a serial port abstraction for debug that ought to routed to
the kernel, nor how to handle an ASIC that provides services to multiple
consumers ?

> One of the core assumptions of the Gasket framework is that precisely
> one process is allowed to have an open write handle to the device node
> at any given time. (That process may, once it has one write handle, open

Why ? That's a very un-Linuxlike and un-Unixlike model. It's more like
Windows and with all the problems we know that model causes.

> any number of additional write handles.) This is accomplished by
> tracking open and close data for each driver instance.

What if I want to have multiple threads not sharing an mm, or pass an
ASIC by handle to another instance - eg if I have a master process
assigning resources wanting to pass a handle into a container ?

And what about fd passing ?

It seems completely weird to try and do this given I can (given
permissions) equally just ptrace the person with it open and use ptrace
as a multiplexor ???

Also how about pointers to a real world use case example and user space ?

Alan