From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 4071BA0032 for ; Thu, 1 Sep 2022 16:43:04 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C1C6D40C35; Thu, 1 Sep 2022 16:43:03 +0200 (CEST) Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53]) by mails.dpdk.org (Postfix) with ESMTP id B99C040695 for ; Thu, 1 Sep 2022 16:43:01 +0200 (CEST) Received: by mail-lf1-f53.google.com with SMTP id z29so16169837lfb.13 for ; Thu, 01 Sep 2022 07:43:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date; bh=VyZLDVoR8QbFtesvliyxXZWhyFfVMMon+EbQG7CKXe0=; b=j7S53A0OPfHCpz/JtfSSdr7BXQ+alLFu6FZynKMxOG08xiHD4oVkTuQFkdr0gL0Ra7 ECiWitDtDUgJ70sIaxXiNyivwdmJliLuLLL3ZhnbGiOcB0VSFXZ7gDIgbbSGJ5kGpKJS 5YbHlwEvZFKJbf+TPEuctRCI5KuaYIR81NVIusXreFLKrt3gITeFrSmBAMgLAJSbsY5l T7jts3mngn2jqsqHyP7G1caB221OZPEaNDHedSNjaaiDGRMjJt0+OVQlefvMT/oTs1pF MR2rmte9WCDCmeZgR5CvWCzNsuqogvIhbRe6Ce77z28890BRSlW+Q8sTb/8nEqINXVfM Uk2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date; bh=VyZLDVoR8QbFtesvliyxXZWhyFfVMMon+EbQG7CKXe0=; b=X611UxuDJZz35SnpqAjWUgkoJLT+gfTsiaGi98nxK0NO/2gR3K8M0/RpDNcbR33RHr KBJuvhL1JDA4F1qD09IvMinjVCewFpOg7r35DCpKk9OLubvKlfxCWou+ocev1a8ZBYx0 ldmjFPlMJRtxKEuLk7zS1meWQTtvqRibiBQ3ghnehmXg0L5LcKwwjTBUDWIKSKsC6Uad CAwsr7sVN/W6C20zmwfmqy8O98l/i9HISuUJviE7Rlni41z23i3YUaJM1kyZuwSWcWwL USKX88IFhrgWOGo41zJ8v9IQ+dAz87h6NBucU3Lego17AH48tifMQ0bJWuPUm6zvH9XH 05Yw== X-Gm-Message-State: ACgBeo0k9gqJzenNa5Gb6BthjiGp7ZvSPA2T8HhwwFw3IWuT7Q9VB1OG +FHzled2+7uTiQX2FCzX5VU= X-Google-Smtp-Source: AA6agR49+alnnlZhLSSOAirL02MLNN3//9t8YiAOumiCRF3T5SVDW+zA4p86fKMf8FPOBIzvTmMz+A== X-Received: by 2002:a05:6512:16a1:b0:48a:87a2:103c with SMTP id bu33-20020a05651216a100b0048a87a2103cmr12089106lfb.554.1662043381126; Thu, 01 Sep 2022 07:43:01 -0700 (PDT) Received: from sovereign (broadband-37-110-65-23.ip.moscow.rt.ru. [37.110.65.23]) by smtp.gmail.com with ESMTPSA id o8-20020ac24e88000000b0048a921664e8sm1551409lfr.37.2022.09.01.07.43.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 Sep 2022 07:43:00 -0700 (PDT) Date: Thu, 1 Sep 2022 17:42:59 +0300 From: Dmitry Kozlyuk To: Boris Ouretskey Cc: users@dpdk.org, Bruce Richardson , "Burakov, Anatoly" Subject: Re: Issue setting up the DPDK development with non-privileged user Message-ID: <20220901174259.3a9420ae@sovereign> In-Reply-To: References: <20220831190158.44dd76de@sovereign> X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org 2022-09-01 15:52 (UTC+0300), Boris Ouretskey: > > > > Dmitry, > > Thanks a lot for the reply. > > 1. The things look better now, but now we still have some capabilities > > left out in order for the program to run. I am myself not a kernel > > programmer and asked on stackoverflow > > > > the question on how can we deduce the exact capability that failed the > > check in kernel. Otherwise the process of finding the exact set can be very > > irritating. May be someone here will have the idea better than guessing for > > user space developers. Theoretically, one can enumerate all capabilities, give all capabilities except one to the binary, try to run it, and notice which capability removal leads to a failure. However, `setcap "all=ep $capa-ep" ./binary` did not give the correct answer to me (why?), so I did it semi-manually. I created a file with all capabilities listed, /tmp/caps. The following command sets capabilities from this file which are not commented-out using #: sudo setcap $(grep -v "^#" /tmp/caps | tr "\n" "," | sed -e 's/,$/+ep/') ./binary Then I started commenting parts of /tmp/caps (bisecting actually) until the error reproduced. > > [user1@dredd examples]$ sudo setcap > > cap_ipc_lock,cap_sys_admin,cap_dac_override+ep ./dpdk-helloworld > > [sudo] password for user1: > > [user1@dredd examples]$ ./dpdk-helloworld > > EAL: Detected CPU lcores: 4 > > EAL: Detected NUMA nodes: 1 > > EAL: Detected static linkage of DPDK > > EAL: Multi-process socket /run/user/1000/dpdk/rte/mp_socket > > EAL: Selected IOVA mode 'PA' > > EAL: VFIO support initialized > > EAL: Cannot open /dev/vfio/noiommu-0: Operation not permitted > > EAL: Failed to open VFIO group 0 > > EAL: Requested device 0000:00:08.0 cannot be used > > EAL: Cannot open /dev/vfio/noiommu-1: Operation not permitted > > EAL: Failed to open VFIO group 1 > > EAL: Requested device 0000:00:09.0 cannot be used > > TELEMETRY: No legacy callbacks, legacy socket not created > > hello from core 1 > > hello from core 2 > > hello from core 3 > > hello from core 0 Bruce, Anatoly, you know VFIO the best, any suggestions? > > 2. Thanks a lot for pointing out how it works. Regarding your second note, > > In my understanding, knowing physical addresses does not help any user > > process lacking the corresponding privileges. Because mapping and read > > permission are enforced by kernel & hardware, even knowing the physical > > memory address would not help regular process reading or updating it unless > > the physical page was mapped by the kernel into process virtual space with > > proper permission. An attacker can trick HW to read or write at the specified physical address. Memory protection is implemented in MMU, and DMA bypasses MMU. I've no idea how practical this is for penetrating systems, but even an unintended bug may crash the OS this way or corrupt data. > > In addition it turns out that if one would like to debug DPDK or any other > > executable using a special capabilities set, this set must be duplicated in > > gdb (at least that's how it worked for me), otherwise it spawns debugee > > with reduced capabilities set ( I guess by means of bound set). If someone > > using VSCODE remote connection debug than also Thanks for sharing the experience. Maybe worth adding to the section about running w/o root privileges.