[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20200325.193056.1153970692429454819.davem@davemloft.net>
Date: Wed, 25 Mar 2020 19:30:56 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: longman@...hat.com
Cc: dhowells@...hat.com, jarkko.sakkinen@...ux.intel.com,
jmorris@...ei.org, serge@...lyn.com, zohar@...ux.ibm.com,
kuba@...nel.org, keyrings@...r.kernel.org,
linux-kernel@...r.kernel.org,
linux-security-module@...r.kernel.org,
linux-integrity@...r.kernel.org, netdev@...r.kernel.org,
linux-afs@...ts.infradead.org, sumit.garg@...aro.org,
jsnitsel@...hat.com, roberto.sassu@...wei.com, ebiggers@...gle.com,
crecklin@...hat.com
Subject: Re: [PATCH v8 0/2] KEYS: Read keys to internal buffer & then copy
to userspace
From: Waiman Long <longman@...hat.com>
Date: Sat, 21 Mar 2020 21:11:23 -0400
> The current security key read methods are called with the key semaphore
> held. The methods then copy out the key data to userspace which is
> subjected to page fault and may acquire the mmap semaphore. That can
> result in circular lock dependency and hence a chance to get into
> deadlock.
>
> To avoid such a deadlock, an internal buffer is now allocated for getting
> out the necessary data first. After releasing the key semaphore, the
> key data are then copied out to userspace sidestepping the circular
> lock dependency.
>
> The keyutils test suite was run and the test passed with these patchset
> applied without any falure.
Who will integrate these changes?
Powered by blists - more mailing lists