From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 138B0A00BE; Tue, 7 Jul 2020 20:04:41 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id DAA7C1DE08; Tue, 7 Jul 2020 20:04:39 +0200 (CEST) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id 83BA41D9AA for ; Tue, 7 Jul 2020 20:04:38 +0200 (CEST) IronPort-SDR: qg6xzW1UGQ+WM6O3H7FXKTZyWbsSiMZROu6ygE74zh7bmj/FlAFriFleSIB0ZxHjMR4IhkZK5q 13xjcbaD2bOQ== X-IronPort-AV: E=McAfee;i="6000,8403,9675"; a="135132505" X-IronPort-AV: E=Sophos;i="5.75,324,1589266800"; d="scan'208";a="135132505" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Jul 2020 11:04:37 -0700 IronPort-SDR: rxSYjz5RE3jB7EXYwaxRGDxhgY3WoOqUTCws3Y8t8L63Vr5i1TxsySipB5CJ7946i06AAsCMWS vwodkwalP4lg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,324,1589266800"; d="scan'208";a="315600615" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by fmsmga002.fm.intel.com with ESMTP; 07 Jul 2020 11:04:36 -0700 Received: from [10.166.30.253] (10.166.30.253) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 7 Jul 2020 11:04:36 -0700 To: Dmitry Kozlyuk , Tal Shnaiderman CC: Narcisa Ana Maria Vasile , "dev@dpdk.org" , Thomas Monjalon , "pallavi.kadam@intel.com" , "david.marchand@redhat.com" , "grive@u256.net" , "harini.ramakrishnan@microsoft.com" , "ocardona@microsoft.com" , "anatoly.burakov@intel.com" References: <20200624145621.26604-1-talshn@mellanox.com> <20200624145621.26604-2-talshn@mellanox.com> <20200707004325.GA71561@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <20200707113922.2e870d2d@sovereign> From: Ranjit Menon Message-ID: Date: Tue, 7 Jul 2020 11:04:34 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200707113922.2e870d2d@sovereign> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: [10.166.30.253] Subject: Re: [dpdk-dev] [PATCH 1/2] eal/windows: Add needed calls to detect vdev PMD X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 7/7/2020 1:39 AM, Dmitry Kozlyuk wrote: > On Tue, 7 Jul 2020 08:04:00 +0000, Tal Shnaiderman wrote: >> Dmitry, It looks like we got to this stage since hugepage_claim_privilege() cannot actually detect that "Lock pages" isn't granted to the current user, as a result we fail on the first usage of a memory management call [in this case rte_calloc()] without indication to the reason. >> >> Is it possible to add an actual check that the current user is in the list of grantees? > Thanks, I'll look into it. > >> Alternatively, It would be great to have this privilege added programmatically, I tried the MSDN example in [2] but it didn't work for me while testing, maybe Microsoft team can check if there is a way to do it? > I don't think it's a good idea from security perspective if an application > grants its user new privileges implicitly. Process with SeLockMemory > privilege can affect overall system performance and stability. I agree. This is something we forbid, when we do security reviews for our other products here inside Intel. Best to have the user explicitly acquire this privilege. ranjit m.