Re: [PATCH v4 2/2] proc: restrict /proc/pid/mem

Hi-- On 5/24/24 12:28 PM, Adrian Ratiu wrote: > diff --git a/security/Kconfig b/security/Kconfig > index 412e76f1575d..0cd73f848b5a 100644 > --- a/security/Kconfig > +++ b/security/Kconfig > @@ -183,6 +183,74 @@ config STATIC_USERMODEHELPER_PATH > If you wish for all usermode helper progra

[PATCH v2 0/4] Add support for hwspinlock bust

hwspinlocks can be acquired by many devices on the SoC. If any of these devices go into a bad state before the device releases the hwspinlock, then that hwspinlock may end up in an unusable state. In the case of smem, each remoteproc takes a hwspinlock before trying to allocate an smem item. If th

[PATCH v2 4/4] remoteproc: qcom_q6v5_pas: Add hwspinlock bust on stop

From: Richard Maina When remoteproc goes down unexpectedly this results in a state where any acquired hwspinlocks will remain locked possibly resulting in deadlock. In order to ensure all locks are freed we include a call to qcom_smem_bust_hwspin_lock_by_host() during remoteproc shutdown. For qc

[PATCH v2 3/4] soc: qcom: smem: Add qcom_smem_bust_hwspin_lock_by_host()

Add qcom_smem_bust_hwspin_lock_by_host to enable remoteproc to bust the hwspin_lock owned by smem. In the event the remoteproc crashes unexpectedly, the remoteproc driver can invoke this API to try and bust the hwspin_lock and release the lock if still held by the remoteproc device. Signed-off-by:

[PATCH v2 1/4] hwspinlock: Introduce hwspin_lock_bust()

From: Richard Maina When a remoteproc crashes or goes down unexpectedly this can result in a state where locks held by the remoteproc will remain locked possibly resulting in deadlock. This new API hwspin_lock_bust() allows hwspinlock implementers to define a bust operation for freeing previously

[PATCH v2 2/4] hwspinlock: qcom: implement bust operation

From: Richard Maina Implement a new operation qcom_hwspinlock_bust() which can be invoked to bust any locks that are in use when a remoteproc is stopped or crashed. Signed-off-by: Richard Maina Signed-off-by: Chris Lew --- drivers/hwspinlock/qcom_hwspinlock.c | 25 + 1

Re: [PATCH v4 1/2] proc: pass file instead of inode to proc_mem_open

Hi Adrian, kernel test robot noticed the following build errors: [auto build test ERROR on kees/for-next/pstore] [also build test ERROR on kees/for-next/kspp linus/master v6.9 next-20240523] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we sugg

Re: [PATCH v4 1/2] proc: pass file instead of inode to proc_mem_open

Hi Adrian, kernel test robot noticed the following build errors: [auto build test ERROR on kees/for-next/pstore] [also build test ERROR on kees/for-next/kspp linus/master v6.9 next-20240523] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we sugg

[PATCH v4 2/2] proc: restrict /proc/pid/mem

Prior to v2.6.39 write access to /proc//mem was restricted, after which it got allowed in commit 198214a7ee50 ("proc: enable writing to /proc/pid/mem"). Famous last words from that patch: "no longer a security hazard". :) Afterwards exploits started causing drama like [1]. The exploits using /proc

[PATCH v4 1/2] proc: pass file instead of inode to proc_mem_open

The file struct is required in proc_mem_open() so its f_mode can be checked when deciding whether to allow or deny /proc/*/mem open requests via the new read/write and foll_force restriction mechanism. Thus instead of directly passing the inode to the fun, we pass the file and get the inode inside

Re: [PATCH 5/7] dt-bindings: remoteproc: qcom,pas: Add hwlocks

On Thu, May 23, 2024 at 08:15:54AM +0200, Krzysztof Kozlowski wrote: > On 22/05/2024 19:50, Bjorn Andersson wrote: > > > > We did consider tying this to the SMEM instance, but the entitiy > > relating to firmware is the remoteproc instance. > > I still do not understand why y