linux-kernel - Re: [PATCH v4 0/2] System Generation ID driver and VMGENID backend

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: <9952EF0C-CD1D-4EDB-BAB8-21F72C0BF90D@amazon.com>
Date:   Thu, 21 Jan 2021 10:28:16 +0000
From:   "Catangiu, Adrian Costin" <acatan@...zon.com>
To:     "Michael S. Tsirkin" <mst@...hat.com>
CC:     "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "qemu-devel@...gnu.org" <qemu-devel@...gnu.org>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "linux-s390@...r.kernel.org" <linux-s390@...r.kernel.org>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "Graf (AWS), Alexander" <graf@...zon.de>,
        "arnd@...db.de" <arnd@...db.de>,
        "ebiederm@...ssion.com" <ebiederm@...ssion.com>,
        "rppt@...nel.org" <rppt@...nel.org>,
        "0x7f454c46@...il.com" <0x7f454c46@...il.com>,
        "borntraeger@...ibm.com" <borntraeger@...ibm.com>,
        "Jason@...c4.com" <Jason@...c4.com>,
        "jannh@...gle.com" <jannh@...gle.com>, "w@....eu" <w@....eu>,
        "MacCarthaigh, Colm" <colmmacc@...zon.com>,
        "luto@...nel.org" <luto@...nel.org>,
        "tytso@....edu" <tytso@....edu>,
        "ebiggers@...nel.org" <ebiggers@...nel.org>,
        "Woodhouse, David" <dwmw@...zon.co.uk>,
        "bonzini@....org" <bonzini@....org>,
        "Singh, Balbir" <sblbir@...zon.com>,
        "Weiss, Radu" <raduweis@...zon.com>,
        "corbet@....net" <corbet@....net>,
        "mhocko@...nel.org" <mhocko@...nel.org>,
        "rafael@...nel.org" <rafael@...nel.org>,
        "pavel@....cz" <pavel@....cz>,
        "mpe@...erman.id.au" <mpe@...erman.id.au>,
        "areber@...hat.com" <areber@...hat.com>,
        "ovzxemul@...il.com" <ovzxemul@...il.com>,
        "avagin@...il.com" <avagin@...il.com>,
        "ptikhomirov@...tuozzo.com" <ptikhomirov@...tuozzo.com>,
        "gil@...l.com" <gil@...l.com>,
        "asmehra@...hat.com" <asmehra@...hat.com>,
        "dgunigun@...hat.com" <dgunigun@...hat.com>,
        "vijaysun@...ibm.com" <vijaysun@...ibm.com>,
        "oridgar@...il.com" <oridgar@...il.com>,
        "ghammer@...hat.com" <ghammer@...hat.com>
Subject: Re: [PATCH v4 0/2] System Generation ID driver and VMGENID backend

On 12/01/2021, 14:49, "Michael S. Tsirkin" <mst@...hat.com> wrote:

    On Tue, Jan 12, 2021 at 02:15:58PM +0200, Adrian Catangiu wrote:
    > The first patch in the set implements a device driver which exposes a
    > read-only device /dev/sysgenid to userspace, which contains a
    > monotonically increasing u32 generation counter. Libraries and
    > applications are expected to open() the device, and then call read()
    > which blocks until the SysGenId changes. Following an update, read()
    > calls no longer block until the application acknowledges the new
    > SysGenId by write()ing it back to the device. Non-blocking read() calls
    > return EAGAIN when there is no new SysGenId available. Alternatively,
    > libraries can mmap() the device to get a single shared page which
    > contains the latest SysGenId at offset 0.

    Looking at some specifications, the gen ID might actually be located
    at an arbitrary address. How about instead of hard-coding the offset,
    we expose it e.g. in sysfs?

The functionality is split between SysGenID which exposes an internal u32
counter to userspace, and an (optional) VmGenID backend which drives
SysGenID generation changes based on hw vmgenid updates.

The hw UUID you're referring to (vmgenid) is not mmap-ed to userspace or
otherwise exposed to userspace. It is only used internally by the vmgenid
driver to find out about VM generation changes and drive the more generic
SysGenID.

The SysGenID u32 monotonic increasing counter is the one that is mmaped to
userspace, but it is a software counter. I don't see any value in using a dynamic
offset in the mmaped page. Offset 0 is fast and easy and most importantly it is
static so no need to dynamically calculate or find it at runtime.

Thanks,
Adrian.




Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005.