From owner-freebsd-hackers@freebsd.org Sun Mar 11 11:18:44 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 81C98F45198 for ; Sun, 11 Mar 2018 11:18:44 +0000 (UTC) (envelope-from yhayakawa3720@gmail.com) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E9BDF875B4 for ; Sun, 11 Mar 2018 11:18:43 +0000 (UTC) (envelope-from yhayakawa3720@gmail.com) Received: by mail-wr0-x22c.google.com with SMTP id o8so12935124wra.1 for ; Sun, 11 Mar 2018 04:18:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=fBvy5KgXZXiG1vGPOpRwe9AwiqKoI6TfBZnTvWa4sT4=; b=d43B/AHIJ6gkusymqLEU/4YYlHSKzPjwueQatTZmpYrIYHudBL4u4MEjnqNno/qnaZ i3xIN/1G53auPM6KXpaYqyj9xIWb5/VA4qY8jFQWuPQ0dzU1Ch67b2bezO12ArNMFzrs Nl0sAhPP/2N4soh4HmlmJc7qmBPGJL3CzVTGrPH9GArB144GjTrEnRP9p1rfOmrg/D9V JvkjnVTwbNVw5x3g7vkGIW/VRuWXLVe8ZuyBbH8brfJyb2lItPQfAJdIm9nJs4VLesfa 642ysUpDfgy4bQ2KgMiK8zeJ8MSSyHaP0G9PO1EyPI+aDbsj1k02Xnpoal2y2g5lC2NY Gqjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=fBvy5KgXZXiG1vGPOpRwe9AwiqKoI6TfBZnTvWa4sT4=; b=MfUCuxqHSDTFJHWQf0MxO8KzESNTQ19ohq8X6+G/YeGJw5OY7L3Nz02rgaOmsdBr5H aImJ3Ojs3KmIGYhTj5iNjJJgktf9PiNjyuzrsZM9vZ6rk+MIVxxugN4Z0WfUrasHt7GN 0DH1D7902nqi1gwhQDvHI17EgVgBtqUCLQwJe2Jz2cGgI3cBzpSTVMDfMxEMYOqzzaPv FXfbR7JWgh/8zwMrty0ASen3oQ+z+g6a2ZxO75P4tv/ZUthOv6RylU8Q2mocVLFROu2P NfVFWZLbxLc+M8Fc/DQWFK6Q2r26ns+e0OimjaUoDXXD6UV7DaDjCrNSz6D4g5l/z3Du RjJQ== X-Gm-Message-State: AElRT7GawPLoIt9zuXsTugraciSGjP4+OBzg+HgFD6NzgOjYY8tFlWNM kRnTpwGbXc2vdnJ7hBosJuSOckJSdJQ= X-Google-Smtp-Source: AG47ELvph9LXlyaJ2wF1FJpg/v/5GjEytMQ/p5icAPHm8rlecokLQVkOAZaZMl0MYw1tJTNufCcb/Q== X-Received: by 10.223.173.163 with SMTP id w32mr3713820wrc.204.1520767122747; Sun, 11 Mar 2018 04:18:42 -0700 (PDT) Received: from ?IPv6:2a02:8071:2c0:1500:10b2:1657:74a4:feb0? ([2a02:8071:2c0:1500:10b2:1657:74a4:feb0]) by smtp.gmail.com with ESMTPSA id u89sm2103934wma.10.2018.03.11.04.18.42 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 11 Mar 2018 04:18:42 -0700 (PDT) From: Yutaro Hayakawa Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Possible GSoC idea, eBPF for FreeBSD Message-Id: Date: Sun, 11 Mar 2018 12:19:03 +0100 To: freebsd-hackers@FreeBSD.org X-Mailer: Apple Mail (2.3273) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2018 11:18:44 -0000 Dear FreeBSD Hackers Hello, this is Yutaro Hayakawa, master student of Keio University Japan. Sorry if this mail was duplicated, I sent once with no membership. And now I am a member of this mailing list. I=E2=80=99m now working for implementing eBPF for FreeBSD. I had talk = about this in BSDCam2017 (https://wiki.freebsd.org/DevSummit/201708 = ) and will make talk in BSDCan2018 = (https://lists.bsdcan.org/pipermail/bsdcan-announce/2018-March/000168.html= = ). Below you can see some work in progress codes. eBPF itself: https://github.com/YutaroHayakawa/generic-ebpf = eBPF + VALE software switch: https://github.com/YutaroHayakawa/vale-bpf = To move this work forward, I=E2=80=99d like to make this GSoC project. I = have a rough idea for what I do in 12weeks, but not yet discuss it with FreeBSD people. Is there anyone who willing to mentor this work? Could you discuss about = this with me? Best Regards, Yutaro P.S For the people attended to AsiaBSDCon2018, I hope you enjoy Tokyo!= From owner-freebsd-hackers@freebsd.org Sun Mar 11 11:08:31 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D44E7F443F5 for ; Sun, 11 Mar 2018 11:08:30 +0000 (UTC) (envelope-from yhayakawa3720@gmail.com) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4921E86F3F for ; Sun, 11 Mar 2018 11:08:30 +0000 (UTC) (envelope-from yhayakawa3720@gmail.com) Received: by mail-wm0-x231.google.com with SMTP id z81so11202407wmb.4 for ; Sun, 11 Mar 2018 04:08:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=LkVnXjGsxc+LvdHR60NXWuodgjIRLHB8Z5Cs5KdwBGY=; b=HZzkK/9MfAUykMKMub0jscrHY+sb2UCMmTEaZsy/71cpSfL73NsenCfihFdKvVlRHo ESUNpSvAHgdxd3YM/Y/t0HuplgaElHByQLVedMPGm9bvj+nnjk6VZHqQlgifq0FVbjuE 4IPfocIzelrkmI0jfOL0oySUXsHHyrJZKBnbT9siRkvwOyMjvdwE0IzlFZU35TRIiaiZ bh7N+rOyN+DhuIWohViziESYf/Ti0PQ3lsnphS0+ZeR6iGvoBBs5FyEtm5irlZntaw6M lamhMlJd6GyB/osJuhbLg9Hko0CSBC12AzKADbOdaaifEEtL5Udsj38gjOgXwULvaL2l lmpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=LkVnXjGsxc+LvdHR60NXWuodgjIRLHB8Z5Cs5KdwBGY=; b=YYm3uSUfZIcXJNRjoUPp+sAmz1G2ZfDGwa3EjK7yWE9ZqV1sNHN/CHcqx5nMX8G1OU DMni3RjVKlayASd/zJbHGUFBkcivd5Tb81wTVPZw1mkOIiVJBvp87Z7T0NG571xB8jXv quL4tNhO9Y4/sYQRW1pmaD2N7cCpO2g+W7rNTGaItyjtx8Yq5SFq5AYj98vvOl/r+RlX KbrmDCG5tqqbuK4hmQUnyoWn7if+BS71Ko54Liz3QArBlMnUHhVzpqjFN1dtidwYCsgZ kpVkQKAtqtP1bXbJbPAAUODeIBcWOlxYvzSs5NMf/BCEHh98ATzZq72VqcfZgNEPikVm PAig== X-Gm-Message-State: AElRT7EuS7KVD/MyhNsCJenxn3zZln+ceBM4tjW1BsBv8rZCYfG6rKbd Ee0Jo/Qyu20pkranqiiItbnES41+4ro= X-Google-Smtp-Source: AG47ELsy1cAOCx89c8YEXRBEznjzj3Lu5qQGKZ55+n5DOURp0XAzrg/rxK/JbVSjB8sasxPNK1ju7w== X-Received: by 10.28.227.66 with SMTP id a63mr2786203wmh.128.1520766508386; Sun, 11 Mar 2018 04:08:28 -0700 (PDT) Received: from ?IPv6:2a02:8071:2c0:1500:10b2:1657:74a4:feb0? ([2a02:8071:2c0:1500:10b2:1657:74a4:feb0]) by smtp.gmail.com with ESMTPSA id y6sm1786084wmy.16.2018.03.11.04.08.27 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 11 Mar 2018 04:08:27 -0700 (PDT) From: Yutaro Hayakawa Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Possible GSoC idea, eBPF for FreeBSD Message-Id: Date: Sun, 11 Mar 2018 12:08:46 +0100 To: freebsd-hackers@FreeBSD.org X-Mailer: Apple Mail (2.3273) X-Mailman-Approved-At: Sun, 11 Mar 2018 11:31:54 +0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2018 11:08:31 -0000 Dear FreeBSD Hackers Hello, this is Yutaro Hayakawa, master student of Keio University Japan. I=E2=80=99m now working for implementing eBPF for FreeBSD. I had talk = about this in BSDCam2017 (https://wiki.freebsd.org/DevSummit/201708 = ) and will make talk in BSDCan2018 = (https://lists.bsdcan.org/pipermail/bsdcan-announce/2018-March/000168.html= = ). Below you can see some work in progress codes. eBPF itself: https://github.com/YutaroHayakawa/generic-ebpf = eBPF + VALE software switch: https://github.com/YutaroHayakawa/vale-bpf = To move this work forward, I=E2=80=99d like to make this GSoC project. I = have a rough idea for what I do in 12weeks, but not yet discuss it with FreeBSD people. Is there anyone who willing to mentor this work? Could you discuss about = this with me? Best Regards, Yutaro P.S For the people attended to AsiaBSDCon2018, I hope you enjoy Tokyo!= From owner-freebsd-hackers@freebsd.org Mon Mar 12 19:59:05 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6F8C0F3F4FC for ; Mon, 12 Mar 2018 19:59:05 +0000 (UTC) (envelope-from radovanovic@gmail.com) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DBBB76E25E for ; Mon, 12 Mar 2018 19:59:04 +0000 (UTC) (envelope-from radovanovic@gmail.com) Received: by mail-wm0-x229.google.com with SMTP id x7so18508850wmc.0 for ; Mon, 12 Mar 2018 12:59:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=t9048iCHp6dqXEGct2THS7BazJqRVTu7/bih4hWBj6A=; b=td2IR4pWuvUl41ZuBJ2BB1Txurr2qe/ACzr0Tra7iOliF+uMyuSi+V5wJIleQp2xT8 w+BKgVWOvWjPpvZlbqrRxda372E/+ByTv8s0+DQvRUBn3+184GtSBlW9Mfq0ucwU5nDA V9vc5veJQofRQUfdCS/WvNky+BIO0LgB5KjxKRDv6zs/7yxhFwQkv8JY05conemq8wuC 5jnaziZruzJXH7bhnORLeYs+WLgJQAPAJiXaCcBCmnHX+s2W0+sRj37mOlyz/QPSeNIo w68aGylXQO4gdZ42dNLA0DjrH3E64QpME8lc1cVtGWSiJbKJ2T0BrhxL1YTmGXyD4NDe cLSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=t9048iCHp6dqXEGct2THS7BazJqRVTu7/bih4hWBj6A=; b=qA6SmxtxIEREGD/wsJ3vsEUrAcrlqcW08nReMtwfHVgl168wcHDgKiEgbnyX/V1qaW goW5bTrV7ENASDKVfLQcXjEcO9oC3fYGCGn3A2IpKSurRGyfJt7POKDELX70ecnxMnir eSZWwfs60/6GVCczWoKIcYY+l9R8Ad49DIqDtgV1+2tfi7VOq/kcmks/QUwH8zBtfuVN ZfHG1wbbdFMXJfRCatRtoYfsAOT8dGE2Gr3VzZpzwNWdTfH6WgDylx/Oa5JMJe555vy6 7Bz+556xXX73DPLXOzCpJEHnhFDJ/gSb9D8CHYOCyO6V3z0oVFUX+tLSLiqJaia4iJr8 6HVA== X-Gm-Message-State: AElRT7HjAQEd8zrDCX+7uenHerJt3lyMfH913kt3whRrhmv4KOhKbMcJ Hwnhnxze3ndOo6w7pkHtZ1WV1A== X-Google-Smtp-Source: AG47ELuqceNIxJdEP5MSkh6RPkl9oqwgnp7AseBTGKxvp4xYh6PR6f5RVgU1a2Xya+VkS1UKK6CvaQ== X-Received: by 10.28.92.208 with SMTP id q199mr6236384wmb.91.1520884743678; Mon, 12 Mar 2018 12:59:03 -0700 (PDT) Received: from zmaj.softwarehood.com ([178.220.209.186]) by smtp.googlemail.com with ESMTPSA id m9sm3825430wrg.79.2018.03.12.12.59.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Mar 2018 12:59:03 -0700 (PDT) To: freebsd-hackers@freebsd.org From: Ivan Radovanovic Subject: About setgid, setgroups and supplemental groups Message-ID: Date: Mon, 12 Mar 2018 20:59:01 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2018 19:59:05 -0000 I was working on simple program which should drop some (ordinary) user privileges and complete its work while keeping permissions of only one group user is in, when I discovered that FreeBSD doesn't actually behave the way I expected (actually I didn't find way to achieve this at all in FreeBSD). The problem is: - there is user A, member of groups B, C, D. Program should run with credentials of only group C (A != root). I expected that setgid(2) would always succeed for root, and succeed for ordinary user if user was member of requested group, but I kept getting EPERM. While checking documentation I found to my surprise that setgid behaves exactly like setuid(2) (normal user can switch only to his primary group, superuser can do whatever he wants). Also from documentation is very difficult to understand what is exact relation between setgroups(2) and setgid(2) on FreeBSD (if any), for example Linux manual pages say explicitly that setgid has no interaction whatsoever with supplemental groups, while AIX manual pages explicitly say that user is allowed to setgid to any of his supplemental groups (so obviously both approaches are in use). Documentation for setgroups(2) explicitly states that only root can use it, so apparently normal user can't use it to restrict group permissions for running program. I would be very grateful if somebody could explain why it was chosen not to allow setgid to other real user's groups (sounds like illogical thing to do), or if there is some other mechanism to achieve the same in FreeBSD (preferably completely in code, without playing with file permissions). Kind regards, Ivan From owner-freebsd-hackers@freebsd.org Tue Mar 13 02:22:22 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 382B9AFC6E3 for ; Tue, 13 Mar 2018 02:22:22 +0000 (UTC) (envelope-from chris@chrisbailey.io) Received: from mail-vk0-x243.google.com (mail-vk0-x243.google.com [IPv6:2607:f8b0:400c:c05::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C7F3B81A0A for ; Tue, 13 Mar 2018 02:22:21 +0000 (UTC) (envelope-from chris@chrisbailey.io) Received: by mail-vk0-x243.google.com with SMTP id y127so7561960vky.9 for ; Mon, 12 Mar 2018 19:22:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chrisbailey-io.20150623.gappssmtp.com; s=20150623; h=from:mime-version:date:message-id:subject:to:cc :content-transfer-encoding; bh=o1kEwOHIvw8aI89Gq4EIMz2nPmGg8/QrdbLv30zBSik=; b=d/zdQwh+rYPYE8ap4r5GtXgciPzmHXs07VjZ/laOpM3J0H3AQyLoGkhw7pE0uhkYSJ 6hZNzsHzWoSyBe6ojTyANQ9LcUySNqMMAYt2d2jCS6BlbSxh0ifdjonIgDtQcBfxJ1BF RQ8xXLjl8xZPndaiIiy9ogGWxKMSfUT7LqJkh60wecdznxd6VMS5EsAuFFyj1GZrbij2 pyppvSS3v5wO0OIZDJJq+Kc2GW+cPrxqVLHIlX0W3QAZRLVP69NVK4WL81kwVQ8Au3gz JtojJIR2mtbvlHD/rNZ6ETTcVw4I5+5AZA7XGOL/BEYcEv03uPu1WemQNIhtDYPrzN8Q Fktw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to:cc :content-transfer-encoding; bh=o1kEwOHIvw8aI89Gq4EIMz2nPmGg8/QrdbLv30zBSik=; b=M54EAm8Ye17pQ9njBf/aCpzpLaEIEMc5RzaJNK8FviIHX02/rC3KNBjixfRJt3ROrt G3GRYo18ES9Y3Fbcq9E8JPmlDl+tH5sd/HrtAFV0S8xOE+RoB6Ob2XtR2MPt2tuRFd/W UbmOHK3RxNDBefGFjnSOddsxxP/029fpg9sD7kzFFHjrNrQefdqZheBZBmvOzBWGZeOP XluC4R0sgtYN6/ZLTMepE3a3mTRLtElKIbjiGrYrSmtlhVoS7ATQ8NyH7RClu+T5aOg+ sWErI32QAR/oySMYtzNVFZWuQHkmH8r/sXaqphaEe8GCvyT8TRbcCKdMUJCaYprk6AkE PXxQ== X-Gm-Message-State: AElRT7GDrB4fOheW4pOd1WDxpP1HlkQxmBX8nr1NNHn0dVrGA0F7hzqT dyuczHQ2xpBymKYzJM+Sx4U0iBs2nf7Vb5XQO72L0Q== X-Google-Smtp-Source: AG47ELuxTmnhACba7Q8xthfTqMP72hIhH8m2w2w9mMgXn+qF3IIZoCi6PRXvBME//L+YT6D5mu46lKi14ELCqbnRjlI= X-Received: by 10.31.27.195 with SMTP id b186mr6492113vkb.14.1520907741133; Mon, 12 Mar 2018 19:22:21 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 12 Mar 2018 22:22:20 -0400 From: Christopher Bailey X-Mailer: Airmail (467) MIME-Version: 1.0 Date: Mon, 12 Mar 2018 22:22:20 -0400 Message-ID: Subject: [GSoC] Dual-stack ping command To: freebsd-hackers@freebsd.org Cc: freebsd-net@freebsd.org, lists@eitanadler.com, gavin@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 02:22:22 -0000 Hello, I=E2=80=99m an undergraduate computer science student at the University of Alaska Fairbanks. I=E2=80=99m interested in unifying ping and ping6 into a single command, because it=E2=80=99s one of the suggested ideas on the wiki= , it=E2=80=99s something that=E2=80=99s mildly irritated me in the past, and = I believe I have the necessary skills to accomplish it. >From looking at the source code to the two existing commands, this project looks pretty straightforward. There could be some complications I=E2=80=99m missing though, so I=E2=80=99d be interested to h= ear from more experienced developers if there are. Also, apologies if I did anything wrong in sending this email. I=E2=80=99ve been following the FreeBSD lists for a while, but this is the first time I=E2=80=99ve sent a message myself, so I=E2=80=99m new to the experien= ce. Thanks, Chris Bailey From owner-freebsd-hackers@freebsd.org Tue Mar 13 03:40:39 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8C5E3B7C657; Tue, 13 Mar 2018 03:40:39 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:300:2185:a:dead:bad:faff]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3F9C485F2D; Tue, 13 Mar 2018 03:40:38 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [104.207.135.49]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id w2D3eYFM015437; Tue, 13 Mar 2018 03:40:34 GMT (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id w2D3eXTa015436; Tue, 13 Mar 2018 03:40:33 GMT (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <201803130340.w2D3eXTa015436@donotpassgo.dyslexicfish.net> Date: Tue, 13 Mar 2018 03:40:33 +0000 Organization: Dyslexic Fish To: freebsd-hackers@freebsd.org, chris@chrisbailey.io Cc: lists@eitanadler.com, gavin@freebsd.org, freebsd-net@freebsd.org Subject: Re: [GSoC] Dual-stack ping command References: In-Reply-To: User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [104.207.135.49]); Tue, 13 Mar 2018 03:40:34 +0000 (GMT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 03:40:39 -0000 Christopher Bailey wrote: > I’m an undergraduate computer science student at the University of > Alaska Fairbanks. I’m interested in unifying ping and ping6 into a > single command, because it’s one of the suggested ideas on the wiki, > it’s something that’s mildly irritated me in the past, and I believe I > have the necessary skills to accomplish it. Hello! That's something that's bugged me too.. I'm going to be cheeky now, and ask if you've thought of doing traceroute/traceroute6 too? :-) Cheers, Jamie From owner-freebsd-hackers@freebsd.org Tue Mar 13 05:36:33 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D169EBF11F0 for ; Tue, 13 Mar 2018 05:36:33 +0000 (UTC) (envelope-from chris@chrisbailey.io) Received: from mail-vk0-x243.google.com (mail-vk0-x243.google.com [IPv6:2607:f8b0:400c:c05::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 643FF69E5A for ; Tue, 13 Mar 2018 05:36:33 +0000 (UTC) (envelope-from chris@chrisbailey.io) Received: by mail-vk0-x243.google.com with SMTP id f6so7761260vkh.6 for ; Mon, 12 Mar 2018 22:36:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chrisbailey-io.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=KSbF8dsVBOUk1Wna7cQ1TEEb3d1kUPglqBCgijqutJY=; b=EYfp9Boie+haUao3b0hBMOfYXE60JcnmnxVf8DBaUg9j9z94L+Sj09+X4ZuzN4zCrI +pM1e8zm5DGK9TbXGld75LYsjRbbmMg0Pt6q8KTsQT3kKYmXpGemurymPDrcPSzUKbtM mcRObFxM6pb2su3nGQP8dkbB0T7l5T/pvwfdgGc62PiT8tWe8f7oyYUjTQ0+WO+YCMDs tIFb1zN+0UoXiNBRmLRIUEB2dIzF6dSmwbn7N2MyI7jd9TNXuni9cazLZ7LmjnhYBYMx /zuFemcVSZem9WJizBcKdKR5Qd47dmawjQoNI3KgcqgMv38y4SoLDL0T/VAM72qNaJdB p4jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=KSbF8dsVBOUk1Wna7cQ1TEEb3d1kUPglqBCgijqutJY=; b=D9XyNtOnZgrqbkhEBqSK7zXEUmEXeSRcEQF2LiEyNgN3V6iIx4H/1n8VIvbAvc5nD5 qVr8mq/cOIh7LrDHgO8wOFN0pwtSKoJSgU1HrRpMQW9RODAZUFKr+KFTVUZc2EjXUpF4 qxzEjApJZKSJ78GpH1kHhjVKRLyRE0DLIearkdL8xN57MFKVykTkZjo6Jf6Ad8cqPThp ze+2gtPIEiR4wcFz4pMQ3DxFrTnFeOjWGUO0s1y7EHN3xtpD9txoMt6/Bgy1Fxm3JUpJ nL1u4HyLBnmStakVYzM9lpg9SnTrbaKj938Vi7bI3tqAvjGT7qmL1yDv17nIeXRCKzpR WjdQ== X-Gm-Message-State: AElRT7H1+vPqgxlrW00F4UosFLlvI0CGZN1tK/IMMI9FOJb/KhSk+X3q jUD294mZl66IE8OCvbxID4h4jRb/YIpapvcxsIscFRai X-Google-Smtp-Source: AG47ELvE1pLRHJJTbH0COjGz8JfFBeBq3KAX7eoi49lvkJyFJdwYw/eh162J/rp4M7fi4+QFSgxsxCzgkSGZxWTMzCk= X-Received: by 10.31.138.129 with SMTP id m123mr6790359vkd.13.1520919392758; Mon, 12 Mar 2018 22:36:32 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 13 Mar 2018 01:36:32 -0400 From: Christopher Bailey In-Reply-To: <201803130340.w2D3eXTa015436@donotpassgo.dyslexicfish.net> References: <201803130340.w2D3eXTa015436@donotpassgo.dyslexicfish.net> X-Mailer: Airmail (467) MIME-Version: 1.0 Date: Tue, 13 Mar 2018 01:36:32 -0400 Message-ID: Subject: Re: [GSoC] Dual-stack ping command To: freebsd-hackers@freebsd.org, Jamie Landeg-Jones Cc: freebsd-net@freebsd.org, lists@eitanadler.com, gavin@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 05:36:34 -0000 Jamie Landeg-Jones (jamie@catflap.org) wrote: > That's something that's bugged me too.. I'm going to be cheeky now, and a= sk if you've > thought of doing traceroute/traceroute6 too? Yes, I have. It was listed on the project ideas wiki page as a separate project, but I wouldn=E2=80=99t mind combining the two (or working= on traceroute as a stretch goal). From owner-freebsd-hackers@freebsd.org Tue Mar 13 16:03:35 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D7C2BF2B94A for ; Tue, 13 Mar 2018 16:03:35 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 731C084B18 for ; Tue, 13 Mar 2018 16:03:35 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by mail-qk0-x233.google.com with SMTP id v124so105500qkh.11 for ; Tue, 13 Mar 2018 09:03:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MvAJ3PO8CdBCycuQcnEb+HVJwqF30IMibgZWyGYHZm0=; b=uTV6t1xHNphQ33+jXN2j9fpUK+i2yoE+r7FPoVa5BVjpHJSeuvy+YjXPVpbhEGoJHt EckyRN3DwLN+aci/yA3uDnwa0vUYYbJrnmGOjorPJHYKBN3fyHPn6GGb51IsXQr9G+ac nqkNHlK3b5TfJNwDK+FnJGYJGIXSUh4JkaddWX5E0NQn+kgAJloaCt82dL8ifIVdSHLC CZ6SYBT8sYkMQXcMxXvxL5IpK8cXqJpNZft5da2Q80cFqgkHYk96gmFEXKd9rwL+TZJS SpSFe5VYEZvMFUYbjxLrYQ7Hhi5B99JYIcnIcwjnahyY2dk2UeMKiNiwRP9Xm9TZD9t2 ltSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MvAJ3PO8CdBCycuQcnEb+HVJwqF30IMibgZWyGYHZm0=; b=k+cf6X36YMQJbqj1pZ1Z8bS44DgN7PmnWebmQLUpPWe5q9BXO9nZk1U8v8B5ZPSQL+ sExfw62tlCS5x6mpVKC9jpxmJrMkwxem+3Nq8Xsxfc0w6yg+doeMSOJhNQvZSA6woEZ+ CvrLFQnQSklKq8lITEj1r3S2oyv64xCOkaWBb01MROmH6JNsa4XJA158wYAuzLyjwKvd H9VRy7LjgPZeF8OiWLAG2NTv1yY169xI4smf6o17kAXXv2twIyCcIfqizF68s/G+Z/tv r2YHDzeBpPJ59BOuRmc9T2suv1pvbO81PYUdnCzX1PDgbx0RbxfuwwKduvVInaXk2jpm D38Q== X-Gm-Message-State: AElRT7GDHl54RPso4odolvqKPWzezRzYvY3YT9/x+W34QRloVQWx5XAv DmXMdR7if5RBeThGygBGP4glslhhnuBJMkBUi8w= X-Google-Smtp-Source: AG47ELu4Ac5NU2rhEbvq5b4D6wFlISAdjY0Qo7KjEDGtC47bTABDqV1o4di3SBi0F+YRMWaeM2mWPgUl7fBT0kOqk74= X-Received: by 10.55.57.135 with SMTP id g129mr1707667qka.212.1520957014905; Tue, 13 Mar 2018 09:03:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.32.200 with HTTP; Tue, 13 Mar 2018 09:03:34 -0700 (PDT) In-Reply-To: References: From: Ryan Stone Date: Tue, 13 Mar 2018 12:03:34 -0400 Message-ID: Subject: Re: Possible GSoC idea, eBPF for FreeBSD To: Yutaro Hayakawa Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 16:03:36 -0000 I would be very interested in serving as a mentor for this project. I am registered at the GSOC as Ryan Stone at rysto32@gmail.com. Please feel free to contact me off-list if you have any questions about your project proposal. Thanks, Ryan From owner-freebsd-hackers@freebsd.org Tue Mar 13 16:53:21 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0BA55F31900 for ; Tue, 13 Mar 2018 16:53:21 +0000 (UTC) (envelope-from theron.tarigo@gmail.com) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 99E9A68A78 for ; Tue, 13 Mar 2018 16:53:20 +0000 (UTC) (envelope-from theron.tarigo@gmail.com) Received: by mail-qt0-x22f.google.com with SMTP id s48so299397qtb.10 for ; Tue, 13 Mar 2018 09:53:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=GzwcuX7YMHMpJBDjqvhGEFjWFzLLn3ocucSYA4AA08g=; b=O2Mw8YS9O2nra7VpYw8FvZjDLxqKJMT3L0blDuxI9HkLrIQfrhyLQETfV0RFUevMCM q7NTPSVWq5mp3waY0WXe5i6L6D9qnENKlt+d4QvtxrdMPrSWAiI2t67saW5qsG5odt4Y ynbGarqka6wKTB8r07c8vvgByO3JbraHuE3JbsXMA4itNJ6zC88H2qhgo7HOHOOQK3Va HfzaULraTk8txulJtWNTG8b8vPjNwm+KgJx3DZwLa+uzMPa+0JY/M4i7G8kp8Bhugq6d JXzhmwcOmZ8/AMg2lSsqHrfm8seHeBSI6EZkQgSrTBQ/jmrtmbhFXniU0tHEo6Nf4iPm iuKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:to:from:subject:message-id:date :user-agent:mime-version:content-transfer-encoding:content-language; bh=GzwcuX7YMHMpJBDjqvhGEFjWFzLLn3ocucSYA4AA08g=; b=uXrad2a1y2VaiXygKMypXHXKuOsRk0bAJGevnj0p7KJrZR0sui8e1daNzkPVgXaycL QCek2O3xfD/U5pkXf1i3vmRAudK3MBHR9Rshmmn+LXcU7xOqSI7FvJfeP2dPV/SAvMME AUJ9r9Tlc2TBRs97AN7KIVrdn02Z0NsgEnrAP/SfVHTZT6z+S/JbSAuZ+RnNmqDqlixj bRSY0reja1IXi/yBGp+EDJG2SgaF9nvamL3pR4qSiruZzvQZIdhgfIXXHkPNHv9BsoWh 26KYLc1F25dpzu4ySg3tQ3wP1gNhPlpGZvFIYD9QipSgcaP9XIsSdxAOpjA/mEpOr0DC rB6g== X-Gm-Message-State: AElRT7Flih5XS5KD+DwUJD+7DRBZE9l7wWJ0OceTeqAd6bnI9mMg8STb 9f//pF7yxJ4vFOvK0ts08EvYMY1t X-Google-Smtp-Source: AG47ELsDylw7lSfaMX3XUC6ByaxNHdZAgHDWU5v0KP6tg8wHswgK4ZhelyhqHoF7a1usDMQAdlDVhg== X-Received: by 10.200.48.135 with SMTP id v7mr2086993qta.296.1520960000099; Tue, 13 Mar 2018 09:53:20 -0700 (PDT) Received: from [155.41.26.230] (dhcp-wifi-8021x-155-41-26-230.bu.edu. [155.41.26.230]) by smtp.gmail.com with ESMTPSA id m187sm94220qkc.17.2018.03.13.09.53.19 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Mar 2018 09:53:19 -0700 (PDT) Sender: Theron Tarigo To: freebsd-hackers@freebsd.org From: Theron Subject: GSoC Idea: per-process filesystem namespaces for FreeBSD Message-ID: Date: Tue, 13 Mar 2018 12:53:18 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 16:53:21 -0000 Hello All, I am an undergraduate a Boston University looking to contribute to FreeBSD this summer under GSoC. The idea I would like to implement is to bring to FreeBSD a per-process mounting / namespaces functionality similar to that of the Plan9 operating system as a means to give greater flexibility in combination with less overhead than is associated with chroots and jails for purposes of isolating software setups from one another and from the underlying system. For those unfamiliar with Plan9, here is a rough explanation of the namespace feature: unlike in Unix, where all processes share the same virtual filesystem, each process instead has its own view of the filesystem according to what has been mounted, which, unlike Unix mount, as an unpriviliged operation changing only what is seen by the particular process and any processes it later spawns.  Thus it is possible for one process's /bin to be completely different from another process's /bin, and neither need be the same as the system's /bin, should one exist. As an example of its application and potential usefulness, a user may mount on top of /usr/local an overlay pointing to a location owned by the user, allowing existing binary packages which expect a /usr/local PREFIX to be installed and run without any modification either to the binary packages or to the underlying system.  Currently the only ways to achieve this are by recompiling ports with a different PREFIX or by configuring a jail.  Some, but not all, programs will function out-of-place under tweaked PATH and LD_LIBRARY_PATH, but this is not a general solution and leads to messy environments. Although I have not previously worked with kernel programming in particular, I have good experience of high-level practices and low-level details of C programming and I can teach myself new technical details quickly.  In researching how to approach the task, I will study the existing implementation of chroot, jail, and fdescfs as examples of process-specific namespace behavior already supported in FreeBSD kernel.  The nullfs and unionfs may also serve as work to build off of, although unionfs as currently implemented appears to be partially broken. Robustness of the implementation allowing, it should eventually be possible to replace system directories /bin, /sbin, /etc, etc. with bindings configured at boot time to improve the safety of live system upgrades and to provide a means of returning to older configurations which is not dependent on filesystem-specific snapshotting features. Although per-process filesystem namespacing is unconventional in the face of the dominant Unix single-namespace model, introducing the feature to a Unix-like system does not constitute a radical change, as it is compatible with and indeed facilitates the meeting of the reasonable expectation of existing and unmodified software to find resources in predetermined file paths. My attempt here to outline the relevant concepts is to the best of my limited understanding.  Hopefully I am not creating or propagating any misinformation and have not grossly misassessed the complexity of the task. I would greatly appreciate any suggestions of approaches to this task and of who to contact for more expertise and for potential mentorship. Thanks, Theron Tarigo From owner-freebsd-hackers@freebsd.org Tue Mar 13 17:14:34 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5B0F7F33F9A for ; Tue, 13 Mar 2018 17:14:34 +0000 (UTC) (envelope-from andre@fbsd.e4m.org) Received: from mail.g66.org (mail.g66.org [85.10.206.112]) by mx1.freebsd.org (Postfix) with ESMTP id C515F6A157 for ; Tue, 13 Mar 2018 17:14:33 +0000 (UTC) (envelope-from andre@fbsd.e4m.org) Received: from x4e35ee0c.dyn.telefonica.de (x4e35ee0c.dyn.telefonica.de [78.53.238.12]) (authenticated bits=128) by mail.g66.org (8.15.2/8.15.2) with ESMTPA id w2DHEWLd015494 for ; Tue, 13 Mar 2018 18:14:32 +0100 (CET) (envelope-from andre@fbsd.e4m.org) Received: from stationary.client ([192.168.128.2]) by gate.local (8.15.2/8.15.2) with ESMTP id w2DHEW8M002544; Tue, 13 Mar 2018 18:14:32 +0100 (CET) (envelope-from andre@fbsd.e4m.org) Received: from submit.client ([127.0.0.1]) by voyager.local (8.15.2/8.15.2) with ESMTP id w2DHEW1N012030; Tue, 13 Mar 2018 18:14:32 +0100 (CET) (envelope-from andre@fbsd.e4m.org) Received: (from user@localhost) by voyager.local (8.15.2/8.15.2/Submit) id w2DHEW6c012029; Tue, 13 Mar 2018 18:14:32 +0100 (CET) (envelope-from andre@fbsd.e4m.org) Date: Tue, 13 Mar 2018 18:14:32 +0100 From: Andre Albsmeier To: freebsd-hackers@freebsd.org Cc: andre@fbsd.e4m.org Subject: UARTs not working on a Supermicro A2SAV / Linux works ;-( Message-ID: <20180313171432.GA11972@voyager> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.7.2 (2016-11-26) X-Virus-Scanned: clamav-milter 0.99.4 at colo X-Virus-Status: Clean X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 17:14:34 -0000 The UARTs on the brand new Supermicro A2SAV mainboard (https://www.supermicro.com/products/motherboard/Atom/A2SAV.cfm) are detected on 11.1-STABLE as uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 which is consistent with the BIOS settings. Everything seems to work when it comes to setting of parameters and even the DTR and RTS lines change state when opening cuau0 or cuau1, e.g. with minicom. But sending or receiving characters fails -- to be exact, no single character will be received and only the very first one will be sent to the remote device. We remember this behaviour from the good old times when we had to jumper base port addresses and IRQs on ISA cards: If we got the IRQ wrong the same effect happened: The first char could be sent because the TX register was empty but the IRQ telling the kernel that it can send the next char never arrived. When using debug.uart_force_poll=1 in loader.conf it works (at least if we type in characters slowly, of course). So it really seems to have to do with interrupts again but I have no idea where to look. The A2SAV manual talks about the Super I/O being a Nuvoton NCT5523D. Can it be that we miss some support for this? But if the devices really behave like standard 16550s we shouldn't need any specific support at all, I think. I disabled the corresponding ACPI functions by using debug.acpi.avoid="\_SB_.PCI0.SBRG.UAR1 \_SB_.PCI0.SBRG.UAR2" and the devices were detected properly as uart0: <16550 or compatible> at port 0x3f8 irq 4 flags 0x10 on isa0 uart1: <16550 or compatible> at port 0x2f8 irq 3 on isa0 but this didn't help (same behaviour). The really bad news are: Using Linux (Ubuntu 16.04) it works. Devices are detected here as: ... [ 0.261209] pnp 00:01: [dma 0 disabled] [ 0.261295] pnp 00:01: Plug and Play ACPI device, IDs PNP0501 (active) [ 0.261774] pnp 00:02: [dma 0 disabled] [ 0.261868] pnp 00:02: Plug and Play ACPI device, IDs PNP0501 (active) ... [ 1.479082] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled [ 1.499962] 00:01: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A [ 1.520943] 00:02: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A and we can send and receive characters without problems. So it really seems FreeBSD does something wrong on the A2SAV board when it comes to interrupts of the serial ports. Any ideas how to start? From owner-freebsd-hackers@freebsd.org Tue Mar 13 18:11:38 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 089A7F3ACCB for ; Tue, 13 Mar 2018 18:11:38 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 80EA66C945 for ; Tue, 13 Mar 2018 18:11:37 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w2DIAmL2090183 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 13 Mar 2018 20:10:51 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w2DIAmL2090183 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w2DIAkUp090174; Tue, 13 Mar 2018 20:10:46 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 13 Mar 2018 20:10:46 +0200 From: Konstantin Belousov To: Andre Albsmeier Cc: freebsd-hackers@freebsd.org Subject: Re: UARTs not working on a Supermicro A2SAV / Linux works ;-( Message-ID: <20180313181046.GP76926@kib.kiev.ua> References: <20180313171432.GA11972@voyager> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180313171432.GA11972@voyager> User-Agent: Mutt/1.9.4 (2018-02-28) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 18:11:38 -0000 On Tue, Mar 13, 2018 at 06:14:32PM +0100, Andre Albsmeier wrote: > The UARTs on the brand new Supermicro A2SAV mainboard > (https://www.supermicro.com/products/motherboard/Atom/A2SAV.cfm) > are detected on 11.1-STABLE as > > uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 > > which is consistent with the BIOS settings. > > Everything seems to work when it comes to setting of parameters and even > the DTR and RTS lines change state when opening cuau0 or cuau1, e.g. with > minicom. > > But sending or receiving characters fails -- to be exact, no single > character will be received and only the very first one will be sent to > the remote device. > > We remember this behaviour from the good old times when we had to jumper > base port addresses and IRQs on ISA cards: If we got the IRQ wrong the > same effect happened: The first char could be sent because the TX register > was empty but the IRQ telling the kernel that it can send the next char > never arrived. > > When using debug.uart_force_poll=1 in loader.conf it works (at least if > we type in characters slowly, of course). > > So it really seems to have to do with interrupts again but I have no > idea where to look. > > The A2SAV manual talks about the Super I/O being a Nuvoton NCT5523D. Can > it be that we miss some support for this? But if the devices really behave > like standard 16550s we shouldn't need any specific support at all, I think. > > I disabled the corresponding ACPI functions by using > > debug.acpi.avoid="\_SB_.PCI0.SBRG.UAR1 \_SB_.PCI0.SBRG.UAR2" > > and the devices were detected properly as > > uart0: <16550 or compatible> at port 0x3f8 irq 4 flags 0x10 on isa0 > uart1: <16550 or compatible> at port 0x2f8 irq 3 on isa0 > > but this didn't help (same behaviour). > > The really bad news are: Using Linux (Ubuntu 16.04) it works. Devices are > detected here as: > ... > [ 0.261209] pnp 00:01: [dma 0 disabled] > [ 0.261295] pnp 00:01: Plug and Play ACPI device, IDs PNP0501 (active) > [ 0.261774] pnp 00:02: [dma 0 disabled] > [ 0.261868] pnp 00:02: Plug and Play ACPI device, IDs PNP0501 (active) > ... > [ 1.479082] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled > [ 1.499962] 00:01: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A > [ 1.520943] 00:02: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A > > and we can send and receive characters without problems. > > So it really seems FreeBSD does something wrong on the A2SAV board when > it comes to interrupts of the serial ports. > > Any ideas how to start? Bay Trail and later Atoms UARTS are not standard UARTs controllers, AFAIR the registers are memory mapped, to start with. They also support DMA, as you can see from the linux dmesg. Perhaps there are some incompatibilities with the new implementation. Can you show the vmstat -i output ? Are there any other non-MSI interrupts used on the machine, do they work ? For a minor chance, try to set hw.lapic_eoi_suppression to 0 at the loader prompt. From owner-freebsd-hackers@freebsd.org Tue Mar 13 18:50:57 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E8EF0F4156C for ; Tue, 13 Mar 2018 18:50:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 551AA6EAD4 for ; Tue, 13 Mar 2018 18:50:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w2DIojbe099256 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 13 Mar 2018 20:50:48 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w2DIojbe099256 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w2DIoiFe099252; Tue, 13 Mar 2018 20:50:45 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 13 Mar 2018 20:50:44 +0200 From: Konstantin Belousov To: Theron Cc: freebsd-hackers@freebsd.org Subject: Re: GSoC Idea: per-process filesystem namespaces for FreeBSD Message-ID: <20180313185044.GQ76926@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 18:50:57 -0000 On Tue, Mar 13, 2018 at 12:53:18PM -0400, Theron wrote: > Hello All, > > I am an undergraduate a Boston University looking to contribute to > FreeBSD this summer under GSoC. > > The idea I would like to implement is to bring to FreeBSD a per-process > mounting / namespaces functionality similar to that of the Plan9 > operating system as a means to give greater flexibility in combination > with less overhead than is associated with chroots and jails for > purposes of isolating software setups from one another and from the > underlying system. > > For those unfamiliar with Plan9, here is a rough explanation of the > namespace feature: unlike in Unix, where all processes share the same > virtual filesystem, each process instead has its own view of the > filesystem according to what has been mounted, which, unlike Unix mount, > as an unpriviliged operation changing only what is seen by the > particular process and any processes it later spawns. Thus it is > possible for one process's /bin to be completely different from another > process's /bin, and neither need be the same as the system's /bin, > should one exist. > > As an example of its application and potential usefulness, a user may > mount on top of /usr/local an overlay pointing to a location owned by > the user, allowing existing binary packages which expect a /usr/local > PREFIX to be installed and run without any modification either to the > binary packages or to the underlying system. Currently the only ways to Do you understand what consequences of this feature is, when mixed with setuid ? > achieve this are by recompiling ports with a different PREFIX or by > configuring a jail. Some, but not all, programs will function > out-of-place under tweaked PATH and LD_LIBRARY_PATH, but this is not a > general solution and leads to messy environments. > > Although I have not previously worked with kernel programming in > particular, I have good experience of high-level practices and low-level > details of C programming and I can teach myself new technical details > quickly. In researching how to approach the task, I will study the > existing implementation of chroot, jail, and fdescfs as examples of > process-specific namespace behavior already supported in FreeBSD > kernel. The nullfs and unionfs may also serve as work to build off of, > although unionfs as currently implemented appears to be partially broken. > > Robustness of the implementation allowing, it should eventually be > possible to replace system directories /bin, /sbin, /etc, etc. with > bindings configured at boot time to improve the safety of live system > upgrades and to provide a means of returning to older configurations > which is not dependent on filesystem-specific snapshotting features. > > Although per-process filesystem namespacing is unconventional in the > face of the dominant Unix single-namespace model, introducing the > feature to a Unix-like system does not constitute a radical change, as > it is compatible with and indeed facilitates the meeting of the > reasonable expectation of existing and unmodified software to find > resources in predetermined file paths. > > My attempt here to outline the relevant concepts is to the best of my > limited understanding. Hopefully I am not creating or propagating any > misinformation and have not grossly misassessed the complexity of the task. > > I would greatly appreciate any suggestions of approaches to this task > and of who to contact for more expertise and for potential mentorship. You need to understand a lot about the FreeBSD VFS to sketch the approach for implementation. I do not want to sound sceptical, but the amount of architectural work, and then the quantity of the details to discover and handle for this project certainly exceed the scope of GSoC. If you can formulate the basic ideas of the possible implementation, this might add more substance to the discussion. From owner-freebsd-hackers@freebsd.org Tue Mar 13 19:31:10 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D8427F49617 for ; Tue, 13 Mar 2018 19:31:09 +0000 (UTC) (envelope-from lists.br@gmail.com) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 457197051F for ; Tue, 13 Mar 2018 19:31:09 +0000 (UTC) (envelope-from lists.br@gmail.com) Received: by mail-wm0-x22f.google.com with SMTP id i194so43874wmg.1 for ; Tue, 13 Mar 2018 12:31:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KneaHTe+yHpA0sgL7BqnaEUVoH60QJzQJjH7xC5IOGk=; b=rH0vEB1VQ8m4ogAKVdkCVd3AfV5bpdzcsNdz+//Lgymm6kINzEYzPMZxjAp4nqn/3B 8NijdygeIcXlqs3pSwGCXVLTDrdy8JJNkailD44Tl9Z5io34RWxhH3jvD+xKWa+mh8CF Qg5cVRTuSNeQklRY0Z4W7auR2mnK+qAy4+7tBaIqpHdpQ+uSZyct6TTLglUPpXtzr8K1 LQ69fXnBEAPFYN08JSHpz15ZIIuM4QzowlmoKbqlAd2KnyOXBUc+4u4dXSvHVg3ob3yx RtBRPVS/Z4qM+Pfaym5B5BVewMqBbnspQ4zXUD9gXzex4eb6j/SwSiSGe+//xom8h+uG b5KQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KneaHTe+yHpA0sgL7BqnaEUVoH60QJzQJjH7xC5IOGk=; b=tBVds4V23nCfS6mAGqCde6qV/2ynTXCJ/aZqGI2EMEE80xayD07ObxIh+a9g1sac20 8W57ZAuMHl6q3qqWfXQN7vSNUmt1fon6cB0yqH8OVYdmloIA8UA2xZrJHRyfTmTPsUjm gI3gMbuT0IhKL2Vys+JK0+AKPUldUZGjR/pWGbZbuVxrHuPYBKRBeBgT0h8KLG9tGbLB iqKI8HBnOsHNQTzx/AEYDsdHJ1c5/jqVnNG7ASkrto0ZvxyA2ZpjW93Sw+74un4YAZpK p4zyb6CAvd9d+a92J3/dH6Q5bcl15bGVezC8bncMGq2e5DBKx+Q6xyiSya0TlGxDY5ve YRSA== X-Gm-Message-State: AElRT7GX3s2Igd/2arnj5sSl/r0ZpC0/5WyflvlY4ZxcO8mYN5d/JyAz EewkrGA+ToXqHOOsILHDO6rTTWbPkCPJ7qGz4JY= X-Google-Smtp-Source: AG47ELvH9M9CTkoAjqZyXjNRTUl1PhfHIMYRqcVnjSTMIMzs2hO84O3GRhqm3THYiJvycFIKHL/MEdZXlp6DW+WOIfE= X-Received: by 10.80.177.179 with SMTP id m48mr2004264edd.94.1520969467853; Tue, 13 Mar 2018 12:31:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.202.67 with HTTP; Tue, 13 Mar 2018 12:31:07 -0700 (PDT) In-Reply-To: <20180313181046.GP76926@kib.kiev.ua> References: <20180313171432.GA11972@voyager> <20180313181046.GP76926@kib.kiev.ua> From: Luiz Otavio O Souza Date: Tue, 13 Mar 2018 16:31:07 -0300 Message-ID: Subject: Re: UARTs not working on a Supermicro A2SAV / Linux works ;-( To: Konstantin Belousov Cc: Andre Albsmeier , freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 19:31:10 -0000 On 13 March 2018 at 15:10, Konstantin Belousov wrote: > On Tue, Mar 13, 2018 at 06:14:32PM +0100, Andre Albsmeier wrote: >> The UARTs on the brand new Supermicro A2SAV mainboard >> (https://www.supermicro.com/products/motherboard/Atom/A2SAV.cfm) >> are detected on 11.1-STABLE as >> >> uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 >> uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 >> >> which is consistent with the BIOS settings. >> >> Everything seems to work when it comes to setting of parameters and even >> the DTR and RTS lines change state when opening cuau0 or cuau1, e.g. with >> minicom. >> >> But sending or receiving characters fails -- to be exact, no single >> character will be received and only the very first one will be sent to >> the remote device. >> >> We remember this behaviour from the good old times when we had to jumper >> base port addresses and IRQs on ISA cards: If we got the IRQ wrong the >> same effect happened: The first char could be sent because the TX register >> was empty but the IRQ telling the kernel that it can send the next char >> never arrived. >> >> When using debug.uart_force_poll=1 in loader.conf it works (at least if >> we type in characters slowly, of course). >> >> So it really seems to have to do with interrupts again but I have no >> idea where to look. >> >> The A2SAV manual talks about the Super I/O being a Nuvoton NCT5523D. Can >> it be that we miss some support for this? But if the devices really behave >> like standard 16550s we shouldn't need any specific support at all, I think. >> >> I disabled the corresponding ACPI functions by using >> >> debug.acpi.avoid="\_SB_.PCI0.SBRG.UAR1 \_SB_.PCI0.SBRG.UAR2" >> >> and the devices were detected properly as >> >> uart0: <16550 or compatible> at port 0x3f8 irq 4 flags 0x10 on isa0 >> uart1: <16550 or compatible> at port 0x2f8 irq 3 on isa0 >> >> but this didn't help (same behaviour). >> >> The really bad news are: Using Linux (Ubuntu 16.04) it works. Devices are >> detected here as: >> ... >> [ 0.261209] pnp 00:01: [dma 0 disabled] >> [ 0.261295] pnp 00:01: Plug and Play ACPI device, IDs PNP0501 (active) >> [ 0.261774] pnp 00:02: [dma 0 disabled] >> [ 0.261868] pnp 00:02: Plug and Play ACPI device, IDs PNP0501 (active) >> ... >> [ 1.479082] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled >> [ 1.499962] 00:01: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A >> [ 1.520943] 00:02: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A >> >> and we can send and receive characters without problems. >> >> So it really seems FreeBSD does something wrong on the A2SAV board when >> it comes to interrupts of the serial ports. >> >> Any ideas how to start? > > Bay Trail and later Atoms UARTS are not standard UARTs controllers, AFAIR > the registers are memory mapped, to start with. They also support DMA, as > you can see from the linux dmesg. Perhaps there are some incompatibilities > with the new implementation. The system has both, UARTs and HSUARTs, the later will not work. Some recent BIOS have an option to route the system console to the first UART. > > Can you show the vmstat -i output ? Are there any other non-MSI > interrupts used on the machine, do they work ? > For a minor chance, try to set hw.lapic_eoi_suppression to 0 at the > loader prompt. There was an IOAPIC programming issue affecting these machines, it was fixed by r327314. Please Andre, can you check if this system boots fine with -head ? Luiz From owner-freebsd-hackers@freebsd.org Tue Mar 13 21:00:42 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DDA08F500E2 for ; Tue, 13 Mar 2018 21:00:41 +0000 (UTC) (envelope-from lidl@pix.net) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254:10::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.pix.net", Issuer "Pix.Com Technologies LLC CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 76A65758A4 for ; Tue, 13 Mar 2018 21:00:41 +0000 (UTC) (envelope-from lidl@pix.net) Received: from torb.pix.net (torb.pix.net [192.168.16.32]) (authenticated bits=0) by hydra.pix.net (8.15.2/8.15.2) with ESMTPA id w2DL0eYq084374; Tue, 13 Mar 2018 17:00:41 -0400 (EDT) (envelope-from lidl@pix.net) Subject: Re: UARTs not working on a Supermicro A2SAV / Linux works ;-( To: freebsd-hackers@freebsd.org References: <20180313171432.GA11972@voyager> From: Kurt Lidl Message-ID: <239d85a8-4e0a-660b-ccde-41edc2f85f19@pix.net> Date: Tue, 13 Mar 2018 17:00:40 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180313171432.GA11972@voyager> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 21:00:42 -0000 On 3/13/18 1:14 PM, Andre Albsmeier wrote: > The UARTs on the brand new Supermicro A2SAV mainboard > (https://www.supermicro.com/products/motherboard/Atom/A2SAV.cfm) > are detected on 11.1-STABLE as > > uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 > > which is consistent with the BIOS settings. > > Everything seems to work when it comes to setting of parameters and even > the DTR and RTS lines change state when opening cuau0 or cuau1, e.g. with > minicom. > > But sending or receiving characters fails -- to be exact, no single > character will be received and only the very first one will be sent to > the remote device. > > We remember this behaviour from the good old times when we had to jumper > base port addresses and IRQs on ISA cards: If we got the IRQ wrong the > same effect happened: The first char could be sent because the TX register > was empty but the IRQ telling the kernel that it can send the next char > never arrived. > > When using debug.uart_force_poll=1 in loader.conf it works (at least if > we type in characters slowly, of course). > > So it really seems to have to do with interrupts again but I have no > idea where to look. > > The A2SAV manual talks about the Super I/O being a Nuvoton NCT5523D. Can > it be that we miss some support for this? But if the devices really behave > like standard 16550s we shouldn't need any specific support at all, I think. > > I disabled the corresponding ACPI functions by using > > debug.acpi.avoid="\_SB_.PCI0.SBRG.UAR1 \_SB_.PCI0.SBRG.UAR2" > > and the devices were detected properly as > > uart0: <16550 or compatible> at port 0x3f8 irq 4 flags 0x10 on isa0 > uart1: <16550 or compatible> at port 0x2f8 irq 3 on isa0 > > but this didn't help (same behaviour). > > The really bad news are: Using Linux (Ubuntu 16.04) it works. Devices are > detected here as: > ... > [ 0.261209] pnp 00:01: [dma 0 disabled] > [ 0.261295] pnp 00:01: Plug and Play ACPI device, IDs PNP0501 (active) > [ 0.261774] pnp 00:02: [dma 0 disabled] > [ 0.261868] pnp 00:02: Plug and Play ACPI device, IDs PNP0501 (active) > ... > [ 1.479082] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled > [ 1.499962] 00:01: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A > [ 1.520943] 00:02: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A > > and we can send and receive characters without problems. > > So it really seems FreeBSD does something wrong on the A2SAV board when > it comes to interrupts of the serial ports. > > Any ideas how to start? So, at my prior job, we had a custom board that used the Novuton NCT5104 as the chip that provided the serial ports. One of the interesting things about the NCT5104 is that one can use in a PCI-only environments to provide serial ports. It offers the serial ports that traditionally would be provided by the traditonal Super I/O chipset, except that rather than having a large number of I/O lines, it's a LPC "low pin count" device. We had no legacy parts on the boards we manufactured, but we really, really wanted serial ports, so we ended up with this chip to provide the serial ports. Anyhow -- we had pretty much the same exact problem with the serial ports on our card. To make a long story short, I wrote a low-level register dumper for the NCT5104. One can make it act like a traditional NS16550A part, if you're willing to dink with the specific setup for the NCT5104. Here's the diff of the "non-working" serial port diagnostic, compared to the corrected version: # diff results_broken.txt results_fixed.txt 64c64 < sio register 0xf0 - value: 0x00 --- > sio register 0xf0 - value: 0x40 66c66 < IRQ mode: level --- > IRQ mode: pulse mode (for sharing) If you have a BIOS setting that allows you to control the IRQ method for the NCT part, try setting it to "pulse mode", rather than "level". We ended up resolving the issue by having the board manufacturer rev the BIOS, so that "BIOS defaults" value was set to "pulse mode", rather than "level" for this controller, and then FreeBSD was happy to use it as a regular old serial port. Alternatively, you can probably stick a little initialization bit of code in, to program the NCT5523D to change the interrupt setting. I was able to get the programming guide from Nuvoton just by asking nicely, so you can probably get it too, if you needed it. -Kurt From owner-freebsd-hackers@freebsd.org Tue Mar 13 20:02:35 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2D14FF4BBE7 for ; Tue, 13 Mar 2018 20:02:35 +0000 (UTC) (envelope-from ske@pkmab.se) Received: from mail1.bemta6.messagelabs.com (mail1.bemta6.messagelabs.com [193.109.254.115]) by mx1.freebsd.org (Postfix) with ESMTP id CEC0A71ACA for ; Tue, 13 Mar 2018 20:02:34 +0000 (UTC) (envelope-from ske@pkmab.se) Received: from [193.109.254.147] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-11.bemta-6.messagelabs.com id 16/AB-01262-5CC28AA5; Tue, 13 Mar 2018 19:55:49 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBIsWRWlGSWpSXmKPExsVycM+Pg7pHdVZ EGTz4rGGxffM/RgdGjxmf5rMEMEaxZuYl5VcksGZ82rCdveABc8XSTRsYGxh7mLsYOTmEBE4y Svz9mAlhH2eUeDUzoYuRC8iezijR8u4WC0hCWMBV4vj802wgtoiAisT0mU/ZQWwWAW2JuY+bw GqYBeQlHm4/A2ZzCqRK7LrxGMyWEFCQ+LJjHiuIzSsgKHFy5hOoeh2Jd30PwI5gE9CQmHernw WixlRi/bNFrBC9wRJ9s7+zQdhqElfPbWKG6NWWWLbwNfMERoFZSMbOQjJ2FpKyBYzMqxg1ilO LylKLdA2N9ZKKMtMzSnITM3N0DQ3M9HJTi4sT01NzEpOK9ZLzczcxAsOTAQh2MH5ZFnCIUZKD SUmU97jCiighvqT8lMqMxOKM+KLSnNTiQ4wyHBxKErzxwHAXEixKTU+tSMvMAUYKTFqCg0dJh Pe3NlCat7ggMbc4Mx0idYrRmKNt5ZM2Zo4bL163MQux5OXnpUqJ834BKRUAKc0ozYMbBIvgS4 yyUsK8jECnCfEUpBblZpagyr9iFOdgVBLmLQe5hyczrwRu3yugU5iATrlyYgnIKSWJCCmpBsa 8oCCnWxxzZuU8lU5nvtgvfOu/1hO5+fffVL2PfdI+TVAq3W3xM4W2WMEXmnV9vs5x9+TPW66S f8S21+SdQMqpGQ4HL2y9u9uYw2XZ1L1fP+9fl1PyK/yzwnefifwdOvX/DDgOSdZmXtY+k9krE Rxvc27dk4sZwveDVkkXdr7gvc4uPPXAhZ1KLMUZiYZazEXFiQAjY2bF2wIAAA== X-Env-Sender: ske@pkmab.se X-Msg-Ref: server-12.tower-27.messagelabs.com!1520970949!110918357!1 X-Originating-IP: [193.188.248.193] X-SYMC-ESS-Client-Auth: outbound-route-from=fail X-StarScan-Received: X-StarScan-Version: 9.9.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 48606 invoked from network); 13 Mar 2018 19:55:49 -0000 Received: from cdo-smtp32.composeit.net (HELO cdo-smtp32.composeit.net) (193.188.248.193) by server-12.tower-27.messagelabs.com with SMTP; 13 Mar 2018 19:55:49 -0000 Received: from cdo-smtp32.composeit.net (localhost [127.0.0.1]) by cdo-smtp32.composeit.net (Postfix) with ESMTP id 470D915663 for ; Tue, 13 Mar 2018 20:55:49 +0100 (CET) Received: from psy-app005.precio.lan (unknown [10.112.7.132]) by cdo-smtp32.composeit.net (Postfix) with ESMTP id 3C15C15662 for ; Tue, 13 Mar 2018 20:55:49 +0100 (CET) Received: from berenice.precio.lan ([172.27.68.201]) by psy-app005.precio.lan with Microsoft SMTPSVC(8.5.9600.16384); Tue, 13 Mar 2018 20:55:49 +0100 Subject: Re: GSoC Idea: per-process filesystem namespaces for FreeBSD To: Theron Date: Tue, 13 Mar 2018 20:55:46 +0100 (CET) Cc: freebsd-hackers@freebsd.org In-Reply-To: from "Theron" at Mar 13, 18 12:53:18 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 From: Kristoffer Eriksson Message-ID: <201803132055.aa28780@berenice.pkmab.se> X-OriginalArrivalTime: 13 Mar 2018 19:55:49.0195 (UTC) FILETIME=[48A611B0:01D3BB05] X-Virus-Scanned: ClamAV using ClamSMTP Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 13 Mar 2018 21:12:41 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 20:02:35 -0000 On 13 Mar 2018 12:53:18, Theron wrote: > For those unfamiliar with Plan9, here is a rough explanation of the > namespace feature: unlike in Unix, where all processes share the same > virtual filesystem, each process instead has its own view of the > filesystem according to what has been mounted ... What if I mount a new /etc with a passwd file where root has no password, and then run "su"? (How does Plan9 handle that?) Regards/Kristoffer Eriksson From owner-freebsd-hackers@freebsd.org Tue Mar 13 21:41:32 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3A61EF52D8B for ; Tue, 13 Mar 2018 21:41:32 +0000 (UTC) (envelope-from theron.tarigo@gmail.com) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C217677793 for ; Tue, 13 Mar 2018 21:41:31 +0000 (UTC) (envelope-from theron.tarigo@gmail.com) Received: by mail-qt0-x22b.google.com with SMTP id g60so1311678qtd.11 for ; Tue, 13 Mar 2018 14:41:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=44pBDOhOO5UU0k0l8RoLcmzPLTRE0Ddf13xNc0xYcvs=; b=dfqheE9bIAQrMilVrPvdMaCNNSmYnWkpN31blrTg0JpNE3B2dCZWKp+KLTTBagdf9O j5kruaz/AJZ6uzzUlKch5SQZt64P+RvepEbJBkx0XFX/IqlZix1YyBU8UvShbdoni+fS kbqeAc7Vx/vSnSnt+SH8wt5sUoWtdHpoL1pgGkPSR3CfiAouAMY44MoAP4XUatjvy/wz LfN9m/5agHNmeSbkvVgtedpu4xIT8si/PgvrBHyjEbbxWVGLvHQG/hbbXaVDZ9HZ2yWF PQtHLUTB5/BQ96w2i/HB92nSnByoLprrxhzb0C/jzt/3KsX9eXbNdP17cnwi2RTvQii1 YKuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=44pBDOhOO5UU0k0l8RoLcmzPLTRE0Ddf13xNc0xYcvs=; b=BwbWhLTmbWX5M2pkfpHafZkJuIBLDIiG62qTJm+tSGdXKutPrJAJbCbNEmxMOy5tG4 ncXJOEuzxAhY2+wYGptZE7rPh/BK9zfkqjNhMOaUbmls4Kv4pul/XU+34ZjfqkAufhpg cKvea0p7Qwekf9dJ3IgetWm7+FfXIDlNSzvYlcxwxOxvnDjHp1LayvKkFGxy/1kozXWC 1nuk2SCyh4ctftMbtdOubTTf5WmPm6NStLP57pzyV3TdITSY/2+c5rxglKQWCxwmgiv1 WO9fAWJvpqHhsD7Ijo/Q97aNpTDQfo3P+iErV2QIfAK+pR/yM6mfIyc+nXJxmXlSn6wM rswQ== X-Gm-Message-State: AElRT7F94/o+3SsXk9TX6Paznba1q0Uz72FXDldXHNPDgihhhaIW5/mq g1LgmbloSfvba68w2Z+KrTPVX+wG X-Google-Smtp-Source: AG47ELv4xp6515rSZjcnu+evc52BRyCq1rNwDkgBHiW/cGYZBtV24AHJOAwFMvFonyRfucvF28ujcA== X-Received: by 10.200.51.215 with SMTP id d23mr1104935qtb.338.1520977290846; Tue, 13 Mar 2018 14:41:30 -0700 (PDT) Received: from [155.41.26.230] (dhcp-wifi-8021x-155-41-26-230.bu.edu. [155.41.26.230]) by smtp.gmail.com with ESMTPSA id s184sm470367qke.55.2018.03.13.14.41.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Mar 2018 14:41:30 -0700 (PDT) Sender: Theron Tarigo Subject: Re: GSoC Idea: per-process filesystem namespaces for FreeBSD To: Kristoffer Eriksson Cc: freebsd-hackers@freebsd.org References: <201803132055.aa28780@berenice.pkmab.se> From: Theron Tarigo Message-ID: Date: Tue, 13 Mar 2018 17:41:28 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <201803132055.aa28780@berenice.pkmab.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 21:41:32 -0000 Hi Kristoffer, That will of course need to be worked out, since it is the classic safety problem  of chroot.  The first idea I can think of is that any user-switching (i.e. executing setuid files) resets the namespace, similarly to "su - " resetting the environment variables by way of simulating a new login.  Maybe it will not work out to be so simple, as I can see there will be a lot of research ahead for me, but I feel strongly that it will not be insurmountable.  If I implement this as a special filesystem rather than as a modification to the vfs, it can be as simple as not allowing any setuid, as with the "nosuid" option of existing filesystems. As I understand it, Plan9 uses namespaces so thoroughly that a superuser is not needed and all restrictions of privilege are accomplished through launching "unprivileged" processes into a namespace that contains only the resources that user should have access to.  While this may make sense within Plan9, it is sufficiently alien to the Unix ways of handling security that I don't think it makes any sense to try to do things this way on FreeBSD.  There will probably always be security risks associated with anything running as uid 0 regardless of restrictions to its environment.*  What I am trying to accomplish is to stay roughly within the Unix model but to provide a layer of flexibility appropriate for addressing a specific need, and the solution I have in mind happens to parallel a Plan9 concept. Theron * """      In addition, there are several ways in which an unprivileged user outside      the jail can cooperate with a privileged user inside the jail and thereby      obtain elevated privileges in the host environment. """ - JAIL(8) manual On 03/13/18 15:55, Kristoffer Eriksson wrote: > On 13 Mar 2018 12:53:18, Theron wrote: >> For those unfamiliar with Plan9, here is a rough explanation of the >> namespace feature: unlike in Unix, where all processes share the same >> virtual filesystem, each process instead has its own view of the >> filesystem according to what has been mounted ... > What if I mount a new /etc with a passwd file where root has no > password, and then run "su"? > > (How does Plan9 handle that?) > > Regards/Kristoffer Eriksson From owner-freebsd-hackers@freebsd.org Tue Mar 13 21:43:12 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0D012F531B8 for ; Tue, 13 Mar 2018 21:43:12 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 02A9177AD6 for ; Tue, 13 Mar 2018 21:43:10 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x234.google.com with SMTP id m83so1884256ioi.8 for ; Tue, 13 Mar 2018 14:43:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ZeLn/6tCWqD8K2vI7QjKJNzeOr5SPWa40O8E8oXQUos=; b=HgCYyc0OdvkACnOUWAwVxHVCXE17xPl5+r7Os9YEHlcajwd+/GZFyVjBRGhrHh4nUo ftC2QB+x5kX+6t03TMCy+0q5fg6l46Sqa/7ylg8ErnMPPrJgphx8zMwDoed/BFHhCNOQ SKO2NeqP6p5JuPHAUOPesQ6hMKHBghbTof7M5TVPcmNMoA2qK6QFsoh4u8bQtmR9mpcm f7CEobwV1MrzxUDXexvJH8UAF2F9aNR3/hHnLMNCPF2IfW4RWhZAWFw//IMs1220IdN1 3VSv919NNUAaLu/003eZbyP9U1258tBwESqNGxWG+jLjJwLM33xen0D5b4qs+SLpdc7P 8ttQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ZeLn/6tCWqD8K2vI7QjKJNzeOr5SPWa40O8E8oXQUos=; b=LnvpxOt7tW/CABfyWjie7Jgqb+44a5fFuKMDqBt9Ry0gT7Hu1BXD0DTK/oXtZrgw89 y0GmKQ4MWqI+96Wh/nN+h4y6l83bIr8RVyz0UHLc3cScv+TuYaD7Smqq3jiH1LVqkyTH kCL4IseydDJ8WVYyOSH5Hrh1jPwG6hPUam8AxXMNfXK2n7hzb07ykUEn7/TJEQRq+KWv dcPdGFTnXrlR4d5wKHI33JWDAanGBhIZbXJWlprP1GRJWJUstv7xkfbXUfwqGLgBsujC AMSjCfLsmKazXToQnK1dLOeYt8f+f5S4d62qWokWGLKZP6LaJKEB+Q/3Hy6ie4QUfGZq j3QA== X-Gm-Message-State: AElRT7GzbTiCCwaNLA9e2nSPoJqJt4pa1H+pppN/YhQkT5ytVoXD8xOO ZI2V+axvbomqOczO0m8Caac8P5uTvUbG2AKO/U6EcQ== X-Google-Smtp-Source: AG47ELs9DyJRvediyXx4sS95uMBsNP8CTdm00ycmMmu3cIHw8bZd1FbtryXqvX0IxUPNOlouSA9w81ORL4nBMVBO52c= X-Received: by 10.107.12.230 with SMTP id 99mr2418983iom.117.1520977389180; Tue, 13 Mar 2018 14:43:09 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.203.196 with HTTP; Tue, 13 Mar 2018 14:43:08 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <201803132055.aa28780@berenice.pkmab.se> References: <201803132055.aa28780@berenice.pkmab.se> From: Warner Losh Date: Tue, 13 Mar 2018 15:43:08 -0600 X-Google-Sender-Auth: OnU0_XUh9v_cUHawY5RcttLzuv0 Message-ID: Subject: Re: GSoC Idea: per-process filesystem namespaces for FreeBSD To: Kristoffer Eriksson Cc: Theron , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 21:43:12 -0000 On Tue, Mar 13, 2018 at 1:55 PM, Kristoffer Eriksson wrote: > > On 13 Mar 2018 12:53:18, Theron wrote: > > For those unfamiliar with Plan9, here is a rough explanation of the > > namespace feature: unlike in Unix, where all processes share the same > > virtual filesystem, each process instead has its own view of the > > filesystem according to what has been mounted ... > > What if I mount a new /etc with a passwd file where root has no > password, and then run "su"? > > (How does Plan9 handle that?) > Plan9 handles that by having a daemon that does user authentication. It's actually more complicated than that, but the machine owner has control over who can do what. For this to work in FreeBSD, either we'd need to disallow the 'file' type for passwd, or we'd have to do something sensible with setuid programs. Well, maybe not 'or' but 'and' since the security of setuid programs depends on the security of the filesystem.... Plan 9 doesn't have these complications, so it can offer a user malleable filesystem without security risk. Warner From owner-freebsd-hackers@freebsd.org Tue Mar 13 22:31:45 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 127A1F56574 for ; Tue, 13 Mar 2018 22:31:45 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A5DBE79B14 for ; Tue, 13 Mar 2018 22:31:44 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: by mail-qt0-x22c.google.com with SMTP id n12so1461155qtl.5 for ; Tue, 13 Mar 2018 15:31:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=longcount-org.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=v8yUVC6KtnLMjvci0EGZ3W8roNcdZEpPtVkzHVBMS8k=; b=VCwqfTWNHL4WegMllH3LyTBNjVEBXcm/qQcohMuZsFwcaMsizVrxbmYPe5CkAbTDQ2 jkQ0Ca3ZlBLx539eCCmEaAUvCAIhaGKCqiSCBLWgP+mtt9cbaGuc2Er5mCef0VrUr+gD 7+bD82x/fLp4ziLj0Pb3zC5/09CbfrnH1YhcA1i/+bIhhlk2ubxh51BWphjb/inyD9DZ tad5KeWo0U4eAThlyIhnQuocA12lDLtoxmnDNPYlirYeruQsZbDCF51POJhdXYrAQohl ngwiBzIbtSVPukKzeGznbDDECsno3isYvyITg2t18LFaABwn4VOh82gh1tjOa5BsVScP Ov7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=v8yUVC6KtnLMjvci0EGZ3W8roNcdZEpPtVkzHVBMS8k=; b=DwLoSg6qRe/de1IbKvAGgh6Y+L/a1ZISAs8JtzQvEZCC0MWz1UegH29sznsuGHhhk6 hs0OQgb3gwRacOODTCEpN2hpv4iV46jf2D1XFWzumTsM3GelNReYMg8aSDK3VDOClnDG Ea6mR7WypHF/vZS7heonOAaINBBbZPyfIPNlsg8S1NZPQsy6GNSODHxkzeDfEpzhGIiK bT6SS2l3sE3Us7R3SzbVuUU050tPuKdqNQK2D51+z98SUikKn4gFiLCcsoUxIGZFONv9 D8cKs3W+bjnYHr0RuofpWxBJ51af+5T/dtUWjgP6RtiWjQZzsRJys5rcyJMQrXByj/O+ tdtw== X-Gm-Message-State: AElRT7GWrUFruKOBm/03VoiMFsy4fISB0RpOKaiuUbndzPriYkp+CcPP 7kKd2i/hzffwcaIy/0AjcmVhwVJHEsI= X-Google-Smtp-Source: AG47ELvBOo2facIuKw1A3Lg0Y37UHjOXaMrPNgItHTS7mPPpUdHRwdHKN3yu2j8xG8gHHeH2cMkOYw== X-Received: by 10.200.36.189 with SMTP id s58mr3757938qts.0.1520980303660; Tue, 13 Mar 2018 15:31:43 -0700 (PDT) Received: from ?IPv6:2600:1017:b81e:56ea:9c09:d36e:402c:9f78? ([2600:1017:b81e:56ea:9c09:d36e:402c:9f78]) by smtp.gmail.com with ESMTPSA id 21sm603001qkk.10.2018.03.13.15.31.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Mar 2018 15:31:42 -0700 (PDT) Mime-Version: 1.0 (1.0) Subject: Re: GSoC Idea: per-process filesystem namespaces for FreeBSD From: Mark Saad X-Mailer: iPhone Mail (15D100) In-Reply-To: Date: Tue, 13 Mar 2018 18:31:41 -0400 Cc: Kristoffer Eriksson , Theron , Warner Losh Message-Id: References: <201803132055.aa28780@berenice.pkmab.se> To: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 22:31:45 -0000 > On Mar 13, 2018, at 5:43 PM, Warner Losh wrote: >=20 >> On Tue, Mar 13, 2018 at 1:55 PM, Kristoffer Eriksson wrote= : >>=20 >>=20 >>> On 13 Mar 2018 12:53:18, Theron wrote: >>> For those unfamiliar with Plan9, here is a rough explanation of the >>> namespace feature: unlike in Unix, where all processes share the same >>> virtual filesystem, each process instead has its own view of the >>> filesystem according to what has been mounted ... >>=20 >> What if I mount a new /etc with a passwd file where root has no >> password, and then run "su"? >>=20 >> (How does Plan9 handle that?) >>=20 >=20 > Plan9 handles that by having a daemon that does user authentication. It's > actually more complicated than that, but the machine owner has control ove= r > who can do what. For this to work in FreeBSD, either we'd need to disallow= > the 'file' type for passwd, or we'd have to do something sensible with > setuid programs. Well, maybe not 'or' but 'and' since the security of > setuid programs depends on the security of the filesystem.... Plan 9 > doesn't have these complications, so it can offer a user malleable > filesystem without security risk. >=20 > Warner A kind of related task; FreeBSD could benefit from : Fixing and improving u= nionfs / nullfs. There are some weird issues with the current unionfs and wh= ile it works in many cases there are some edge cases where the comments are s= omething like =E2=80=9C FreeBSD needs a proper stacking vfs ...=E2=80=9D t= he examples I can think of ; imagine you have a jail , chroot or even a Pxe b= ooted system where you want a a read only null mount from the hosts /bin to t= he targets /bin . Now expand that to most of the base system and the mount t= mpfs=E2=80=99s for /tep /var/log etc. most of that works but try to unmount= it in the wrong order or thrash a unionfs with lots of writes ,on top of a t= mpfs and things break .=20 So to be clear the project would be to better document the various uses of u= nionfs and nullfs that work , for the ones that do not diving into the stack= ing vfs and seeing if it could be implemented and if it would help .=20 Alternatively making FreeBSD multiboot compliant would rock . This would all= ow FreeBSD to natively boot from ipxe or syslinux derivates; thus allowing y= ou to boot a working FreeBSD install via a kernel and mfsroot image off a we= b server . http://netbsd.gw.com/cgi-bin/man-cgi?multiboot+8+NetBSD-current http://ipxe.org/ --- Mark Saad | nonesuch@longcount.org > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"= From owner-freebsd-hackers@freebsd.org Tue Mar 13 22:34:06 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4070AF567D1 for ; Tue, 13 Mar 2018 22:34:06 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (ns1.bitblocks.com [173.228.5.8]) by mx1.freebsd.org (Postfix) with ESMTP id D08CE79CF8 for ; Tue, 13 Mar 2018 22:34:05 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 2929E156E812; Tue, 13 Mar 2018 15:23:28 -0700 (PDT) From: Bakul Shah To: Warner Losh cc: Kristoffer Eriksson , Theron , "freebsd-hackers@freebsd.org" Subject: Re: GSoC Idea: per-process filesystem namespaces for FreeBSD In-reply-to: Your message of "Tue, 13 Mar 2018 15:43:08 -0600." References: <201803132055.aa28780@berenice.pkmab.se> Comments: In-reply-to Warner Losh message dated "Tue, 13 Mar 2018 15:43:08 -0600." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <58342.1520979807.1@bitblocks.com> Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Mar 2018 15:23:27 -0700 Message-Id: <20180313222344.2929E156E812@mail.bitblocks.com> X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 22:34:06 -0000 On Tue, 13 Mar 2018 15:43:08 -0600 Warner Losh wrote: Warner Losh writes: > On Tue, Mar 13, 2018 at 1:55 PM, Kristoffer Eriksson wrot= e: > = > > > > On 13 Mar 2018 12:53:18, Theron wrote: > > > For those unfamiliar with Plan9, here is a rough explanation of the > > > namespace feature: unlike in Unix, where all processes share the sam= e > > > virtual filesystem, each process instead has its own view of the > > > filesystem according to what has been mounted ... > > > > What if I mount a new /etc with a passwd file where root has no > > password, and then run "su"? > > > > (How does Plan9 handle that?) > > > = > Plan9 handles that by having a daemon that does user authentication. It'= s > actually more complicated than that, but the machine owner has control o= ver > who can do what. For this to work in FreeBSD, either we'd need to disall= ow > the 'file' type for passwd, or we'd have to do something sensible with > setuid programs. Well, maybe not 'or' but 'and' since the security of > setuid programs depends on the security of the filesystem.... Plan 9 > doesn't have these complications, so it can offer a user malleable > filesystem without security risk. Plan9 has no root (superuser) or setuid. You can mangle anything in your namespace but it affects only *your* own process and its future descendents. The following paper on Plan9 authentication in Linux may be worth reading: https://static.googleusercontent.com/media/research.google.com/en//pub= s/archive/34433.pdf While I have wanted per-process namespace in BSD for a long time, I agree with Konstantin this is a non-trivial project. Even if the design was fully fleshed out, implementing it would likely take longer than 12 weeks. From owner-freebsd-hackers@freebsd.org Tue Mar 13 23:16:51 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C36A55E4 for ; Tue, 13 Mar 2018 23:16:50 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 576067BB99 for ; Tue, 13 Mar 2018 23:16:50 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22b.google.com with SMTP id u84so2113715iod.9 for ; Tue, 13 Mar 2018 16:16:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=cTa81h6/z1KS5YFlSaRhtTyQj/shBEZzC+Lt3AUJggA=; b=Etdn+/Xb6GaAtNWDrjJfbNpVVhhHM+/lRn7TJvvoe8zf7LdThgxPizzZ85CozuKGo3 6xKBfggcAyVCAizoNKxnU8iar+7XDsPTY+157UpQbQ6gmPyxXj3l1lddBUOxf+siS8+P 1DYZiZa80ski1Xwx9tjmAt9fL1kbycfJ26ZmgkonXUOnJnaCcqRM5mXPHL5Z2tFxMOYT q82TCvC1LwKjKoEYV2dbj4jtM6Xtb5BVThY3a5WyH9OAQ6S83Bsmznxfctux0aocHhVl YhKtcd9LbHuWBmTUzFD+6Q7LAPJr3CjB0RvCbxEpVfbNPGlOIkZhi2JeOwaY7H0rN+av pE/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=cTa81h6/z1KS5YFlSaRhtTyQj/shBEZzC+Lt3AUJggA=; b=rbUBMuDXnJ5K+qPXZ/BX/zu3dZYI2C+wE/zL6x87S5+ZtYsBhAmIeimipU66C68YfI LTrebZuzn+eymG+DkddlZVFB342MH60oFrnOuIlui/R51mxR37C4qOZV4DS5NEOEmv2P FzsJHW1CxV+F6sJs2qi6d0Jx3uQ+iphOFT2vbVxrPt71CHHY14uA0dvjFqlzm3t7gRFf LrxUvo5qZE2ND0EvlIDQimDmY1nMnScqvvJ61bkg961qyYJU3OGeD4pOTuPPTcfxQJ74 F/yiGg9L4vd9Gu88ViDF9+4NYJAwlUGbnvuwi4/qj/vPaDOG3dScrWqMsQVzTmRvWRg7 4sag== X-Gm-Message-State: AElRT7FC2Hjare7OSNHlWuVd+XUki3+szwz5QnsUmtTJLZ+e8VfyGQrO w64RL1//bMfn9Icyp4rGZctpDHzoo/vTX69jsQh6oA== X-Google-Smtp-Source: AG47ELsl7Fe7bGfYkR8eaqC4edf9HItxL6XqSd/d0yXNhnwVt+16nCGdLlyTsN8UCcFa0I1oWm0hAhWfHN3NqKSzDDM= X-Received: by 10.107.18.162 with SMTP id 34mr2678389ios.168.1520983009421; Tue, 13 Mar 2018 16:16:49 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.203.196 with HTTP; Tue, 13 Mar 2018 16:16:48 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:18a2:a4f7:170:8dd9] In-Reply-To: References: <201803132055.aa28780@berenice.pkmab.se> From: Warner Losh Date: Tue, 13 Mar 2018 17:16:48 -0600 X-Google-Sender-Auth: Fz9VUnb4e15vlIaxe-yJKsQ3lew Message-ID: Subject: Re: GSoC Idea: per-process filesystem namespaces for FreeBSD To: Mark Saad Cc: "freebsd-hackers@freebsd.org" , Kristoffer Eriksson , Theron Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 23:16:51 -0000 On Tue, Mar 13, 2018 at 4:31 PM, Mark Saad wrote: > > On Mar 13, 2018, at 5:43 PM, Warner Losh wrote: > > On Tue, Mar 13, 2018 at 1:55 PM, Kristoffer Eriksson wrote= : > > > On 13 Mar 2018 12:53:18, Theron wrote: > > For those unfamiliar with Plan9, here is a rough explanation of the > > namespace feature: unlike in Unix, where all processes share the same > > virtual filesystem, each process instead has its own view of the > > filesystem according to what has been mounted ... > > > What if I mount a new /etc with a passwd file where root has no > > password, and then run "su"? > > > (How does Plan9 handle that?) > > > > Plan9 handles that by having a daemon that does user authentication. It's > actually more complicated than that, but the machine owner has control ov= er > who can do what. For this to work in FreeBSD, either we'd need to disallo= w > the 'file' type for passwd, or we'd have to do something sensible with > setuid programs. Well, maybe not 'or' but 'and' since the security of > setuid programs depends on the security of the filesystem.... Plan 9 > doesn't have these complications, so it can offer a user malleable > filesystem without security risk. > > Warner > > > A kind of related task; FreeBSD could benefit from : Fixing and > improving unionfs / nullfs. There are some weird issues with the current > unionfs and while it works in many cases there are some edge cases where > the comments are something like =E2=80=9C FreeBSD needs a proper stacking= vfs ...=E2=80=9D > the examples I can think of ; imagine you have a jail , chroot or even = a > Pxe booted system where you want a a read only null mount from the hosts > /bin to the targets /bin . Now expand that to most of the base system and > the mount tmpfs=E2=80=99s for /tep /var/log etc. most of that works but = try to > unmount it in the wrong order or thrash a unionfs with lots of writes ,on > top of a tmpfs and things break . > So to be clear the project would be to better document the various uses o= f > unionfs and nullfs that work , for the ones that do not diving into the > stacking vfs and seeing if it could be implemented and if it would help . > > Alternatively making FreeBSD multiboot compliant would rock . This would > allow FreeBSD to natively boot from ipxe or syslinux derivates; thus > allowing you to boot a working FreeBSD install via a kernel and mfsroot > image off a web server . > There appears to already be a multiboot.c in the bootloader. I've been told by others in the past it just works... Warner From owner-freebsd-hackers@freebsd.org Wed Mar 14 00:00:04 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 198C8F2C9FE for ; Wed, 14 Mar 2018 00:00:04 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AEACB7D556 for ; Wed, 14 Mar 2018 00:00:03 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: by mail-qk0-x235.google.com with SMTP id y137so1657634qka.4 for ; Tue, 13 Mar 2018 17:00:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=longcount-org.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=A4AwSKlTV8Y+yBxLSKXR9KGdxY1BuRaYF0yGfSL0XpY=; b=KyZMapPcTBkeh93gxq22j+jQ3buQ174BvN6t2GIKZ6k5msjb33/GGSthdcwKMTk5Ag J/po4ljIT98pob4kd2EHxLq23o8ubT3pUcvSmfqeDqEY5ncGzZ2NBbczrHNN2zZ6CYFq lOPqOzsUMPDEx7NpRF9dhSXl57faFhZOC9btosK1z/h3dib3Nt/7WdqLRPTdakVx1/dS CSXPAZ06UidYPn0/HRkOmbl66PHITIl+gOpmM3TsaJNAkGZB7M4cAFT93QsfGL+R35xP 2l5HhylhFQRilzdd1/dKLzgARBKDTIVkV2pm7bipBnSIunGzh8+p41Op53tp2pkrEdmM 7Hwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=A4AwSKlTV8Y+yBxLSKXR9KGdxY1BuRaYF0yGfSL0XpY=; b=U2ShS7gM+tFhimt+rIXzKGP0qyWY2Eb3YMeiak8+sLrPHfPzmyl9lon2cG+ZigZ+Kt xqppZNAmcxUKtlFRVYJ9Pyi8rHE1w+/l4XITI0n6bIb4Iu/dJ30YOOkkQWtndDXOVmm3 cdPbdcymbauRVdCCnzDDW3m0Hky/A1w5F2Ea2rJkgWIVyn8Aar+L3/KH3uMdNyUJRic6 A5wxnqUI3h00q24JWE35XhWPA/wFAF1nXC9nKBSlm+kUS8+Nl84SVWcaRUM7QaDDDc3P eVDgM32PadVn7u5FaZEZdul6UUgpmtMly/KccfCj7GdqsD0JVCGvgduLUGTfq49W5x9V 3+PA== X-Gm-Message-State: AElRT7H+fyBUTAhJsYXzPpn4Jzmo3I39DUnd2ytkleN5CoZe2qVdsUtm uMKnY41Y76nj0lA29cXp5gUBwDM6atA= X-Google-Smtp-Source: AG47ELvpsZny1XzZHBbhI8BoY86hfbCCyzxIIPiNeq6GnL0fDril8psfmIvkuXhEYynS1Hf1BVvLHg== X-Received: by 10.55.16.135 with SMTP id 7mr3722166qkq.85.1520985602838; Tue, 13 Mar 2018 17:00:02 -0700 (PDT) Received: from [192.168.1.41] (ool-435225e3.dyn.optonline.net. [67.82.37.227]) by smtp.gmail.com with ESMTPSA id f13sm988652qtj.63.2018.03.13.17.00.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Mar 2018 17:00:01 -0700 (PDT) Mime-Version: 1.0 (1.0) Subject: Re: GSoC Idea: per-process filesystem namespaces for FreeBSD From: Mark Saad X-Mailer: iPhone Mail (15D100) In-Reply-To: Date: Tue, 13 Mar 2018 20:00:00 -0400 Cc: "freebsd-hackers@freebsd.org" , Kristoffer Eriksson , Theron Message-Id: References: <201803132055.aa28780@berenice.pkmab.se> To: Warner Losh Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 00:00:04 -0000 > On Mar 13, 2018, at 7:16 PM, Warner Losh wrote: >=20 >=20 >=20 >> On Tue, Mar 13, 2018 at 4:31 PM, Mark Saad wrote= : >>=20 >>> On Mar 13, 2018, at 5:43 PM, Warner Losh wrote: >>>=20 >>>> On Tue, Mar 13, 2018 at 1:55 PM, Kristoffer Eriksson wro= te: >>>>=20 >>>>=20 >>>>> On 13 Mar 2018 12:53:18, Theron wrote: >>>>> For those unfamiliar with Plan9, here is a rough explanation of the >>>>> namespace feature: unlike in Unix, where all processes share the same >>>>> virtual filesystem, each process instead has its own view of the >>>>> filesystem according to what has been mounted ... >>>>=20 >>>> What if I mount a new /etc with a passwd file where root has no >>>> password, and then run "su"? >>>>=20 >>>> (How does Plan9 handle that?) >>>>=20 >>>=20 >>> Plan9 handles that by having a daemon that does user authentication. It'= s >>> actually more complicated than that, but the machine owner has control o= ver >>> who can do what. For this to work in FreeBSD, either we'd need to disall= ow >>> the 'file' type for passwd, or we'd have to do something sensible with >>> setuid programs. Well, maybe not 'or' but 'and' since the security of >>> setuid programs depends on the security of the filesystem.... Plan 9 >>> doesn't have these complications, so it can offer a user malleable >>> filesystem without security risk. >>>=20 >>> Warner >>=20 >> A kind of related task; FreeBSD could benefit from : Fixing and improvi= ng unionfs / nullfs. There are some weird issues with the current unionfs an= d while it works in many cases there are some edge cases where the comments a= re something like =E2=80=9C FreeBSD needs a proper stacking vfs ...=E2=80=9D= the examples I can think of ; imagine you have a jail , chroot or even a P= xe booted system where you want a a read only null mount from the hosts /bin= to the targets /bin . Now expand that to most of the base system and the mo= unt tmpfs=E2=80=99s for /tep /var/log etc. most of that works but try to un= mount it in the wrong order or thrash a unionfs with lots of writes ,on top o= f a tmpfs and things break .=20 >> So to be clear the project would be to better document the various uses o= f unionfs and nullfs that work , for the ones that do not diving into the st= acking vfs and seeing if it could be implemented and if it would help .=20 >>=20 >> Alternatively making FreeBSD multiboot compliant would rock . This would a= llow FreeBSD to natively boot from ipxe or syslinux derivates; thus allowing= you to boot a working FreeBSD install via a kernel and mfsroot image off a w= eb server . >=20 > There appears to already be a multiboot.c in the bootloader. I've been tol= d by others in the past it just works... >=20 > Warner I am going down the rabbit hole to see how it works . However I still think the unionfs / nullfs work I mentioned before would be a= good project related to the plan9 idea in some ways .=20 --- Mark Saad | nonesuch@longcount.org= From owner-freebsd-hackers@freebsd.org Wed Mar 14 00:16:50 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7D99CF2F245 for ; Wed, 14 Mar 2018 00:16:50 +0000 (UTC) (envelope-from theron.tarigo@gmail.com) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 10E1C7E264 for ; Wed, 14 Mar 2018 00:16:50 +0000 (UTC) (envelope-from theron.tarigo@gmail.com) Received: by mail-qt0-x22f.google.com with SMTP id g60so1660057qtd.11 for ; Tue, 13 Mar 2018 17:16:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=Y1zuGJ6mlmHOF5ewRm5/zdJSLflUCLG43Ullob6GQE8=; b=DGDLxIcTUXdqZ+R7f2lXFGanJRxorKGmmjZVWOpdu/6zxCe2qQtVF0L9F8fFzg7CUO 0SjUMtEUiGTZsSR8sW6x9XI0gg50Dts6FDct/Jy6b3HDiYIqILAqtb8nLsVsmKaBLYtV Nw33+n2BAE5PZ1zburmnBvCbJKBynXJECSc8XsMHfPNaFAjba1GARLu2eWxkkA/C6dYE YAuPx/7/XZuPeW4b35agOK2yr7SFZkT9kyIFY07N4OnlZXMgenfMfu8p2kQVfZ9TSQhB pBS5f7Srf7Igw2mNidap3JAOyyhtBhoIHfOPUYbTrHjDMSsGoG00CJT9XjAx21vZHIXx 6mbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=Y1zuGJ6mlmHOF5ewRm5/zdJSLflUCLG43Ullob6GQE8=; b=QAemzgFdBtg3nIYWLKyH+SL4BTl6gH5iYjuE10rozkSbuuOBt/O75uucYhEAdr/so5 /eabtqe86iEsqaBN0IpcsbztrqGC6hv+u5tAcC9NHITF7eTUs+qIK5kedJJIAk0DrO2Q exqFxRMI/EE1xD54uVBxRfF9If94xoUGCFRCcWM7pGfy4szFzY2xf3HUrza1hrTUMX9v vQzeX66G0B8il2Q4UGLOrSqr3Q2hIP4lWcaKg4NHnvlAqHsFpo7yARJ2DwRkZ62nz7DZ dfLAlSg2A9Jwt9qrQRujuGvt7lglxCLVwQhFfexmLcUwnYUU4lyb0FX88s8gLMKTnM06 1jUg== X-Gm-Message-State: AElRT7HUVYlCRKSbIZFM7WrWIxqB3Xcwp5pIFY6Cj1Ds9y7Q8RMAdznW 3LhX15mBpTuFAX2ZGq+XYll2IlIpsNI= X-Google-Smtp-Source: AG47ELvGtImuTxp8FaykdfDHEZbwlMYFAAvIWn8sVfFmnVASvTysc8Fp3Xj7e88/Q24f/M9Be9K+lg== X-Received: by 10.237.38.231 with SMTP id q94mr4066308qtd.60.1520986609267; Tue, 13 Mar 2018 17:16:49 -0700 (PDT) Received: from [155.41.26.230] (dhcp-wifi-8021x-155-41-26-230.bu.edu. [155.41.26.230]) by smtp.gmail.com with ESMTPSA id h184sm658491qkc.78.2018.03.13.17.16.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Mar 2018 17:16:48 -0700 (PDT) Sender: Theron Tarigo Subject: Re: GSoC Idea: per-process filesystem namespaces for FreeBSD To: Bakul Shah , Warner Losh , Mark Saad Cc: Kristoffer Eriksson , "freebsd-hackers@freebsd.org" References: <201803132055.aa28780@berenice.pkmab.se> <20180313222344.2929E156E812@mail.bitblocks.com> From: Theron Tarigo Message-ID: <1f8fc07b-9bf0-f9b2-ae7e-7cb0919722d0@gmail.com> Date: Tue, 13 Mar 2018 20:16:47 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180313222344.2929E156E812@mail.bitblocks.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 00:16:50 -0000 On 03/13/18 18:23, Bakul Shah wrote: > Plan9 has no root (superuser) or setuid. You can mangle > anything in your namespace but it affects only *your* own > process and its future descendents. > > The following paper on Plan9 authentication in Linux may be > worth reading: > https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/34433.pdf > > While I have wanted per-process namespace in BSD for a long > time, I agree with Konstantin this is a non-trivial project. > Even if the design was fully fleshed out, implementing it > would likely take longer than 12 weeks. Although it would limit the usefulness of it, ignoring any and all file suid bits for any process with a non-empty mount table should in theory prevent exploitation of setuid.  Allowing safe setuid in combination with ("trusted" ?) namespaces would be something to add support for much later if someone decides it would be useful. By focusing on a narrowed case, that of allowing an unprivileged process to alter its view into the vfs in a way which is only preserved through execve() in specific safe circumstances, I hoped to avoid the insurmountable complexity of implementing the feature in the full generality that is available on Plan9. On 03/13/18 18:31, Mark Saad wrote: >  A kind of related task; FreeBSD could benefit from : Fixing  and > improving unionfs / nullfs. There are some weird issues with the > current unionfs and while it works in many cases there are some edge > cases where the comments are something like “ FreeBSD needs a proper > stacking vfs ...”   the examples I can think of ; imagine you have a > jail , chroot or even a Pxe booted system where you want a a read only > null mount from the hosts /bin to the targets /bin . Now expand that > to most of the base system and the mount tmpfs’s for /tep /var/log > etc.  most of that works but try to unmount it in the wrong order or > thrash a unionfs with lots of writes ,on top of a tmpfs and things > break . > So to be clear the project would be to better document the various > uses of unionfs and nullfs that work , for the ones that do not diving > into the stacking vfs and seeing if it could be implemented and if it > would help . > Using nullfs / unionfs in combination with chroot could be made functionally equivalent to per-process namespace, but would have the very same security problems as already discussed (as any chroot have) so configuring such environments would be available only to superuser. So it appears that the most significant obstacle to achieving at least an approximation of the behavior of user-controlled per-process namespace is managing setuid safely. One thought I had is to do all of this purely in user-space by creating an extension to libc which allows appropriately linked programs to find files according to some set of prefixes defining the namespace, defined through an environment variable, but have all system interactions function in the normal ways.  Would this be sufficiently general to be of any use?  If this approach does pose any security threats, it indicates a hole is already present in the system! (MacOS once had a problem with allowing privileged programs to be launched under a modified library path...) On 03/13/18 20:00, Mark Saad wrote: > However I still think the unionfs / nullfs work I mentioned before > would be a good project related to the plan9 idea in some ways . Is there a way I could go about fixing up unionfs while also making significant progress towards eventual support for true per-process namespace? Theron From owner-freebsd-hackers@freebsd.org Wed Mar 14 01:18:40 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6C74BF33DD5 for ; Wed, 14 Mar 2018 01:18:40 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DA7148068F for ; Wed, 14 Mar 2018 01:18:39 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w2E1ISvH085771; Tue, 13 Mar 2018 18:18:28 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w2E1IRJl085770; Tue, 13 Mar 2018 18:18:27 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201803140118.w2E1IRJl085770@pdx.rh.CN85.dnsmgr.net> Subject: Re: GSoC Idea: per-process filesystem namespaces for FreeBSD In-Reply-To: To: Warner Losh Date: Tue, 13 Mar 2018 18:18:27 -0700 (PDT) CC: Mark Saad , Kristoffer Eriksson , "freebsd-hackers@freebsd.org" , Theron X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 01:18:40 -0000 ... non related text deleted ... > > Alternatively making FreeBSD multiboot compliant would rock . This would > > allow FreeBSD to natively boot from ipxe or syslinux derivates; thus > > allowing you to boot a working FreeBSD install via a kernel and mfsroot > > image off a web server . > > > > There appears to already be a multiboot.c in the bootloader. I've been told > by others in the past it just works... I run a test bed that PXE boots FreeBSD {10,11,12}{i386,amd64} using FreeBSD 11.1 as the service provider. I have a specially saved version of /boot/pxeboot that gets broken and fixed several times over that evolution that i have to place in each server image to get it working, I do not know if ^head's /boot/pxeboot works for me or not, I'll try it again soon. This system uses stock FreeBSD + isc-dhcp + iPXE. Everything else is pretty much untouched. This same environment via syslinux add ons to iPXE supports running most .iso images as a netbooted payload, known working are ESXi 5.5, and 6.5, as I use those frequently. Michael Dexter is using similiar tooling to netboot via PXE bhyve instances running as far back as the FreeBSD 5, though this requires some modifications of things in those releases do to non working code. So in final summary, Warner is right "it just works", though there are a few pointy sticks to get hung up on. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Wed Mar 14 01:25:59 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 32BF0F378BA for ; Wed, 14 Mar 2018 01:25:59 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9A43E80D19 for ; Wed, 14 Mar 2018 01:25:58 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w2E1Psc3085811; Tue, 13 Mar 2018 18:25:54 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w2E1Ps8j085810; Tue, 13 Mar 2018 18:25:54 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201803140125.w2E1Ps8j085810@pdx.rh.CN85.dnsmgr.net> Subject: Re: GSoC Idea: per-process filesystem namespaces for FreeBSD In-Reply-To: To: Mark Saad Date: Tue, 13 Mar 2018 18:25:54 -0700 (PDT) CC: Warner Losh , Kristoffer Eriksson , "freebsd-hackers@freebsd.org" , Theron X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 01:25:59 -0000 > > On Mar 13, 2018, at 7:16 PM, Warner Losh wrote: > > > > > > > >> On Tue, Mar 13, 2018 at 4:31 PM, Mark Saad wrote: > >> > >>> On Mar 13, 2018, at 5:43 PM, Warner Losh wrote: > >>> > >>>> On Tue, Mar 13, 2018 at 1:55 PM, Kristoffer Eriksson wrote: > >>>> > >>>> > >>>>> On 13 Mar 2018 12:53:18, Theron wrote: > >>>>> For those unfamiliar with Plan9, here is a rough explanation of the > >>>>> namespace feature: unlike in Unix, where all processes share the same > >>>>> virtual filesystem, each process instead has its own view of the > >>>>> filesystem according to what has been mounted ... > >>>> > >>>> What if I mount a new /etc with a passwd file where root has no > >>>> password, and then run "su"? > >>>> > >>>> (How does Plan9 handle that?) > >>>> > >>> > >>> Plan9 handles that by having a daemon that does user authentication. It's > >>> actually more complicated than that, but the machine owner has control over > >>> who can do what. For this to work in FreeBSD, either we'd need to disallow > >>> the 'file' type for passwd, or we'd have to do something sensible with > >>> setuid programs. Well, maybe not 'or' but 'and' since the security of > >>> setuid programs depends on the security of the filesystem.... Plan 9 > >>> doesn't have these complications, so it can offer a user malleable > >>> filesystem without security risk. > >>> > >>> Warner > >> > >> A kind of related task; FreeBSD could benefit from : Fixing and improving unionfs / nullfs. There are some weird issues with the current unionfs and while it works in many cases there are some edge cases where the comments are something like ? FreeBSD needs a proper stacking vfs ...? the examples I can think of ; imagine you have a jail , chroot or even a Pxe booted system where you want a a read only null mount from the hosts /bin to the targets /bin . Now expand that to most of the base system and the mount tmpfs?s for /tep /var/log etc. most of that works but try to unmount it in the wrong order or thrash a unionfs with lots of writes ,on top of a tmpfs and things break . > >> So to be clear the project would be to better document the various uses of unionfs and nullfs that work , for the ones that do not diving into the stacking vfs and seeing if it could be implemented and if it would help . > >> > >> Alternatively making FreeBSD multiboot compliant would rock . This would allow FreeBSD to natively boot from ipxe or syslinux derivates; thus allowing you to boot a working FreeBSD install via a kernel and mfsroot image off a web server . > > > > There appears to already be a multiboot.c in the bootloader. I've been told by others in the past it just works... > > > > Warner > > I am going down the rabbit hole to see how it works . If you have any questions I am happy to share my working tooling. ... isc-dhcp from ports, base system tftp setup via inetd some bits of syslinix 6.03 proper set of iPXE.exe binaries built with iSCSI, http and nfs support, you wont need iSCSI, I use that for other things like Windblows. I boot direct from iPXE to nfs loaded kernel, only thing tftp is used for is getting a modern version of iPXE onto the booting system. iPXE loads a menu.ipxe to allow OS selection. menu.ipxe loads /boot/pxeboot via NFS YOU SHALL HAVE ISSUES HERE most pxeboot images are broken pxeboot loads kernel via NFS kernel runs, end up in /etc/rc.diskless that does the rest of the magic. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Wed Mar 14 01:35:06 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3EA06F3A584 for ; Wed, 14 Mar 2018 01:35:06 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A3D80812F2 for ; Wed, 14 Mar 2018 01:35:05 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: by mail-wm0-x22a.google.com with SMTP id h21so976151wmd.1 for ; Tue, 13 Mar 2018 18:35:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=longcount-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=fD8lb8MgTZ+lHtYLdUWYTsQgZwLBL7TRD/P7pYSLe00=; b=KdptHDccphI33pWvrEBNf75sxPzJdaWvJzW/AQHeL7HKAPHykpsoF8aBDh3THS5A9P Nv60WgZguEo6k9xJzSmwzAu23L7V6AoN7F7YbN4l2ieEzfSjTifzH3qeXF7mjFpPJRmz f3OfTMobgJzZYEWblDSlMuQSaxWYnP/eleJNOd2U0SJs0XRn3GaeWKMJlg21TBtn7oFX URhofosvFEMA3Md3K45Xzy3IIx2wnOCxxf9NnBQqUaJzGpu1DbUtqToDgaHoFOMGnH+8 wBQ7Fheajo609HorYOT2+B/y2j9TnzJdickxGrnDJG6VkI2caQboRuq3feDYhsIHYdP4 XADg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=fD8lb8MgTZ+lHtYLdUWYTsQgZwLBL7TRD/P7pYSLe00=; b=uC2HBpvdKMcJaezeZAjQdGD0VOGkVrPX6k1gTtQBTNh+99qk1itA1KkRf3g1x7mrD1 ppeBK7u+P0gEtO5H86xtJqYNFKiwMK68pyjAOfn6c4FNbrRwGikGr/7gF1IrpDBCwvmG KAR4Tn+6BW8aTjq0S6pejVlUUaNb9danuoXhxbA3zILegjaaNVZMo0w/Xs1ZQ46L3/xT KhGRC8mPoPzpnlkwRq9IHv50nowgLfTZ4PhXiUQ1he8FOPgL/TtBlbWpfwTMyM4g/wQM ridh5qKNhSIRGTn+WF4PHXvN82FfperpGSiwmwnoua80cdX5yjz/4NRJJmR0STqMoB14 fGlA== X-Gm-Message-State: AElRT7FpjmnMNxgDHGCB9NppTmntolxnC/gl7BmDK0HBXyuPPsu8IOH9 GYuFqqBbtA1UrsEcDEbL5GauRbwm+RRFYvqQqyp5sw== X-Google-Smtp-Source: AG47ELtH/P4CotK3TaY92vAGmPFGLXu5zLlTXxUvSqAh8h8z0ptgJZ6jWkGVxm74vtd3lPZ3K+mrMObGoSQ2UeIgSnQ= X-Received: by 10.80.136.85 with SMTP id c21mr2808227edc.259.1520991304462; Tue, 13 Mar 2018 18:35:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.140.35 with HTTP; Tue, 13 Mar 2018 18:35:04 -0700 (PDT) X-Originating-IP: [67.82.37.227] In-Reply-To: <201803140125.w2E1Ps8j085810@pdx.rh.CN85.dnsmgr.net> References: <201803140125.w2E1Ps8j085810@pdx.rh.CN85.dnsmgr.net> From: Mark Saad Date: Tue, 13 Mar 2018 21:35:04 -0400 Message-ID: Subject: Re: GSoC Idea: per-process filesystem namespaces for FreeBSD To: "Rodney W. Grimes" Cc: Warner Losh , Kristoffer Eriksson , "freebsd-hackers@freebsd.org" , Theron Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 01:35:06 -0000 On Tue, Mar 13, 2018 at 9:25 PM, Rodney W. Grimes wrote: >> > On Mar 13, 2018, at 7:16 PM, Warner Losh wrote: >> > >> > >> > >> >> On Tue, Mar 13, 2018 at 4:31 PM, Mark Saad w= rote: >> >> >> >>> On Mar 13, 2018, at 5:43 PM, Warner Losh wrote: >> >>> >> >>>> On Tue, Mar 13, 2018 at 1:55 PM, Kristoffer Eriksson = wrote: >> >>>> >> >>>> >> >>>>> On 13 Mar 2018 12:53:18, Theron wrote: >> >>>>> For those unfamiliar with Plan9, here is a rough explanation of th= e >> >>>>> namespace feature: unlike in Unix, where all processes share the s= ame >> >>>>> virtual filesystem, each process instead has its own view of the >> >>>>> filesystem according to what has been mounted ... >> >>>> >> >>>> What if I mount a new /etc with a passwd file where root has no >> >>>> password, and then run "su"? >> >>>> >> >>>> (How does Plan9 handle that?) >> >>>> >> >>> >> >>> Plan9 handles that by having a daemon that does user authentication.= It's >> >>> actually more complicated than that, but the machine owner has contr= ol over >> >>> who can do what. For this to work in FreeBSD, either we'd need to di= sallow >> >>> the 'file' type for passwd, or we'd have to do something sensible wi= th >> >>> setuid programs. Well, maybe not 'or' but 'and' since the security o= f >> >>> setuid programs depends on the security of the filesystem.... Plan 9 >> >>> doesn't have these complications, so it can offer a user malleable >> >>> filesystem without security risk. >> >>> >> >>> Warner >> >> >> >> A kind of related task; FreeBSD could benefit from : Fixing and imp= roving unionfs / nullfs. There are some weird issues with the current union= fs and while it works in many cases there are some edge cases where the com= ments are something like ? FreeBSD needs a proper stacking vfs ...? the e= xamples I can think of ; imagine you have a jail , chroot or even a Pxe boo= ted system where you want a a read only null mount from the hosts /bin to t= he targets /bin . Now expand that to most of the base system and the mount = tmpfs?s for /tep /var/log etc. most of that works but try to unmount it in= the wrong order or thrash a unionfs with lots of writes ,on top of a tmpfs= and things break . >> >> So to be clear the project would be to better document the various us= es of unionfs and nullfs that work , for the ones that do not diving into t= he stacking vfs and seeing if it could be implemented and if it would help = . >> >> >> >> Alternatively making FreeBSD multiboot compliant would rock . This wo= uld allow FreeBSD to natively boot from ipxe or syslinux derivates; thus al= lowing you to boot a working FreeBSD install via a kernel and mfsroot image= off a web server . >> > >> > There appears to already be a multiboot.c in the bootloader. I've been= told by others in the past it just works... >> > >> > Warner >> >> I am going down the rabbit hole to see how it works . > > If you have any questions I am happy to share my working tooling. > I think you are both missing my point. I can boot FreeBSD with ipxe loading mfsbsd style setups like this :freebsd initrd ${base-root}/freebsd/mfsroot.gz chain ${base-root}/other/memdisk harddisk raw I want to be able to boot and run it like I would Linux or ESXi with the ability to directly load an kernel and a mfsroot/initrd and pass kernel loader arguments :centos674 set centos674_args edd=3Doff ramdisk_size=3D50000 nomodeset ks=3D${centos-root}/CentOS6.7_x64/ks/supermicro-4drives.ks ksdevice=3D${net0/mac} verbose ip=3Ddhcp root-path=3D${centos-root}/CentOS6.7_x64/OS/ net.ifnames=3D0 biosdevname=3D= 0 nousb echo ${centos674_args} kernel ${base-root}/centos/CentOS6.7_x64/isolinux/vmlinuz ${centos674_args} initrd ${base-root}/centos/CentOS6.7_x64/isolinux/initrd.img > ... > > isc-dhcp from ports, > base system tftp setup via inetd > some bits of syslinix 6.03 > proper set of iPXE.exe binaries built with iSCSI, http and nfs support, > you wont need iSCSI, I use that for other things like Windblows. > I boot direct from iPXE to nfs loaded kernel, only thing tftp is used > for is getting a modern version of iPXE onto the booting system. > > iPXE loads a menu.ipxe to allow OS selection. > menu.ipxe loads /boot/pxeboot via NFS > YOU SHALL HAVE ISSUES HERE most pxeboot images are broken > pxeboot loads kernel via NFS > kernel runs, end up in /etc/rc.diskless that does the rest of the magic. > > > -- > Rod Grimes rgrimes@freebs= d.org --=20 mark saad | nonesuch@longcount.org From owner-freebsd-hackers@freebsd.org Wed Mar 14 03:33:39 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 02CA7F4B55D for ; Wed, 14 Mar 2018 03:33:39 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 835AC86828 for ; Wed, 14 Mar 2018 03:33:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22b.google.com with SMTP id d21so2637070ioc.5 for ; Tue, 13 Mar 2018 20:33:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=D89aR3bhuucToua4/lmglmVZMgyoOR/Kz54243ILgfU=; b=miY1UeaPkMgzmU0WTc1mG4+NyzGKaM/aO0tYC3G9+bTj/CZIXRUguP9PzVBHNWlqzV SRiEOMycBqxtBW7R3BTT0pKbSpAWu8OQKA77y+aj0e5sPGxHFJLMfIJkVxY7w3ypPz/D e2gL4i7X8+pcrm79N+EkNOnVWXivaHsL4rvQHq1Ev5nhNqId2lrgDx7tZKHInBOLhSJo GwOv8oOXV7Tanm789ItEpCog2ED6/UcI4dpDKO+xJFbxKf4THcyCgKVtpCHhnfXOdiO5 rHykLumR16NbWNi+gpYSlZIGLqPibBj5H5qYT9KdDTaXgRCnqhyL0aYC2BE8AzDnBaP5 gfZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=D89aR3bhuucToua4/lmglmVZMgyoOR/Kz54243ILgfU=; b=LxIP0PICxXj7q/r46CawfPVn9h/tXOXiGn1qsJkSOd8GByWgdmXWiT+JsHsFNmqpZu 3CfOsW8sNP2ZVZ+NL3C2vsILPbtGgym8Is47+Y0fS7s05bgZi4hs77l/4x6Djx0cIrDh 5vB89g1GcSACVd7fBnlxL4LetYEpok3EEWhVIixMLJGIf8ukIuaNu5FaJWkqIu5ltig5 19sFkMoSXhDfADLcHwhUziS7+N2hzZBE79v10r0lCfAwJTYlXlLKeVlYj7dvqkOGFfUo mFkOljKYoNLmeN/tx6/ExPDXt/HFPvhuQUWZcxFb0NljrNae341kedr2sCu20SnufNiG Yh0g== X-Gm-Message-State: AElRT7FpJd0LqkVIZeMonKX60NpcphPgttpCDOeVHBbSuU0T4chWs5tH PKs4ieBia0qwpyty3xXZSoFJfA3H8SaJDf3dOGKMrA== X-Google-Smtp-Source: AG47ELsaSmvWeGqVyVP+z8NQ68/z5oi9a5bhecQGInw1lrmtrwSG56aYb4ItBQ1b4iVysGd0dJj/3uzCJvtjyB4SvRs= X-Received: by 10.107.187.129 with SMTP id l123mr3077686iof.39.1520998417713; Tue, 13 Mar 2018 20:33:37 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.203.196 with HTTP; Tue, 13 Mar 2018 20:33:36 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:18a2:a4f7:170:8dd9] In-Reply-To: References: <201803140125.w2E1Ps8j085810@pdx.rh.CN85.dnsmgr.net> From: Warner Losh Date: Tue, 13 Mar 2018 21:33:36 -0600 X-Google-Sender-Auth: SmrkznN5QMKFHFiZvQXflz8z_zA Message-ID: Subject: Re: GSoC Idea: per-process filesystem namespaces for FreeBSD To: Mark Saad Cc: "Rodney W. Grimes" , Kristoffer Eriksson , "freebsd-hackers@freebsd.org" , Theron Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 03:33:39 -0000 On Tue, Mar 13, 2018 at 7:35 PM, Mark Saad wrote: > On Tue, Mar 13, 2018 at 9:25 PM, Rodney W. Grimes > wrote: > >> > On Mar 13, 2018, at 7:16 PM, Warner Losh wrote: > >> > > >> > > >> > > >> >> On Tue, Mar 13, 2018 at 4:31 PM, Mark Saad > wrote: > >> >> > >> >>> On Mar 13, 2018, at 5:43 PM, Warner Losh wrote: > >> >>> > >> >>>> On Tue, Mar 13, 2018 at 1:55 PM, Kristoffer Eriksson > wrote: > >> >>>> > >> >>>> > >> >>>>> On 13 Mar 2018 12:53:18, Theron wrote: > >> >>>>> For those unfamiliar with Plan9, here is a rough explanation of > the > >> >>>>> namespace feature: unlike in Unix, where all processes share the > same > >> >>>>> virtual filesystem, each process instead has its own view of the > >> >>>>> filesystem according to what has been mounted ... > >> >>>> > >> >>>> What if I mount a new /etc with a passwd file where root has no > >> >>>> password, and then run "su"? > >> >>>> > >> >>>> (How does Plan9 handle that?) > >> >>>> > >> >>> > >> >>> Plan9 handles that by having a daemon that does user > authentication. It's > >> >>> actually more complicated than that, but the machine owner has > control over > >> >>> who can do what. For this to work in FreeBSD, either we'd need to > disallow > >> >>> the 'file' type for passwd, or we'd have to do something sensible > with > >> >>> setuid programs. Well, maybe not 'or' but 'and' since the security > of > >> >>> setuid programs depends on the security of the filesystem.... Plan 9 > >> >>> doesn't have these complications, so it can offer a user malleable > >> >>> filesystem without security risk. > >> >>> > >> >>> Warner > >> >> > >> >> A kind of related task; FreeBSD could benefit from : Fixing and > improving unionfs / nullfs. There are some weird issues with the current > unionfs and while it works in many cases there are some edge cases where > the comments are something like ? FreeBSD needs a proper stacking vfs ...? > the examples I can think of ; imagine you have a jail , chroot or even a > Pxe booted system where you want a a read only null mount from the hosts > /bin to the targets /bin . Now expand that to most of the base system and > the mount tmpfs?s for /tep /var/log etc. most of that works but try to > unmount it in the wrong order or thrash a unionfs with lots of writes ,on > top of a tmpfs and things break . > >> >> So to be clear the project would be to better document the various > uses of unionfs and nullfs that work , for the ones that do not diving into > the stacking vfs and seeing if it could be implemented and if it would help > . > >> >> > >> >> Alternatively making FreeBSD multiboot compliant would rock . This > would allow FreeBSD to natively boot from ipxe or syslinux derivates; thus > allowing you to boot a working FreeBSD install via a kernel and mfsroot > image off a web server . > >> > > >> > There appears to already be a multiboot.c in the bootloader. I've > been told by others in the past it just works... > >> > > >> > Warner > >> > >> I am going down the rabbit hole to see how it works . > > > > If you have any questions I am happy to share my working tooling. > > > > I think you are both missing my point. I can boot FreeBSD with ipxe > loading mfsbsd style setups like this > > :freebsd > initrd ${base-root}/freebsd/mfsroot.gz > chain ${base-root}/other/memdisk harddisk raw > > I want to be able to boot and run it like I would Linux or ESXi with > the ability to directly load an kernel and a mfsroot/initrd and pass > kernel loader arguments > > :centos674 > set centos674_args edd=off ramdisk_size=50000 nomodeset > ks=${centos-root}/CentOS6.7_x64/ks/supermicro-4drives.ks > ksdevice=${net0/mac} verbose ip=dhcp > root-path=${centos-root}/CentOS6.7_x64/OS/ net.ifnames=0 biosdevname=0 > nousb > echo ${centos674_args} > kernel ${base-root}/centos/CentOS6.7_x64/isolinux/vmlinuz > ${centos674_args} > initrd ${base-root}/centos/CentOS6.7_x64/isolinux/initrd.img FreeBSD takes all the arguments that DHCP supplies as loader / kernel env variables (and if that's not working, I'll fix it). This is a recent feature and might not be widely documented. Warner > > ... > > > > isc-dhcp from ports, > > base system tftp setup via inetd > > some bits of syslinix 6.03 > > proper set of iPXE.exe binaries built with iSCSI, http and nfs support, > > you wont need iSCSI, I use that for other things like Windblows. > > I boot direct from iPXE to nfs loaded kernel, only thing tftp is used > > for is getting a modern version of iPXE onto the booting system. > > > > iPXE loads a menu.ipxe to allow OS selection. > > menu.ipxe loads /boot/pxeboot via NFS > > YOU SHALL HAVE ISSUES HERE most pxeboot images are broken > > pxeboot loads kernel via NFS > > kernel runs, end up in /etc/rc.diskless that does the rest of the magic. > > > > > > -- > > Rod Grimes > rgrimes@freebsd.org > > > > -- > mark saad | nonesuch@longcount.org > From owner-freebsd-hackers@freebsd.org Wed Mar 14 03:53:24 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 65D39F4D017 for ; Wed, 14 Mar 2018 03:53:24 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BE8C0680F3 for ; Wed, 14 Mar 2018 03:53:23 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w2E3rIq4086320; Tue, 13 Mar 2018 20:53:18 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w2E3rHN1086319; Tue, 13 Mar 2018 20:53:17 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201803140353.w2E3rHN1086319@pdx.rh.CN85.dnsmgr.net> Subject: Re: GSoC Idea: per-process filesystem namespaces for FreeBSD In-Reply-To: To: Mark Saad Date: Tue, 13 Mar 2018 20:53:17 -0700 (PDT) CC: Warner Losh , Kristoffer Eriksson , "freebsd-hackers@freebsd.org" , Theron X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 03:53:24 -0000 > On Tue, Mar 13, 2018 at 9:25 PM, Rodney W. Grimes > wrote: > >> > On Mar 13, 2018, at 7:16 PM, Warner Losh wrote: > >> > > >> > > >> > > >> >> On Tue, Mar 13, 2018 at 4:31 PM, Mark Saad wrote: > >> >> > >> >>> On Mar 13, 2018, at 5:43 PM, Warner Losh wrote: > >> >>> > >> >>>> On Tue, Mar 13, 2018 at 1:55 PM, Kristoffer Eriksson wrote: > >> >>>> > >> >>>> > >> >>>>> On 13 Mar 2018 12:53:18, Theron wrote: > >> >>>>> For those unfamiliar with Plan9, here is a rough explanation of the > >> >>>>> namespace feature: unlike in Unix, where all processes share the same > >> >>>>> virtual filesystem, each process instead has its own view of the > >> >>>>> filesystem according to what has been mounted ... > >> >>>> > >> >>>> What if I mount a new /etc with a passwd file where root has no > >> >>>> password, and then run "su"? > >> >>>> > >> >>>> (How does Plan9 handle that?) > >> >>>> > >> >>> > >> >>> Plan9 handles that by having a daemon that does user authentication. It's > >> >>> actually more complicated than that, but the machine owner has control over > >> >>> who can do what. For this to work in FreeBSD, either we'd need to disallow > >> >>> the 'file' type for passwd, or we'd have to do something sensible with > >> >>> setuid programs. Well, maybe not 'or' but 'and' since the security of > >> >>> setuid programs depends on the security of the filesystem.... Plan 9 > >> >>> doesn't have these complications, so it can offer a user malleable > >> >>> filesystem without security risk. > >> >>> > >> >>> Warner > >> >> > >> >> A kind of related task; FreeBSD could benefit from : Fixing and improving unionfs / nullfs. There are some weird issues with the current unionfs and while it works in many cases there are some edge cases where the comments are something like ? FreeBSD needs a proper stacking vfs ...? the examples I can think of ; imagine you have a jail , chroot or even a Pxe booted system where you want a a read only null mount from the hosts /bin to the targets /bin . Now expand that to most of the base system and the mount tmpfs?s for /tep /var/log etc. most of that works but try to unmount it in the wrong order or thrash a unionfs with lots of writes ,on top of a tmpfs and things break . > >> >> So to be clear the project would be to better document the various uses of unionfs and nullfs that work , for the ones that do not diving into the stacking vfs and seeing if it could be implemented and if it would help . > >> >> > >> >> Alternatively making FreeBSD multiboot compliant would rock . This would allow FreeBSD to natively boot from ipxe or syslinux derivates; thus allowing you to boot a working FreeBSD install via a kernel and mfsroot image off a web server . > >> > > >> > There appears to already be a multiboot.c in the bootloader. I've been told by others in the past it just works... > >> > > >> > Warner > >> > >> I am going down the rabbit hole to see how it works . > > > > If you have any questions I am happy to share my working tooling. > > > > I think you are both missing my point. I can boot FreeBSD with ipxe > loading mfsbsd style setups like this > > :freebsd > initrd ${base-root}/freebsd/mfsroot.gz > chain ${base-root}/other/memdisk harddisk raw Nope, not what I am doing. > I want to be able to boot and run it like I would Linux or ESXi with > the ability to directly load an kernel and a mfsroot/initrd and pass > kernel loader arguments > > :centos674 > set centos674_args edd=off ramdisk_size=50000 nomodeset > ks=${centos-root}/CentOS6.7_x64/ks/supermicro-4drives.ks > ksdevice=${net0/mac} verbose ip=dhcp > root-path=${centos-root}/CentOS6.7_x64/OS/ net.ifnames=0 biosdevname=0 > nousb > echo ${centos674_args} > kernel ${base-root}/centos/CentOS6.7_x64/isolinux/vmlinuz ${centos674_args} > initrd ${base-root}/centos/CentOS6.7_x64/isolinux/initrd.img :freebsd6411 set root-path 192.168.48.38:/B/FreeBSD/11.0/amd64 iseq ${platform} efi && chain nfs://192.168.48.38/B/FreeBSD/11.0/amd64/boot/loader.efi || chain nfs://192.168.48.38/B/FreeBSD/11.0/amd64/boot/pxeboot boot || goto failed goto start I agree it would be nice to get the "variable=value" stuff working. I do know the above does infact pass that root-path to the kernel, and without that mountroot fails, so some of this is working -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Wed Mar 14 04:42:29 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C23ACF5133E for ; Wed, 14 Mar 2018 04:42:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 76ADF6A5F5 for ; Wed, 14 Mar 2018 04:42:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x236.google.com with SMTP id d13-v6so2911668itf.0 for ; Tue, 13 Mar 2018 21:42:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=hhBH1kK7bqc2h1/HS++Z+zsV7CP6vAUum7ZQHzt3hyY=; b=YWuxC54Oxx/O/syRLd05ec9pzoek7D+VR8Uu/oG96K92kazmqvsDWkoGyMES4HPHpI V9myk+zSPA0HNI3n4hJmDdjh8eD6Bq+mNw6JN1DhzJIwJ8Pr5NjmKbFIBjEYpnH8atMu Vc0qkRS/DdtdVBPLAWs7V6eFpziGvYNOrUrl2au0ieLLTQ67X8jGJIqOaBDQe7u/uFOO L37RrneDC1bH38JkijKqax316dIDUtTwgp+JGDyVI+eJaZRPTcMUcQY9lno8SGRfXu6T YLcA9Dkm86HiO+SWp9F7kdyAGvCeYhE7rNgJuETOfufTjF5B6CxMOvaYi9KoQMFTtUXk V3eQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=hhBH1kK7bqc2h1/HS++Z+zsV7CP6vAUum7ZQHzt3hyY=; b=sRW/gRJa8oINHGb5Chhyp2bhMdw0y70UXSrpS82a38W0ZdHg6MJEk9sGOf+Momnp4W 9EvhbknRnyDwVr8aqyZ9e+PCeFqEX5mzMu+vUzVK6XA9Hjw6bUH3/+0GX1yhnwrMl/qL gNaamSszDUCgFh8NfhIsZMLP3wI9JjKt1xbqnHQIaN8dHE7mGH+Nws6iIqE8SonCIDQv nQhJdHu1xx0PtYhPL8A/mDKTQOijPL9wx8r2HlcHHmvMx9+ofMMVq/g3bvq/X2a1erlo XM0fT2xQDIiRBcKBSADVb6pMBxB3ywS77LGClCY0eTYm+1QdCNQbS7ePtL6YfJTnzIdz RnFA== X-Gm-Message-State: AElRT7HcuB85zj/p5Dk96GWNFnOLEsyLWRvm0RE4B/gx1mPhdf65Z9TN 0xVWpTd8gtADIL9YhQZW/Z8N8bWqqLk/P22gl/jgjA== X-Google-Smtp-Source: AG47ELv9XI5gZTvrfJatSHH84d2bXvTfzpqC4OHyaT5wnLiebLp+Yub25iGjPz05hpWsQp2KCPfeqhe7OHbVN2G2kf8= X-Received: by 10.36.148.204 with SMTP id j195mr523044ite.1.1521002547633; Tue, 13 Mar 2018 21:42:27 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.203.196 with HTTP; Tue, 13 Mar 2018 21:42:26 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:18a2:a4f7:170:8dd9] In-Reply-To: <201803140353.w2E3rHN1086319@pdx.rh.CN85.dnsmgr.net> References: <201803140353.w2E3rHN1086319@pdx.rh.CN85.dnsmgr.net> From: Warner Losh Date: Tue, 13 Mar 2018 22:42:26 -0600 X-Google-Sender-Auth: lmywJe67OJFh-RSC2iksixVx48s Message-ID: Subject: Re: GSoC Idea: per-process filesystem namespaces for FreeBSD To: "Rodney W. Grimes" Cc: Mark Saad , Kristoffer Eriksson , "freebsd-hackers@freebsd.org" , Theron Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 04:42:29 -0000 On Tue, Mar 13, 2018 at 9:53 PM, Rodney W. Grimes < freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: > > On Tue, Mar 13, 2018 at 9:25 PM, Rodney W. Grimes > > wrote: > > >> > On Mar 13, 2018, at 7:16 PM, Warner Losh wrote: > > >> > > > >> > > > >> > > > >> >> On Tue, Mar 13, 2018 at 4:31 PM, Mark Saad > wrote: > > >> >> > > >> >>> On Mar 13, 2018, at 5:43 PM, Warner Losh wrote: > > >> >>> > > >> >>>> On Tue, Mar 13, 2018 at 1:55 PM, Kristoffer Eriksson < > ske@pkmab.se> wrote: > > >> >>>> > > >> >>>> > > >> >>>>> On 13 Mar 2018 12:53:18, Theron > wrote: > > >> >>>>> For those unfamiliar with Plan9, here is a rough explanation of > the > > >> >>>>> namespace feature: unlike in Unix, where all processes share > the same > > >> >>>>> virtual filesystem, each process instead has its own view of the > > >> >>>>> filesystem according to what has been mounted ... > > >> >>>> > > >> >>>> What if I mount a new /etc with a passwd file where root has no > > >> >>>> password, and then run "su"? > > >> >>>> > > >> >>>> (How does Plan9 handle that?) > > >> >>>> > > >> >>> > > >> >>> Plan9 handles that by having a daemon that does user > authentication. It's > > >> >>> actually more complicated than that, but the machine owner has > control over > > >> >>> who can do what. For this to work in FreeBSD, either we'd need to > disallow > > >> >>> the 'file' type for passwd, or we'd have to do something sensible > with > > >> >>> setuid programs. Well, maybe not 'or' but 'and' since the > security of > > >> >>> setuid programs depends on the security of the filesystem.... > Plan 9 > > >> >>> doesn't have these complications, so it can offer a user malleable > > >> >>> filesystem without security risk. > > >> >>> > > >> >>> Warner > > >> >> > > >> >> A kind of related task; FreeBSD could benefit from : Fixing and > improving unionfs / nullfs. There are some weird issues with the current > unionfs and while it works in many cases there are some edge cases where > the comments are something like ? FreeBSD needs a proper stacking vfs ...? > the examples I can think of ; imagine you have a jail , chroot or even a > Pxe booted system where you want a a read only null mount from the hosts > /bin to the targets /bin . Now expand that to most of the base system and > the mount tmpfs?s for /tep /var/log etc. most of that works but try to > unmount it in the wrong order or thrash a unionfs with lots of writes ,on > top of a tmpfs and things break . > > >> >> So to be clear the project would be to better document the various > uses of unionfs and nullfs that work , for the ones that do not diving into > the stacking vfs and seeing if it could be implemented and if it would help > . > > >> >> > > >> >> Alternatively making FreeBSD multiboot compliant would rock . This > would allow FreeBSD to natively boot from ipxe or syslinux derivates; thus > allowing you to boot a working FreeBSD install via a kernel and mfsroot > image off a web server . > > >> > > > >> > There appears to already be a multiboot.c in the bootloader. I've > been told by others in the past it just works... > > >> > > > >> > Warner > > >> > > >> I am going down the rabbit hole to see how it works . > > > > > > If you have any questions I am happy to share my working tooling. > > > > > > > I think you are both missing my point. I can boot FreeBSD with ipxe > > loading mfsbsd style setups like this > > > > :freebsd > > initrd ${base-root}/freebsd/mfsroot.gz > > chain ${base-root}/other/memdisk harddisk raw > > Nope, not what I am doing. > > > I want to be able to boot and run it like I would Linux or ESXi with > > the ability to directly load an kernel and a mfsroot/initrd and pass > > kernel loader arguments > > > > :centos674 > > set centos674_args edd=off ramdisk_size=50000 nomodeset > > ks=${centos-root}/CentOS6.7_x64/ks/supermicro-4drives.ks > > ksdevice=${net0/mac} verbose ip=dhcp > > root-path=${centos-root}/CentOS6.7_x64/OS/ net.ifnames=0 biosdevname=0 > > nousb > > echo ${centos674_args} > > kernel ${base-root}/centos/CentOS6.7_x64/isolinux/vmlinuz > ${centos674_args} > > initrd ${base-root}/centos/CentOS6.7_x64/isolinux/initrd.img > > :freebsd6411 > set root-path 192.168.48.38:/B/FreeBSD/11.0/amd64 > iseq ${platform} efi && chain nfs://192.168.48.38/B/FreeBSD/ > 11.0/amd64/boot/loader.efi || chain nfs://192.168.48.38/B/FreeBSD/ > 11.0/amd64/boot/pxeboot > boot || goto failed > goto start > > I agree it would be nice to get the "variable=value" stuff working. > I do know the above does infact pass that root-path to the kernel, > and without that mountroot fails, so some of this is working > right, loader.efi and/or pxebooot is what sets the root path (and other variables). What others are asking for is some kind way to do just load the kernel + a bundle of variables with some kind of 'mini /boot/loader' (in our terms) that can turn the bundle into the metadata the kernel needs to do it's job. We have an extra layer of with loader.efi/pxeboot and linux doesn't... Warner From owner-freebsd-hackers@freebsd.org Wed Mar 14 05:44:33 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 11CD7F577E7 for ; Wed, 14 Mar 2018 05:44:33 +0000 (UTC) (envelope-from andre@fbsd.e4m.org) Received: from mail.g66.org (mail.g66.org [85.10.206.112]) by mx1.freebsd.org (Postfix) with ESMTP id 906DC6DBB5 for ; Wed, 14 Mar 2018 05:44:32 +0000 (UTC) (envelope-from andre@fbsd.e4m.org) Received: from x4e35ed3c.dyn.telefonica.de (x4e35ed3c.dyn.telefonica.de [78.53.237.60]) (authenticated bits=128) by mail.g66.org (8.15.2/8.15.2) with ESMTPA id w2E5iU9e041827; Wed, 14 Mar 2018 06:44:30 +0100 (CET) (envelope-from andre@fbsd.e4m.org) Received: from submit.client ([127.0.0.1]) by gate.local (8.15.2/8.15.2) with ESMTP id w2E5iTE5097073; Wed, 14 Mar 2018 06:44:30 +0100 (CET) (envelope-from andre@fbsd.e4m.org) Received: (from user@localhost) by gate.local (8.15.2/8.15.2/Submit) id w2E5iTg4097072; Wed, 14 Mar 2018 06:44:29 +0100 (CET) (envelope-from andre@fbsd.e4m.org) Date: Wed, 14 Mar 2018 06:44:29 +0100 From: Andre Albsmeier To: Luiz Otavio O Souza Cc: Konstantin Belousov , Andre Albsmeier , freebsd-hackers@freebsd.org Subject: Re: UARTs not working on a Supermicro A2SAV / Linux works ;-( Message-ID: <20180314054429.GA96802@gate> References: <20180313171432.GA11972@voyager> <20180313181046.GP76926@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) X-Virus-Scanned: clamav-milter 0.99.4 at colo X-Virus-Status: Clean X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 05:44:33 -0000 On Tue, 13-Mar-2018 at 16:31:07 -0300, Luiz Otavio O Souza wrote: > On 13 March 2018 at 15:10, Konstantin Belousov wrote: > > On Tue, Mar 13, 2018 at 06:14:32PM +0100, Andre Albsmeier wrote: > >> The UARTs on the brand new Supermicro A2SAV mainboard > >> (https://www.supermicro.com/products/motherboard/Atom/A2SAV.cfm) > >> are detected on 11.1-STABLE as > >> > >> uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > >> uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 > >> > >> which is consistent with the BIOS settings. > >> > >> Everything seems to work when it comes to setting of parameters and even > >> the DTR and RTS lines change state when opening cuau0 or cuau1, e.g. with > >> minicom. > >> > >> But sending or receiving characters fails -- to be exact, no single > >> character will be received and only the very first one will be sent to > >> the remote device. > >> > >> We remember this behaviour from the good old times when we had to jumper > >> base port addresses and IRQs on ISA cards: If we got the IRQ wrong the > >> same effect happened: The first char could be sent because the TX register > >> was empty but the IRQ telling the kernel that it can send the next char > >> never arrived. > >> > >> When using debug.uart_force_poll=1 in loader.conf it works (at least if > >> we type in characters slowly, of course). > >> > >> So it really seems to have to do with interrupts again but I have no > >> idea where to look. > >> > >> The A2SAV manual talks about the Super I/O being a Nuvoton NCT5523D. Can > >> it be that we miss some support for this? But if the devices really behave > >> like standard 16550s we shouldn't need any specific support at all, I think. > >> > >> I disabled the corresponding ACPI functions by using > >> > >> debug.acpi.avoid="\_SB_.PCI0.SBRG.UAR1 \_SB_.PCI0.SBRG.UAR2" > >> > >> and the devices were detected properly as > >> > >> uart0: <16550 or compatible> at port 0x3f8 irq 4 flags 0x10 on isa0 > >> uart1: <16550 or compatible> at port 0x2f8 irq 3 on isa0 > >> > >> but this didn't help (same behaviour). > >> > >> The really bad news are: Using Linux (Ubuntu 16.04) it works. Devices are > >> detected here as: > >> ... > >> [ 0.261209] pnp 00:01: [dma 0 disabled] > >> [ 0.261295] pnp 00:01: Plug and Play ACPI device, IDs PNP0501 (active) > >> [ 0.261774] pnp 00:02: [dma 0 disabled] > >> [ 0.261868] pnp 00:02: Plug and Play ACPI device, IDs PNP0501 (active) > >> ... > >> [ 1.479082] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled > >> [ 1.499962] 00:01: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A > >> [ 1.520943] 00:02: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A > >> > >> and we can send and receive characters without problems. > >> > >> So it really seems FreeBSD does something wrong on the A2SAV board when > >> it comes to interrupts of the serial ports. > >> > >> Any ideas how to start? > > > > Bay Trail and later Atoms UARTS are not standard UARTs controllers, AFAIR > > the registers are memory mapped, to start with. They also support DMA, as > > you can see from the linux dmesg. Perhaps there are some incompatibilities > > with the new implementation. > > The system has both, UARTs and HSUARTs, the later will not work. AFAIK the HSUARTs are not used on the A2SAV. The manual talks about using a Nuvoton NCT5523D as IO chip. > > Some recent BIOS have an option to route the system console to the first UART. Yes, I know this feature from some Atom 38xx BIOSes but on the A2SAV there is none. > > > > > Can you show the vmstat -i output ? Are there any other non-MSI > > interrupts used on the machine, do they work ? > > For a minor chance, try to set hw.lapic_eoi_suppression to 0 at the > > loader prompt. > > There was an IOAPIC programming issue affecting these machines, it was > fixed by r327314. > > Please Andre, can you check if this system boots fine with -head ? Much better: I copied /sys/x86/x86/io_apic.c from -current to my 11.1-STABLE sources (there were no other differences apart from the ones of r327314), built a new kernel and now it seems to work! So this seems to be a MFC candidate and I am happy that I was not wrong with my interrupt theory. -Andre From owner-freebsd-hackers@freebsd.org Wed Mar 14 05:51:17 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4DBC3F57BDB for ; Wed, 14 Mar 2018 05:51:17 +0000 (UTC) (envelope-from andre@fbsd.e4m.org) Received: from mail.g66.org (mail.g66.org [85.10.206.112]) by mx1.freebsd.org (Postfix) with ESMTP id 9F91B6E036 for ; Wed, 14 Mar 2018 05:51:16 +0000 (UTC) (envelope-from andre@fbsd.e4m.org) Received: from x4e35ed3c.dyn.telefonica.de (x4e35ed3c.dyn.telefonica.de [78.53.237.60]) (authenticated bits=128) by mail.g66.org (8.15.2/8.15.2) with ESMTPA id w2E5pFgV041872; Wed, 14 Mar 2018 06:51:15 +0100 (CET) (envelope-from andre@fbsd.e4m.org) Received: from submit.client ([127.0.0.1]) by gate.local (8.15.2/8.15.2) with ESMTP id w2E5pFAE097278; Wed, 14 Mar 2018 06:51:15 +0100 (CET) (envelope-from andre@fbsd.e4m.org) Received: (from user@localhost) by gate.local (8.15.2/8.15.2/Submit) id w2E5pFmn097277; Wed, 14 Mar 2018 06:51:15 +0100 (CET) (envelope-from andre@fbsd.e4m.org) Date: Wed, 14 Mar 2018 06:51:15 +0100 From: Andre Albsmeier To: Konstantin Belousov Cc: Andre Albsmeier , freebsd-hackers@freebsd.org Subject: Re: UARTs not working on a Supermicro A2SAV / Linux works ;-( Message-ID: <20180314055115.GB96802@gate> References: <20180313171432.GA11972@voyager> <20180313181046.GP76926@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180313181046.GP76926@kib.kiev.ua> User-Agent: Mutt/1.7.2 (2016-11-26) X-Virus-Scanned: clamav-milter 0.99.4 at colo X-Virus-Status: Clean X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 05:51:17 -0000 On Tue, 13-Mar-2018 at 20:10:46 +0200, Konstantin Belousov wrote: > On Tue, Mar 13, 2018 at 06:14:32PM +0100, Andre Albsmeier wrote: > > The UARTs on the brand new Supermicro A2SAV mainboard > > (https://www.supermicro.com/products/motherboard/Atom/A2SAV.cfm) > > are detected on 11.1-STABLE as > > > > uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > > uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 > > > > which is consistent with the BIOS settings. > > > > Everything seems to work when it comes to setting of parameters and even > > the DTR and RTS lines change state when opening cuau0 or cuau1, e.g. with > > minicom. > > > > But sending or receiving characters fails -- to be exact, no single > > character will be received and only the very first one will be sent to > > the remote device. > > > > We remember this behaviour from the good old times when we had to jumper > > base port addresses and IRQs on ISA cards: If we got the IRQ wrong the > > same effect happened: The first char could be sent because the TX register > > was empty but the IRQ telling the kernel that it can send the next char > > never arrived. > > > > When using debug.uart_force_poll=1 in loader.conf it works (at least if > > we type in characters slowly, of course). > > > > So it really seems to have to do with interrupts again but I have no > > idea where to look. > > > > The A2SAV manual talks about the Super I/O being a Nuvoton NCT5523D. Can > > it be that we miss some support for this? But if the devices really behave > > like standard 16550s we shouldn't need any specific support at all, I think. > > > > I disabled the corresponding ACPI functions by using > > > > debug.acpi.avoid="\_SB_.PCI0.SBRG.UAR1 \_SB_.PCI0.SBRG.UAR2" > > > > and the devices were detected properly as > > > > uart0: <16550 or compatible> at port 0x3f8 irq 4 flags 0x10 on isa0 > > uart1: <16550 or compatible> at port 0x2f8 irq 3 on isa0 > > > > but this didn't help (same behaviour). > > > > The really bad news are: Using Linux (Ubuntu 16.04) it works. Devices are > > detected here as: > > ... > > [ 0.261209] pnp 00:01: [dma 0 disabled] > > [ 0.261295] pnp 00:01: Plug and Play ACPI device, IDs PNP0501 (active) > > [ 0.261774] pnp 00:02: [dma 0 disabled] > > [ 0.261868] pnp 00:02: Plug and Play ACPI device, IDs PNP0501 (active) > > ... > > [ 1.479082] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled > > [ 1.499962] 00:01: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A > > [ 1.520943] 00:02: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A > > > > and we can send and receive characters without problems. > > > > So it really seems FreeBSD does something wrong on the A2SAV board when > > it comes to interrupts of the serial ports. > > > > Any ideas how to start? > > Bay Trail and later Atoms UARTS are not standard UARTs controllers, AFAIR > the registers are memory mapped, to start with. They also support DMA, as > you can see from the linux dmesg. Perhaps there are some incompatibilities > with the new implementation. > > Can you show the vmstat -i output ? Are there any other non-MSI > interrupts used on the machine, do they work ? Just to answer this question: I haven't seen any. When using io_apic.c from -head (inspired by Luiz' suggestion to try -head because of r327314) I have: NOHOST:~>vmstat -i interrupt total rate irq3: uart1 18 0 cpu0:timer 1516 16 irq264: ahci0 1300 14 irq265: igb0:que 0 1965 21 irq266: igb0:que 1 414 4 irq267: igb0:que 2 539 6 irq268: igb0:que 3 251 3 irq269: igb0:link 2 0 irq275: ahci1 6 0 irq276: xhci0 367 4 cpu2:timer 950 10 cpu3:timer 866 9 cpu1:timer 1021 11 Total 9215 97 Before the output has been similar but lacking the irq3 line. > For a minor chance, try to set hw.lapic_eoi_suppression to 0 at the > loader prompt. Not needed, since it seems to work with io_apic.c from -head. But if you want me to try it for whatever reasons I can do it, of course. -Andre From owner-freebsd-hackers@freebsd.org Wed Mar 14 06:12:27 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9E04DF5885F for ; Wed, 14 Mar 2018 06:12:27 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:300:2185:a:dead:bad:faff]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E26566EB76 for ; Wed, 14 Mar 2018 06:12:26 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [104.207.135.49]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id w2E6COKR072705; Wed, 14 Mar 2018 06:12:25 GMT (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id w2E6COcR072704; Wed, 14 Mar 2018 06:12:24 GMT (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <201803140612.w2E6COcR072704@donotpassgo.dyslexicfish.net> Date: Wed, 14 Mar 2018 06:12:24 +0000 Organization: Dyslexic Fish To: theron.tarigo@gmail.com, freebsd-hackers@freebsd.org Subject: Re: GSoC Idea: per-process filesystem namespaces for FreeBSD References: In-Reply-To: User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [104.207.135.49]); Wed, 14 Mar 2018 06:12:25 +0000 (GMT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 06:12:27 -0000 Linux has already implemented something similar - with mount namespaces. http://man7.org/linux/man-pages/man7/mount_namespaces.7.html cheers! From owner-freebsd-hackers@freebsd.org Wed Mar 14 08:23:07 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 44870F2F0F3 for ; Wed, 14 Mar 2018 08:23:07 +0000 (UTC) (envelope-from mber2015@gmail.com) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ADD83746AD for ; Wed, 14 Mar 2018 08:23:06 +0000 (UTC) (envelope-from mber2015@gmail.com) Received: by mail-wr0-x230.google.com with SMTP id o1so3749811wro.10 for ; Wed, 14 Mar 2018 01:23:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=UzubT5Q2OHkp/kxl6km9InzyuSRxnFE3XdaP8XY1yyg=; b=D1tv4gtq/TaYgumvGxc0xyWQr0bV2xYrqEvRQakAZG/D613LYNNgeUIUMLCmz2rzzP k96DzL+scaZylMN/F/dqnwZogNWvA1becg/JYuZIPJP6dnOXlLza0GogI6iP0Li4wHcp rinU6eNVaJrL5FKfV694uUXal0zGWLituolPI6jhI5mzeX8VbZzvtQlKbH2NKm5J2ZRX oWvQ9V2Z3Z12VNLStecAWNJzYhb25z8O59a+dn+tsrniw2TTT4dNS1Ftthm4e/lUsoiD 4W5gLGTPlJQtTkgZRiSACIKFbuAHSgjofJVm1tndgTvgfbgkw/5WXHkQHeQNAZHTs4TR aCqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=UzubT5Q2OHkp/kxl6km9InzyuSRxnFE3XdaP8XY1yyg=; b=ueEPyavhD9G/mxPEex5R/CXvjj3JkNwf8g+WAhr0Dm/QxUBbVWbmiHEk2zNnBpMCmi 3wC5Rb0R+7uBh7xALNgZe1OLGMf5lJZOWQ6LQl9NiWHKOLSCBdcUEAMFrZqFzf0dw7qW cZ9+rv+8lA2cUscwZ4KxFtoZM6GKJPO1v8jUMknkAOGsxzKKxCjy4wW/OrpEVtNooQCC MZ7ftznE+8LN+fzKDl297OKYRalLz+cpTUb3BB+kbN7oCCfYV2xUolEW+jO/q33xiXON /ZLjUPL5r27FIjXuSGh9pRD2l3iFCX7xKkGJ4d/IKNkoSoGdnhgIFwGF02rkSOApVm3t 3jUA== X-Gm-Message-State: AElRT7Fwy1Ibmup+Bps5QHcKnd8RUPokCoTscAkMFyo3VPWZPmMICXqp mDrk4Uv92qxgDTSvnLRH3thZbw== X-Google-Smtp-Source: AG47ELsFoRL1LGF1OkAtjq0qHftUhR/fT5MY2ACdXWovNrBXvH2zjhFMw2b69bfDBTj7fqY8SJjRCw== X-Received: by 10.223.134.210 with SMTP id 18mr904491wry.232.1521015785106; Wed, 14 Mar 2018 01:23:05 -0700 (PDT) Received: from mb.tns.cz ([2001:470:6f:ca1:ae2b:6eff:fe6a:b6cf]) by smtp.gmail.com with ESMTPSA id g25sm1002534wmc.0.2018.03.14.01.23.03 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Mar 2018 01:23:04 -0700 (PDT) Sender: Martin Beran Subject: Re: GSoC Idea: per-process filesystem namespaces for FreeBSD To: freebsd-hackers@freebsd.org References: <201803132055.aa28780@berenice.pkmab.se> <20180313222344.2929E156E812@mail.bitblocks.com> <1f8fc07b-9bf0-f9b2-ae7e-7cb0919722d0@gmail.com> From: Martin Beran Message-ID: <25bb803d-5d60-c8e0-f9a1-aaf0f5aa4d4e@mber.cz> Date: Wed, 14 Mar 2018 09:23:02 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <1f8fc07b-9bf0-f9b2-ae7e-7cb0919722d0@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 08:23:07 -0000 On 03/14/18 01:16, Theron Tarigo wrote: > On 03/13/18 18:23, Bakul Shah wrote: >> Plan9 has no root (superuser) or setuid.  You can mangle >> anything in your namespace but it affects only *your* own >> process and its future descendents. >> > Although it would limit the usefulness of it, ignoring any and all file > suid bits for any process with a non-empty mount table should in theory > prevent exploitation of setuid.  Allowing safe setuid in combination > with ("trusted" ?) namespaces would be something to add support for much > later if someone decides it would be useful. > > By focusing on a narrowed case, that of allowing an unprivileged process > to alter its view into the vfs in a way which is only preserved through > execve() in specific safe circumstances, I hoped to avoid the > insurmountable complexity of implementing the feature in the full > generality that is available on Plan9. Another possibility would be to decouple security related decisions from the file system namespaces. What I mean is that, for example, /etc/master.passwd should not be trusted by su because of the file name. Instead, it could bear some attribute assigned by root denoting it as a valid passwd database. If su accessed a file without this attribute, the kernel would withdraw its capability to switch user identity, regardless of its setuid. If any processes without a relevant privilege modifies /etc/master.passwd, the kernel would automatically remove the "passwd db" attribute from the file. Naturally, a password file installed by an ordinary user via altering the file system namespace would not have the attribute. Such security (in fact, integrity-defining) attributes would be attached to the files and possibly other system objects themselves, not to their names. I understand that implementing such security mechanism would require much much larger effort than the above mentioned ad-hoc solution. But I think it has the potential to solve many other security-related problems. -- Martin Beran From owner-freebsd-hackers@freebsd.org Wed Mar 14 08:32:36 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C19F4F300EF for ; Wed, 14 Mar 2018 08:32:36 +0000 (UTC) (envelope-from yhayakawa3720@gmail.com) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 38D647502E for ; Wed, 14 Mar 2018 08:32:36 +0000 (UTC) (envelope-from yhayakawa3720@gmail.com) Received: by mail-wm0-x22f.google.com with SMTP id t3so2310224wmc.2 for ; Wed, 14 Mar 2018 01:32:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=xMxeLfAWO4MhtwFZVoBYl19509ionJkAtf939IXrdI8=; b=nfdMEE1qBJTL3ZxIz/wa+GxRi27QVb0KSYdTSHye/g6w8Pn3aKWiFDxgTb7fIfDHX/ 3RCc8cU2Pcv/qr9iQsADJWJ6AAt1A4rZ3pbOBVbxPx2T8wwo34l6V84N1anMH15CMDLj Xxb1ox/SAjTBTLS0RfH6kMp5wUzYopkEjRy3grsSW4JYCQar0ZA4O6EbyI9cS7TeKJ35 oCTFlUiHK4Ei/OH5pU3MOvn1Uz7eaOXt0mZ3P9FF9NKhUG6fuSYvevZvsDGDiaIndwNl e/jmPxKeE793mJyO7fe6lp80T00VgYQvYWC7nkCLFFgpJG8BNqEG1nBDwjMWrsOaVQ+l JYJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=xMxeLfAWO4MhtwFZVoBYl19509ionJkAtf939IXrdI8=; b=ZX+gBx51yJc2I8UsFoVar/7QTjC7bxNGLJyl1WU5FHgCgv2lkvh67Y1A1/nvlmBAPm KEl0bPfAX/sh+Tpzf51UwmX8jbPaxxV3sAKnR1fC7ldrCuY5QBt0QDa4rPjiNNmt4zZy 36X9ncS182NHuvO9VCdV6Vd8B1csRMy+siTe9FmmPqH3BEstlHGsgRAGSL8we/st6GFh icp054mPa7b2xJDmG8u66bwPLyhMIEA24pGamsOeaUZu0Hmo2eQImJwQYBg6PRhIKjkd cWPDc8S3nqn09ksMf8CRBhIUxOzoo/GnZjevwZSmFzwL4NKv+ynRP4IsqMSWgu6M0DPn d6JQ== X-Gm-Message-State: AElRT7ES9Ecb5/JwpBm9zmlYl8HN4BKvG4rbFeam4gQ8t3JC0zrgsQUv BUi6BW+ALDwIeV9Zlot4GZ9PkA== X-Google-Smtp-Source: AG47ELt3HC+N21atFb2SmfneFHkB3B8RmVmOa3KhZOGtCj4IK+c5ZJswljLjWaUUur6hUDwxNLX6SQ== X-Received: by 10.28.207.73 with SMTP id f70mr937035wmg.92.1521016355121; Wed, 14 Mar 2018 01:32:35 -0700 (PDT) Received: from [10.1.2.212] (mito.neclab.eu. [195.37.70.39]) by smtp.gmail.com with ESMTPSA id x107sm2349245wrb.97.2018.03.14.01.32.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Mar 2018 01:32:34 -0700 (PDT) Subject: Re: Possible GSoC idea, eBPF for FreeBSD To: Ryan Stone Cc: freebsd-hackers@freebsd.org References: From: Yutaro Hayakawa Message-ID: Date: Wed, 14 Mar 2018 09:32:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 08:32:36 -0000 Hello Ryan, Thank you very much! Probably I will come up with some unclear point when I make my proposal. Let me reach out to you at that time. Best regards, Yutaro On 03/13/2018 05:03 PM, Ryan Stone wrote: > I would be very interested in serving as a mentor for this project. I > am registered at the GSOC as Ryan Stone at rysto32@gmail.com. Please > feel free to contact me off-list if you have any questions about your > project proposal. > > Thanks, > Ryan From owner-freebsd-hackers@freebsd.org Wed Mar 14 13:01:49 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CB622F505B9 for ; Wed, 14 Mar 2018 13:01:49 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4859E7F7B4 for ; Wed, 14 Mar 2018 13:01:49 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: by mail-wm0-x235.google.com with SMTP id u10so3694888wmu.4 for ; Wed, 14 Mar 2018 06:01:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=longcount-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=eNBqb3/lgKHzG2YMTqwP5z0RDpzGMd9ks9I0QgvKGsE=; b=vfq+kG77gqZgl8637gcnu9AoaJtKdY+sE5RtedZbT1KnFGx6pTOyx5EJnQVk+ULwRJ dS/UvNC3iA34PSwJN5pkrJU0KxMFpcDxPUJ5jaTebnhvJaDKOWiTqTlY/fDbYRXZslMg ux/6k3Nz2xus4PbOed+Jk31NNl6FNFjxjc5WcGLvetF1Mcwz++w9XhXKXmBr4mfDd6ga kv5eRznfFvd8pED+NyxX+fFTD+wSujDXfBHkEg8ztITVGKZQd87RT+1T/4IMwylwoPMA 6mqZxy+CYS1dJtHJgy3mj/zOtcO5MJCJ0tIYyQBAcSZVLyH60viyYETvzNS3Or8BdnQ8 HH0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=eNBqb3/lgKHzG2YMTqwP5z0RDpzGMd9ks9I0QgvKGsE=; b=tM3uWGxLmkyiK1RnllLULbNzvBRVUr/JtDbgsrgVdfHiRbS57rVukmL8oIBdemjmno EOePahzk9NPhng6sq8KHz3RLW9P7sFKdSx9zL5UkL6oTSkJxW//1k/WbD6NMWmQoM4Pz pZMs2BhrhxCCARN8dfEh1wXV2+rhhHaBBh7CvKBoDJFIs/JIHeF2MOVIcEyjUHVfco2K 7OjwMiHdzIvJG9Lu+GUibg/2rUOVSq1XZZ/U7Ojn0TY6jBtg8qBPgbZUUgdYTnbtIp5S IUADhhwDWO++MyodaNi6q/sBQ+zwBQo7kGq7gZxZ+Xo5uBTuSvBUvgMv9L5oX0QkA93e Xeeg== X-Gm-Message-State: AElRT7E7C8id2U43avBXUdTjk5GB63fyyAlCRDtm90+JlFNdU7S/WP2Z IW/1R8eCyJAqWULIV2QcfXrK58FHT6WfSyLpc+NzrQ== X-Google-Smtp-Source: AG47ELuN/dKPxagj8lsQCBwZOMqx6wKw2jMB4qyMBeuphXhasbvdo8mMV56DRkgrqH2EEyGFMkMoxjrfq3d4Ha2MUqg= X-Received: by 10.80.140.200 with SMTP id r8mr2559449edr.310.1521032508032; Wed, 14 Mar 2018 06:01:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.140.35 with HTTP; Wed, 14 Mar 2018 06:01:47 -0700 (PDT) X-Originating-IP: [174.202.11.120] In-Reply-To: <1f8fc07b-9bf0-f9b2-ae7e-7cb0919722d0@gmail.com> References: <201803132055.aa28780@berenice.pkmab.se> <20180313222344.2929E156E812@mail.bitblocks.com> <1f8fc07b-9bf0-f9b2-ae7e-7cb0919722d0@gmail.com> From: Mark Saad Date: Wed, 14 Mar 2018 09:01:47 -0400 Message-ID: Subject: Re: GSoC Idea: per-process filesystem namespaces for FreeBSD To: Theron Tarigo Cc: Bakul Shah , Warner Losh , Kristoffer Eriksson , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 13:01:50 -0000 On Tue, Mar 13, 2018 at 8:16 PM, Theron Tarigo wr= ote: > On 03/13/18 18:23, Bakul Shah wrote: >> >> Plan9 has no root (superuser) or setuid. You can mangle >> anything in your namespace but it affects only *your* own >> process and its future descendants. >> >> The following paper on Plan9 authentication in Linux may be >> worth reading: >> >> https://static.googleusercontent.com/media/research.google.com/en//pubs/= archive/34433.pdf >> >> While I have wanted per-process namespace in BSD for a long >> time, I agree with Konstantin this is a non-trivial project. >> Even if the design was fully fleshed out, implementing it >> would likely take longer than 12 weeks. > > Although it would limit the usefulness of it, ignoring any and all file s= uid > bits for any process with a non-empty mount table should in theory preven= t > exploitation of setuid. Allowing safe setuid in combination with ("trust= ed" > ?) namespaces would be something to add support for much later if someone > decides it would be useful. > > By focusing on a narrowed case, that of allowing an unprivileged process = to > alter its view into the vfs in a way which is only preserved through > execve() in specific safe circumstances, I hoped to avoid the insurmounta= ble > complexity of implementing the feature in the full generality that is > available on Plan9. > > On 03/13/18 18:31, Mark Saad wrote: >> >> A kind of related task; FreeBSD could benefit from : Fixing and >> improving unionfs / nullfs. There are some weird issues with the current >> unionfs and while it works in many cases there are some edge cases where= the >> comments are something like =E2=80=9C FreeBSD needs a proper stacking vf= s ...=E2=80=9D the >> examples I can think of ; imagine you have a jail , chroot or even a Pxe >> booted system where you want a a read only null mount from the hosts /bi= n to >> the targets /bin . Now expand that to most of the base system and the mo= unt >> tmpfs=E2=80=99s for /tep /var/log etc. most of that works but try to un= mount it in >> the wrong order or thrash a unionfs with lots of writes ,on top of a tmp= fs >> and things break . >> So to be clear the project would be to better document the various uses = of >> unionfs and nullfs that work , for the ones that do not diving into the >> stacking vfs and seeing if it could be implemented and if it would help = . >> > Using nullfs / unionfs in combination with chroot could be made functiona= lly > equivalent to per-process namespace, but would have the very same securit= y > problems as already discussed (as any chroot have) so configuring such > environments would be available only to superuser. I was not thinking of you cobbling nullfs and unionfs into a FreeBSD version of plan9's bind I was thinking more about how nullfs , and unionfs are influenced by plan9 and how they could benefit from someone with some plan9 experience. Not to say that any of the prior work was done poorly or incorrectly because of a lack of plan9 experience . But that your enthusiasm would be better focused on a part of base that could use some polish and maybe some rethinking . > > So it appears that the most significant obstacle to achieving at least an > approximation of the behavior of user-controlled per-process namespace is > managing setuid safely. One idea here could be to use capsicum to enforce this requirement but that would be a new approach from what I understand. https://www.freebsd.org/cgi/man.cgi?capsicum(4) > > One thought I had is to do all of this purely in user-space by creating a= n > extension to libc which allows appropriately linked programs to find file= s > according to some set of prefixes defining the namespace, defined through= an > environment variable, but have all system interactions function in the > normal ways. Would this be sufficiently general to be of any use? If th= is > approach does pose any security threats, it indicates a hole is already > present in the system! (MacOS once had a problem with allowing privileged > programs to be launched under a modified library path...) > > On 03/13/18 20:00, Mark Saad wrote: >> >> However I still think the unionfs / nullfs work I mentioned before would >> be a good project related to the plan9 idea in some ways . > > Is there a way I could go about fixing up unionfs while also making > significant progress towards eventual support for true per-process > namespace? > > Theron I think there is a lot of opportunity here to pick apart a subsystem that shares some commonality with plan9 . I think that improving unionfs / nullfs to have less edge cases would be a great project. You would need to set a smaller goal for managing the expiation of time you will have for GSoC . Some small tasks that could be a starting point for working on this project. There are a few projects that depend on creating a unionfs of a tmpfs and a readonly disk image. One example would be booting off a CD-Rom and using a unionfs to make a ram disk give the read-only medium the appearance of have a read / write. Second example is the Docker / Container setup where a read-only loop-mounted disk image is unioned to a ram disk in a similar way to the cdrom was before . Third option is where a Jail is created from a template directory that would mount versions of a binary or directory into the jailed environment for various reason. --=20 mark saad | nonesuch@longcount.org From owner-freebsd-hackers@freebsd.org Wed Mar 14 13:11:57 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A8208F5106F for ; Wed, 14 Mar 2018 13:11:57 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 247D37FF2F for ; Wed, 14 Mar 2018 13:11:57 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: by mail-wm0-x233.google.com with SMTP id i194so3934925wmg.1 for ; Wed, 14 Mar 2018 06:11:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=longcount-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AuMtdrS6TTQTSWfbfixNUSNI/kJ+wAIZlEfwRunvBeo=; b=evmgA0uqqA9EQUa6svME8oUVjYQGz6Ubny/3THXRlyrVlqeIqkEDb5Q3QuED0Aedob jwWeJTITu21p9TBcQNqhSfiw+uH8zSbo+P5Ovst/CLXbWIbQx/l6dxe6X7BdgExNsyRq fuo7iNLc9dZH9CgPFOiEIW4PHZ6phcjJBCyAMNtubm0FuCHTg1W1RVI2to6s5JSbBDgP LYNGncKEHDsuFYIys5zF/1v8lRPRnYd9xxf3oLYA3vTvWA59bQ7FhNH8umU9irSrM9Mk KLQEyYa8HU/pwKgIzEv3D5PRiuCFWho2BG/zgNgZUpDZSZl/g1KuhLdcuL2h/DzvKH+h mH6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AuMtdrS6TTQTSWfbfixNUSNI/kJ+wAIZlEfwRunvBeo=; b=sRIekeU7JGlSwEYKTTBe3xMZiVz9/OxD/bljl5lU0PiF5wxW4T4AsoTj7wy9AqiZoP wBrt8Zue4jzfQUZ7vN/5LM46TqBfReSFbadGFmkrYPZ50tVZAnHJJXRTKhxkdxd50TuE Q7VMRJlee4WlKl8Q3Skr/8/K4Yl7A6t0TJHQzEi7q/OROydVQMBTFJxMVwN/KuYSnhJm lKE8Dfzh5CGenBnqOqvo3bFPeXaQdFDbHMdobqNeU1eQ6w7+a5H7seb/o2KkkJv+Pi+W 7pobzNgqtBuzeOXVLIckwCan4nJukkL8XEounkKspEuSSfmqEV2og3Qygb7SnfagKKtd yxbA== X-Gm-Message-State: AElRT7FXjKP7Z6OLwlh6so17CrA6euZ1lyTQDstZJfyOn4pCrd9gL34A e4s+lY0y6Wy4EWENEB0EZWd4t25ogtc2hFolmDfDtA== X-Google-Smtp-Source: AG47ELvcjiCbYkSty2zxMGvRnIpGViHw1gY+XZUIRzg6k9NpO0yBW0NhVT8NwZhfiZdIhivEnichewrb/SNThnTvSvc= X-Received: by 10.80.136.85 with SMTP id c21mr4882325edc.259.1521033115988; Wed, 14 Mar 2018 06:11:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.140.35 with HTTP; Wed, 14 Mar 2018 06:11:55 -0700 (PDT) X-Originating-IP: [174.202.11.120] In-Reply-To: References: <201803140353.w2E3rHN1086319@pdx.rh.CN85.dnsmgr.net> From: Mark Saad Date: Wed, 14 Mar 2018 09:11:55 -0400 Message-ID: Subject: Re: GSoC Idea: per-process filesystem namespaces for FreeBSD To: Warner Losh Cc: "Rodney W. Grimes" , Kristoffer Eriksson , "freebsd-hackers@freebsd.org" , Theron Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 13:11:57 -0000 Warner I'll see if I can get this working , later today. From what I remember with NetBSD changes back in 2004 they wanted to get Xen working booting from Grub with out chain loading. If memory serves me that's what led them into getting the kernel to boot via the multiboot protocol . Solaris/Illumos can also do the same . I use iPXE at work to network boot an Illumos derivative with a kernel, boot archive and some variables to govern console bits and what not. In a weird sort of coincidence Illumos imported FreeBSD's loader to try and dump Grub so maybe everything is there already ? Lets see what I can get working today. >> > >> > Warner >> > >> >> > >> I am going down the rabbit hole to see how it works . >> > > >> > > If you have any questions I am happy to share my working tooling. >> > > >> > >> > I think you are both missing my point. I can boot FreeBSD with ipxe >> > loading mfsbsd style setups like this >> > >> > :freebsd >> > initrd ${base-root}/freebsd/mfsroot.gz >> > chain ${base-root}/other/memdisk harddisk raw >> >> Nope, not what I am doing. >> >> > I want to be able to boot and run it like I would Linux or ESXi with >> > the ability to directly load an kernel and a mfsroot/initrd and pass >> > kernel loader arguments >> > >> > :centos674 >> > set centos674_args edd=off ramdisk_size=50000 nomodeset >> > ks=${centos-root}/CentOS6.7_x64/ks/supermicro-4drives.ks >> > ksdevice=${net0/mac} verbose ip=dhcp >> > root-path=${centos-root}/CentOS6.7_x64/OS/ net.ifnames=0 biosdevname=0 >> > nousb >> > echo ${centos674_args} >> > kernel ${base-root}/centos/CentOS6.7_x64/isolinux/vmlinuz >> > ${centos674_args} >> > initrd ${base-root}/centos/CentOS6.7_x64/isolinux/initrd.img >> >> :freebsd6411 >> set root-path 192.168.48.38:/B/FreeBSD/11.0/amd64 >> iseq ${platform} efi && chain >> nfs://192.168.48.38/B/FreeBSD/11.0/amd64/boot/loader.efi || chain >> nfs://192.168.48.38/B/FreeBSD/11.0/amd64/boot/pxeboot >> boot || goto failed >> goto start >> >> I agree it would be nice to get the "variable=value" stuff working. >> I do know the above does infact pass that root-path to the kernel, >> and without that mountroot fails, so some of this is working > > > right, loader.efi and/or pxebooot is what sets the root path (and other > variables). What others are asking for is some kind way to do just load the > kernel + a bundle of variables with some kind of 'mini /boot/loader' (in our > terms) that can turn the bundle into the metadata the kernel needs to do > it's job. We have an extra layer of with loader.efi/pxeboot and linux > doesn't... > > Warner -- mark saad | nonesuch@longcount.org From owner-freebsd-hackers@freebsd.org Wed Mar 14 16:34:37 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B261EF5CE55 for ; Wed, 14 Mar 2018 16:34:37 +0000 (UTC) (envelope-from mail@osfux.nl) Received: from vm1982.vellance.net (vm1982.vellance.net [79.99.187.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 43AEF69890 for ; Wed, 14 Mar 2018 16:34:36 +0000 (UTC) (envelope-from mail@osfux.nl) Received: from vm1982.vellance.net (localhost [127.0.0.1]) by vm1982.vellance.net (Postfix) with ESMTP id DFDD920217; Wed, 14 Mar 2018 17:26:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=osfux.nl; s=default; t=1521044781; bh=/2eXw8iPvPgj/MVv93/VPCX/1+KOJfxOp9VWPEarYM4=; h=To:From:Subject:Date; b=BwSU9TV1YIR420iteRU1wIc5Dfn1IBZBGlKU8vH8ZR5QcGTLfQQIT9MCaEmqs4+9n S1vnIDXoU6fi+4Xa9WkxLYN45glyvJs46na8BWl5WmisK0g4EOaDgB02LAV4Vj+Wu2 7/VfYFhySyItk2eGzZCF/U1P6Vry9qpELNr7LYfZOLgxBzljDEdNrVM6Bk2cSiaW4O LdSAvN3vYj00fYnN1Mk4KvjvDdUzluZHV5k4lkCYFGfIfut7P1J0/1SrlNxeKhurvO 6CYqeRazMorjrjGzoJi8NpnhmoT7xVjWPRW/SSqEWTbD8/ZjMfQDiWTlPFnpjA4rBN Cmo93mPib81eWVIPrNMmQIhBXLjuUVZUHb6YqOLGnmW/wiukNAhr7cxBsrJ1jlb5xf tcE5bev+H468TyUgjPw3Mqrvy1ZqxDjNdt6TJdtVp47Hy0xWKb5WG/kR2dPBpRf2IV r8Hb4HcU8jmI6x+DItZw1IAcE+FFHmFPe1jH6yn9Sk+D0O0+vGWfBQw5FB+wxJoAdW j6784OdyXmQUgsKqXpoW31CFK1GWnyu4CCI0VlBjoS9LIT6vxdWJOGq2Gn92Q6Yub1 SCFcWkg0TsGXScAbzyeWgVbPpKzztS3ieAR+eIxZRzgHjCGpH8RS2h/4YJ4TKf5aaj qXHtaLbNziJZVG9esLZLGFUc= Received: from vm1982.vellance.net (localhost [127.0.0.1]) by vm1982.vellance.net (Postfix) with ESMTP id 22EDB20209; Wed, 14 Mar 2018 17:26:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=osfux.nl; s=default; t=1521044778; bh=/2eXw8iPvPgj/MVv93/VPCX/1+KOJfxOp9VWPEarYM4=; h=To:From:Subject:Date; b=LQmCxET0b87FLNdkqc27QmmHnaPF0XBRwgY1MPawHJP7Hp02gxt6NETt0p9PhMP1s TOY2/1/YWMVrQf/ge2RAzCLjGC/NJixiPri+Addwlb07F+up5qELIfjxkSVRZ7hshy giZsOMckoSyE2wIZz6TvNh4ClhhzOSxjsunBf20IOJNm/cRqC5J1G2HkoQxnyv4Aqt bctXQCDrURXOaZtbdH4HfUWvWk2Of1q3W9Rk/3BaDP767sY02+FSsKnns1TZHnN89T nu58BLQwFp23sLE4LQ5/oLnHIrshCoM3YPU4+/w0AU1I7a28piH/XgHzqZmw4V5BKY uEySLMVOqdv3sDUkdItCAsnSgxfmIOgsV1Dp7/F5zQy5+wYk9Z6X0ctDPPoFxNxO2k B3JKw9ovPdWh0Y344/7iIbnFpNXGDvYRLDUmw3l6Y5albB7cfqh11/jBn2eoFdYNS5 GLCQXhQipZcbU7YzuB6h9g3prxPG2uLbFwro8Sut1N8eWa3Pz/E5hazuY4JYNx2o1p G+p3OO3g2lGNXBzbJvu8Q5l8YyRIOPZesfmGgGRn+X9EabEmm4AGPsxYQuWcMVq60x Lq8Zdt2SRDOA043CdxM+uISSN9Nk2TuiC3SJrqMrpkPDpZaNw1ECsVc0EZwUqO54n9 3FiwjQ3ZtKADATJvKFbRZuHY= X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on vm1982.vellance.net X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=ham autolearn_force=no version=3.4.1 Received: from rubens-MacBook-Air.local (engineering.quanza.net [91.208.87.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by vm1982.vellance.net (Postfix) with ESMTPSA; Wed, 14 Mar 2018 17:26:11 +0100 (CET) To: Stefan Blachmann , freebsd-hackers@freebsd.org From: Ruben Subject: cpupdate : Unsupported version for Intel CPU? Message-ID: Date: Wed, 14 Mar 2018 17:26:10 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Virus-Scanned: ClamAV using ClamSMTP X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 16:34:37 -0000 Hi Stefan, Is this tool intended to be compatible with all intel CPU's or is it just for a specific subset of Intel CPU's (or subset  perhaps of microcode images)? The reason I'm asking is because I've just given your tool a try and got an "error" message (see below). I have not tried using the traditional tools yet (devcpu). Any feedback appreciated! Kind regards, Ruben [root@fbh4:/usr/home/ruben]# git clone https://github.com/kernschmelze/cpupdate [ snip ] [root@fbh4:/usr/home/ruben]# cd cpupdate/ [root@bh4:/usr/home/ruben/cpupdate]# make echo cpupdate.full: /usr/lib/libc.a  >> .depend Warning: Object directory not changed from original /usr/home/ruben/cpupdate cc -O2 -pipe   -g -MD  -MF.depend.cpupdate.o -MTcpupdate.o -std=gnu99 -fstack-protector-strong    -Qunused-arguments  -c cpupdate.c -o cpupdate.o cc -O2 -pipe   -g -MD  -MF.depend.intel.o -MTintel.o -std=gnu99 -fstack-protector-strong    -Qunused-arguments  -c intel.c -o intel.o cc -O2 -pipe -g -std=gnu99 -fstack-protector-strong -Qunused-arguments  -o cpupdate.full cpupdate.o intel.o objcopy --only-keep-debug cpupdate.full cpupdate.debug objcopy --strip-debug --add-gnu-debuglink=cpupdate.debug  cpupdate.full cpupdate gzip -cn cpupdate.8 > cpupdate.8.gz [root@fbh4:/usr/home/ruben/cpupdate]# [root@fbh4:/usr/home/ruben/cpupdate]# ./cpupdate -i Found CPU(s) from Intel Processor Core: 0 -> CPUID: 206c2  Family: 06  Model: 2C  Stepping: 02  uCodeRev: 00000013 Processor Core: 1 -> CPUID: 206c2  Family: 06  Model: 2C  Stepping: 02  uCodeRev: 00000013 Processor Core: 2 -> CPUID: 206c2  Family: 06  Model: 2C  Stepping: 02  uCodeRev: 00000013 Processor Core: 3 -> CPUID: 206c2  Family: 06  Model: 2C  Stepping: 02  uCodeRev: 00000013 Processor Core: 4 -> CPUID: 206c2  Family: 06  Model: 2C  Stepping: 02  uCodeRev: 00000013 Processor Core: 5 -> CPUID: 206c2  Family: 06  Model: 2C  Stepping: 02  uCodeRev: 00000013 Processor Core: 6 -> CPUID: 206c2  Family: 06  Model: 2C  Stepping: 02  uCodeRev: 00000013 Processor Core: 7 -> CPUID: 206c2  Family: 06  Model: 2C  Stepping: 02  uCodeRev: 00000013 Processor Core: 8 -> CPUID: 206c2  Family: 06  Model: 2C  Stepping: 02  uCodeRev: 00000013 Processor Core: 9 -> CPUID: 206c2  Family: 06  Model: 2C  Stepping: 02  uCodeRev: 00000013 Processor Core: 10 -> CPUID: 206c2  Family: 06  Model: 2C  Stepping: 02  uCodeRev: 00000013 Processor Core: 11 -> CPUID: 206c2  Family: 06  Model: 2C  Stepping: 02  uCodeRev: 00000013 Processor Core: 12 -> CPUID: 206c2  Family: 06  Model: 2C  Stepping: 02  uCodeRev: 00000013 Processor Core: 13 -> CPUID: 206c2  Family: 06  Model: 2C  Stepping: 02  uCodeRev: 00000013 Processor Core: 14 -> CPUID: 206c2  Family: 06  Model: 2C  Stepping: 02  uCodeRev: 00000013 Processor Core: 15 -> CPUID: 206c2  Family: 06  Model: 2C  Stepping: 02  uCodeRev: 00000013 [root@fbh4:/usr/home/ruben/cpupdate]# fetch https://github.com/platomav/CPUMicrocodes/blob/master/Intel/cpu206C2_plat03_ver0000001D_2015-08-04_PRD_F7DC758B.bin fetch: https://github.com/platomav/CPUMicrocodes/blob/master/Intel/cpu206C2_plat03_ver0000001D_2015-08-04_PRD_F7DC758B.bin: size of remote file is not known cpu206C2_plat03_ver0000001D_2015-08-04_PRD_F7D          30 kB  270 kBps 00m00s [root@fbh4:/usr/home/ruben/cpupdate]# ./cpupdate -vv -I -f /usr/home/ruben/cpupdate/cpu206C2_plat03_ver0000001D_2015-08-04_PRD_F7DC758B.bin Unsupported version Error in [first] header [root@fbh4:/usr/home/ruben/cpupdate]# From owner-freebsd-hackers@freebsd.org Wed Mar 14 16:54:57 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2664B62E5 for ; Wed, 14 Mar 2018 16:54:57 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AB3C46AC82 for ; Wed, 14 Mar 2018 16:54:56 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: by mail-ot0-x232.google.com with SMTP id m22-v6so3932245otf.10 for ; Wed, 14 Mar 2018 09:54:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=euBwUfSGBsFmXowRfFpWERNetGwelr6HQeLBZEG17aw=; b=R+XhAk/YBXu1njH4pWqhxfY4dzvtUVkQ6l2Xio/aI/w2nwZftDMo9l7sVJcUz0LwPt 4WAEoQSObKRG/eyrErQ08YLsO9jRwJ3SfyKswMGD+HARuYY4qKKlWT9dV59uc3U6OFrD LCtbQFTshacusPRdkpAy5RhiL8PtSYY8QoCPo06/Lfkxz+/b9GJhQN7wvCXRobcFFHG9 bDn3yOVX2aoyJn622ryajtybGGn8TvPJ5K9c4iVGI8kEuzhRqgBlvmc9UXsJZnBAdmDf vWeMoFsuhE5Wby6Og3Ficxu3levWvx4lT9zTWT3UHXt0pcH4zhSYkfcS5MiZ8yKDz+Uk GFjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=euBwUfSGBsFmXowRfFpWERNetGwelr6HQeLBZEG17aw=; b=SD2FyqCsDZkY8HBTLYu1WY1bH+LAqrP4jKtPtQgJCRWT3ZIRwr91OQHyEBXX5sipv5 aF4hma++4VqpMTdaHxXvh/HnPpfU8GBkDTGy6qVyFo34B6x/y57V1cdGaF6SkUXrm81B zG/rG72NILvwZiqegqxx8Ry50QlaM4FOJ76NoijpfyuFk7OgI8UnPuYZPNMDXl158aCJ jEMgYNl2mh9mBgkzkuDLJCl137tjk0Z57mIaHqcB6o57JF5eqKFHhiuv9yUXNHIESE67 DGMVuMls6UzmckIc++rvcN9tZS9DSzHfyObce03NPcrdIUYxcdnEC7rZvSuMNrC4hbll n4lQ== X-Gm-Message-State: AElRT7Eseaw8EQddZdnJg0ibZ/eDxPpq3d/maP/o0DqAqdp54XdbwIc9 FqdW1aBsBJrHWplNmO+cj8kX0qSXVZ3TddqHLbg= X-Google-Smtp-Source: AG47ELtAHrTYLv2fKPskj8/okgoH/+s3aOV4tzioIz1EvhTDT5oE58zpixKZJx7HGcnEeqcXRg4Qbe/JDRV1bWsuu+w= X-Received: by 10.157.89.158 with SMTP id u30mr3650695oth.294.1521046496066; Wed, 14 Mar 2018 09:54:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.49.99 with HTTP; Wed, 14 Mar 2018 09:54:55 -0700 (PDT) In-Reply-To: References: From: Stefan Blachmann Date: Wed, 14 Mar 2018 17:54:55 +0100 Message-ID: Subject: Re: cpupdate : Unsupported version for Intel CPU? To: Ruben Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 16:54:57 -0000 Hi Ruben, thank you for your feedback! The tool is intended for all Intel cpus. I wonder whether there might be a download error? To verify this here is the SHA256 checksum: % sha256 /home/stefan/Downloads/Intel/Intel/cpu206C2_plat03_ver0000001D_201= 5-08-04_PRD_F7DC758B.bin SHA256 (/home/stefan/Downloads/Intel/Intel/cpu206C2_plat03_ver0000001D_2015= -08-04_PRD_F7DC758B.bin) =3D 8f0f2d80ea3ffa0c4993445a49c42751ebe04dfcea19c25d1951870daac45d9a % What makes me wonder too is the size (30KB) that is shown in your log: % ll /home/stefan/Downloads/Intel/Intel/cpu206C2_plat03_ver0000001D_2015-08= -04_PRD_F7DC758B.bin -rw-r--r-- 1 stefan stefan 9216 Mar 11 18:40 /home/stefan/Downloads/Intel/Intel/cpu206C2_plat03_ver0000001D_2015-08-04_P= RD_F7DC758B.bin Please can you check that size and checksum are correct? If they are, please let me know so that I can investigate what might have happened else. Anyway I did a major rework of the tool and added new functions and documentation in the last days. Will upload that tonight or tomorrow. I'll email when it's on github. Have a nice day! Stefan On 3/14/18, Ruben wrote: > Hi Stefan, > > > Is this tool intended to be compatible with all intel CPU's or is it > just for a specific subset of Intel CPU's (or subset=C2=A0 perhaps of > microcode images)? > > The reason I'm asking is because I've just given your tool a try and got > an "error" message (see below). I have not tried using the traditional > tools yet (devcpu). > > Any feedback appreciated! > > > Kind regards, > > > Ruben > > [root@fbh4:/usr/home/ruben]# git clone > https://github.com/kernschmelze/cpupdate > > [ snip ] > > [root@fbh4:/usr/home/ruben]# cd cpupdate/ > [root@bh4:/usr/home/ruben/cpupdate]# make > echo cpupdate.full: /usr/lib/libc.a=C2=A0 >> .depend > Warning: Object directory not changed from original > /usr/home/ruben/cpupdate > cc -O2 -pipe=C2=A0=C2=A0 -g -MD=C2=A0 -MF.depend.cpupdate.o -MTcpupdate.o= -std=3Dgnu99 > -fstack-protector-strong=C2=A0=C2=A0=C2=A0 -Qunused-arguments=C2=A0 -c cp= update.c -o cpupdate.o > cc -O2 -pipe=C2=A0=C2=A0 -g -MD=C2=A0 -MF.depend.intel.o -MTintel.o -std= =3Dgnu99 > -fstack-protector-strong=C2=A0=C2=A0=C2=A0 -Qunused-arguments=C2=A0 -c in= tel.c -o intel.o > cc -O2 -pipe -g -std=3Dgnu99 -fstack-protector-strong -Qunused-arguments > -o cpupdate.full cpupdate.o intel.o > objcopy --only-keep-debug cpupdate.full cpupdate.debug > objcopy --strip-debug --add-gnu-debuglink=3Dcpupdate.debug=C2=A0 cpupdate= .full > cpupdate > gzip -cn cpupdate.8 > cpupdate.8.gz > [root@fbh4:/usr/home/ruben/cpupdate]# > > [root@fbh4:/usr/home/ruben/cpupdate]# ./cpupdate -i > Found CPU(s) from Intel > Processor Core: 0 > -> CPUID: 206c2=C2=A0 Family: 06=C2=A0 Model: 2C=C2=A0 Stepping: 02=C2=A0= uCodeRev: 00000013 > Processor Core: 1 > -> CPUID: 206c2=C2=A0 Family: 06=C2=A0 Model: 2C=C2=A0 Stepping: 02=C2=A0= uCodeRev: 00000013 > Processor Core: 2 > -> CPUID: 206c2=C2=A0 Family: 06=C2=A0 Model: 2C=C2=A0 Stepping: 02=C2=A0= uCodeRev: 00000013 > Processor Core: 3 > -> CPUID: 206c2=C2=A0 Family: 06=C2=A0 Model: 2C=C2=A0 Stepping: 02=C2=A0= uCodeRev: 00000013 > Processor Core: 4 > -> CPUID: 206c2=C2=A0 Family: 06=C2=A0 Model: 2C=C2=A0 Stepping: 02=C2=A0= uCodeRev: 00000013 > Processor Core: 5 > -> CPUID: 206c2=C2=A0 Family: 06=C2=A0 Model: 2C=C2=A0 Stepping: 02=C2=A0= uCodeRev: 00000013 > Processor Core: 6 > -> CPUID: 206c2=C2=A0 Family: 06=C2=A0 Model: 2C=C2=A0 Stepping: 02=C2=A0= uCodeRev: 00000013 > Processor Core: 7 > -> CPUID: 206c2=C2=A0 Family: 06=C2=A0 Model: 2C=C2=A0 Stepping: 02=C2=A0= uCodeRev: 00000013 > Processor Core: 8 > -> CPUID: 206c2=C2=A0 Family: 06=C2=A0 Model: 2C=C2=A0 Stepping: 02=C2=A0= uCodeRev: 00000013 > Processor Core: 9 > -> CPUID: 206c2=C2=A0 Family: 06=C2=A0 Model: 2C=C2=A0 Stepping: 02=C2=A0= uCodeRev: 00000013 > Processor Core: 10 > -> CPUID: 206c2=C2=A0 Family: 06=C2=A0 Model: 2C=C2=A0 Stepping: 02=C2=A0= uCodeRev: 00000013 > Processor Core: 11 > -> CPUID: 206c2=C2=A0 Family: 06=C2=A0 Model: 2C=C2=A0 Stepping: 02=C2=A0= uCodeRev: 00000013 > Processor Core: 12 > -> CPUID: 206c2=C2=A0 Family: 06=C2=A0 Model: 2C=C2=A0 Stepping: 02=C2=A0= uCodeRev: 00000013 > Processor Core: 13 > -> CPUID: 206c2=C2=A0 Family: 06=C2=A0 Model: 2C=C2=A0 Stepping: 02=C2=A0= uCodeRev: 00000013 > Processor Core: 14 > -> CPUID: 206c2=C2=A0 Family: 06=C2=A0 Model: 2C=C2=A0 Stepping: 02=C2=A0= uCodeRev: 00000013 > Processor Core: 15 > -> CPUID: 206c2=C2=A0 Family: 06=C2=A0 Model: 2C=C2=A0 Stepping: 02=C2=A0= uCodeRev: 00000013 > > [root@fbh4:/usr/home/ruben/cpupdate]# fetch > https://github.com/platomav/CPUMicrocodes/blob/master/Intel/cpu206C2_plat= 03_ver0000001D_2015-08-04_PRD_F7DC758B.bin > fetch: > https://github.com/platomav/CPUMicrocodes/blob/master/Intel/cpu206C2_plat= 03_ver0000001D_2015-08-04_PRD_F7DC758B.bin: > size of remote file is not known > cpu206C2_plat03_ver0000001D_2015-08-04_PRD_F7D=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 30 kB=C2=A0 270 kBps > 00m00s > > [root@fbh4:/usr/home/ruben/cpupdate]# ./cpupdate -vv -I -f > /usr/home/ruben/cpupdate/cpu206C2_plat03_ver0000001D_2015-08-04_PRD_F7DC7= 58B.bin > Unsupported version > Error in [first] header > [root@fbh4:/usr/home/ruben/cpupdate]# > From owner-freebsd-hackers@freebsd.org Wed Mar 14 17:02:02 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6C8836969 for ; Wed, 14 Mar 2018 17:02:02 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E459D6B1E6 for ; Wed, 14 Mar 2018 17:02:00 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id w2EH1mvw017687 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Mar 2018 18:01:49 +0100 (CET) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: mail@osfux.nl Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id w2EH1bSP053520 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 15 Mar 2018 00:01:37 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: cpupdate : Unsupported version for Intel CPU? To: Ruben , Stefan Blachmann , freebsd-hackers@freebsd.org References: From: Eugene Grosbein Message-ID: <5AA9556C.2010002@grosbein.net> Date: Thu, 15 Mar 2018 00:01:32 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS * 2.6 LOCAL_FROM From my domains X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 17:02:02 -0000 14.03.2018 23:26, Ruben wrote: > [root@fbh4:/usr/home/ruben/cpupdate]# fetch > https://github.com/platomav/CPUMicrocodes/blob/master/Intel/cpu206C2_plat03_ver0000001D_2015-08-04_PRD_F7DC758B.bin > fetch: > https://github.com/platomav/CPUMicrocodes/blob/master/Intel/cpu206C2_plat03_ver0000001D_2015-08-04_PRD_F7DC758B.bin: > size of remote file is not known > cpu206C2_plat03_ver0000001D_2015-08-04_PRD_F7D 30 kB 270 kBps This is wrong URL to download raw blob, paste it to your browser and see for yourself. Github responds with web page, not binary file. From owner-freebsd-hackers@freebsd.org Wed Mar 14 17:49:43 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 97AA4F2F8B1 for ; Wed, 14 Mar 2018 17:49:43 +0000 (UTC) (envelope-from theron.tarigo@gmail.com) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2B1426D754 for ; Wed, 14 Mar 2018 17:49:43 +0000 (UTC) (envelope-from theron.tarigo@gmail.com) Received: by mail-qt0-x22c.google.com with SMTP id a23so4389969qtn.0 for ; Wed, 14 Mar 2018 10:49:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=8ktRYPCq5MzoXvFc9DaNFvsyJ9+BdN8BAYQVKyXY+iU=; b=DewzV4CDH/VV4aMVcUs0mZG5UHv9X3Ftc0RVCzL5NRgIHTyKPb9NhxOOOEiWUxttT9 lRvr9hKMrZmSkx4zJPREx0qvpNyjH50YyrW+639AWFY3+Dv79bVckbZpj9/S8U7WGiLF rd8LGrvzVSTqvVvhFo40FwWG1vp6pKF3vv6ryYplUQUP5oRPk0bVeyORP+B4j1XytoQi Za92rFg8e/lb/bfyiqLjl8/DWyki3gX/+sxV//z78/LTJyBZcrz9r7KAR1c9DfSmrUjI GNVCEtzVlc7o8R1tK4Y2pHIl7HXR7fkt416OEYZpgKVZjHM/mWKA0PDBvVdke95F+HH9 N22g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=8ktRYPCq5MzoXvFc9DaNFvsyJ9+BdN8BAYQVKyXY+iU=; b=eee3zbswSw4ExcY4BTNH1gOHMTS2XxMRz6+h54oJat6F/knh92QBIcDrFArnCognf6 Sit+RqJcY+Et5mwTT6e9W1GxCD7bEdroDs67Cf+Hcs96ijSihW1sFrR+xzF5vrFMbhYm 1YByc6oWcmQwjkX05AaGWYZaMkObVpoQ8nHoq3z7dGTgXO+/D1GvV+AOdBvwZUAKzPk1 4C8iyQyutg1Q31ANy7oC2nJyWgv8bSnnOhm3F8zF1eZsz2Zi9PglUP7iB3WUerI6V7Id kvGHIL8p7JZYQPM1My8Q8S1lECXeGCvDRtd/k2+/iT6ECkLbvlGTN4IMS/2AYtipBs4I Kfuw== X-Gm-Message-State: AElRT7GMEBXGbtTUPXToBAZF/MWy7LGEfMDFMSOlYNIxTMHmSeSYpiRn D6UNDfsCxAokPA1mAHcUAJDK+4MVqDQ= X-Google-Smtp-Source: AG47ELs/TPGdb6om1Xn6vI8jpurYM7Lrke4bU+K9JszwevJHs/xpkaxF5ebxisO4guBxrkPrtYeAbw== X-Received: by 10.237.39.38 with SMTP id n35mr8719251qtd.51.1521049782470; Wed, 14 Mar 2018 10:49:42 -0700 (PDT) Received: from [155.41.26.230] (dhcp-wifi-8021x-155-41-26-230.bu.edu. [155.41.26.230]) by smtp.gmail.com with ESMTPSA id u57sm2446202qtc.41.2018.03.14.10.49.41 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Mar 2018 10:49:41 -0700 (PDT) Sender: Theron Tarigo Subject: Re: cpupdate : Unsupported version for Intel CPU? To: freebsd-hackers@freebsd.org References: <5AA9556C.2010002@grosbein.net> From: Theron Tarigo Message-ID: Date: Wed, 14 Mar 2018 13:49:41 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <5AA9556C.2010002@grosbein.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 17:49:43 -0000 On 03/14/18 13:01, Eugene Grosbein wrote: > This is wrong URL to download raw blob, paste it to your browser and see for yourself. > Github responds with web page, not binary file. I had to figure this out recently, working URL is of format https://raw.githubusercontent.com/${user}/${project}/${branch}/${path}, so https://raw.githubusercontent.com/platomav/CPUMicrocodes/master/Intel/cpu206C2_plat03_ver0000001D_2015-08-04_PRD_F7DC758B.bin Ports has some documented mechanism for obtaining a tar snapshot of a github repository, but is there a common way to fetch only individual files? Theron From owner-freebsd-hackers@freebsd.org Wed Mar 14 19:22:34 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2F271F3AA2E for ; Wed, 14 Mar 2018 19:22:34 +0000 (UTC) (envelope-from mail@osfux.nl) Received: from vm1982.vellance.net (vm1982.vellance.net [79.99.187.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A978072B88 for ; Wed, 14 Mar 2018 19:22:33 +0000 (UTC) (envelope-from mail@osfux.nl) Received: from vm1982.vellance.net (localhost [127.0.0.1]) by vm1982.vellance.net (Postfix) with ESMTP id 82AD8202A0 for ; Wed, 14 Mar 2018 20:22:30 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=osfux.nl; s=default; t=1521055351; bh=iz1OIG4yszfVOptD9Vvewe84J05m3hsynhjzuIWr2C8=; h=Subject:To:References:From:Date:In-Reply-To; b=STVHmELAV9zTjTTkskv8nEicdo2frXdAq1ZymDvH0S8wy2nofc3iEl69R+R3134zk k6If3fE5omY1SDlBSZKw3x8JJWT5vUwkiTy+tgNEHOHW4zLFl9zFy6Hxjig4MFvVdR JYNkDha/pGmrAW8UuX0s0arJNq8oEqEwC20PuORdPe5tcA6EHt8gPq+zf3CwuVcfXb JgfhzScc9rreUQWxrKut+k+WzzhCsJ0sR1CDWAb/9oTpkWVNzJZ8fDnTZTltFCPuxA X49qQhiGgSyEyIwHPnH+mRDncM2LAmaELoQJwfevmIdoHGamSGG3IgXaRVS2XbWwXg 2fGlbymu3m8NgwmvgfAct4yh8u39++biSuL6eekG3/b+up5Z3q77y3ndx2ker5QPai 8jeTyFIyULnLzyxm0UpGkckazVElLjm1HNGt0IEQOlQIddsOi/noKOa4cI+gUQZHN8 KdGRSILFjudi7CSI5dMTNKIPX/fFePcAkCbkSpcxHIijUmMdwL44k649r9FTw8Q71Y OqMo6dgpwj4zsveDiqIR5Kr6YZKrdGUJIbxyFtCzxJfqqPff8Bdzsq2i17cqrsSGXd dvRuNrB2uYt+ruSilUpQTbA36JVFghyrywS88wBD7Q8ConvJjvDy9hRde1W4Y4HKyh 5M4gRppJ1T/A+5TP/qo8zCK4= Received: from vm1982.vellance.net (localhost [127.0.0.1]) by vm1982.vellance.net (Postfix) with ESMTP id 23F94201E6 for ; Wed, 14 Mar 2018 20:22:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=osfux.nl; s=default; t=1521055349; bh=iz1OIG4yszfVOptD9Vvewe84J05m3hsynhjzuIWr2C8=; h=Subject:To:References:From:Date:In-Reply-To; b=qQ5lP6IlvGpXS+sE6FyOCZOTT6NreASIekC+OnC8HLqIh0YS5fj6huGJ8G6kozeuq zvlqzBF55akac5dWOmSnp9zfCRWsJbFNoJqlTtnQ0c04d8ZruLGE3cHy2hoJhdr+OR yACMlB6lsBu9Q3cnJHj0kVuXNiuKml7A7W72zi86xO+BZRcyUQ27Y30RxCenzjA2sV s3ATXblINCzrW/ILc9zJf7cNswbJhKKz69FNnzvxUn4pYG+1TvjHrtzfmCSxSG4rLH uuooFxEufN2zj0SVzTGcuK6/sB6PS9HmLMWai88vGSa6KN6r5f0lwtQ4H7QjY7oV7g ZKLiqHlJ8C5GhQQ9ljOrk3JPsdMImtxktZ6A4DwzeYTmPRoBxLZyOL1P/zLkUWRE1m fapreqbNKKmfe8km6LWP/dD0ehVp3y4XVJmPzwjBcKi0JmHu65TeLzEL/KhJ9CM8rA Nfq+jRXDKyzVN4X0fH+plqyptEuujzJpzjYhG1B/h2SP6+VUbaF7UPt/VLKGbinHO9 9XNQL9H4B1xm2mDLbRSEMS9ECdeYP3Wu7rnGvmac3WDmer+MMyzjBzjVRO4rPEMv0U oSvwua9kYkA1mJGfjubrEgmaxrlyp+GwZULp66Aefa/wzU1VR+K0PgoBFgHkvggekB dYa0VdNikecA7WryQrwevI2Y= X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on vm1982.vellance.net X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=ham autolearn_force=no version=3.4.1 Received: from rubens-MacBook-Air.local (ip51ccb320.speed.planet.nl [81.204.179.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by vm1982.vellance.net (Postfix) with ESMTPSA for ; Wed, 14 Mar 2018 20:22:10 +0100 (CET) Subject: Re: cpupdate : Unsupported version for Intel CPU? To: freebsd-hackers@freebsd.org References: <5AA9556C.2010002@grosbein.net> From: Ruben Message-ID: Date: Wed, 14 Mar 2018 20:22:10 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <5AA9556C.2010002@grosbein.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Virus-Scanned: ClamAV using ClamSMTP X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 19:22:34 -0000 Hi, Thank you for pointing that out. Forgot about the "download from github thing". Cheers, Ruben On 14/03/2018 18:01, Eugene Grosbein wrote: > This is wrong URL to download raw blob, paste it to your browser and > see for yourself. > Github responds with web page, not binary file. > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Wed Mar 14 19:25:08 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2156BF3AE11 for ; Wed, 14 Mar 2018 19:25:08 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (ns1.bitblocks.com [173.228.5.8]) by mx1.freebsd.org (Postfix) with ESMTP id 8242C72E40 for ; Wed, 14 Mar 2018 19:25:07 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mob.bitblocks.com (mob.bitblocks.com [192.168.125.11]) by mail.bitblocks.com (Postfix) with ESMTP id 05707156E812; Wed, 14 Mar 2018 12:24:35 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: GSoC Idea: per-process filesystem namespaces for FreeBSD From: Bakul Shah In-Reply-To: <1f8fc07b-9bf0-f9b2-ae7e-7cb0919722d0@gmail.com> Date: Wed, 14 Mar 2018 12:24:35 -0700 Cc: "freebsd-hackers@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <1A5AB0FF-8FAB-4DBE-9547-A30BA3C6A487@bitblocks.com> References: <201803132055.aa28780@berenice.pkmab.se> <20180313222344.2929E156E812@mail.bitblocks.com> <1f8fc07b-9bf0-f9b2-ae7e-7cb0919722d0@gmail.com> To: Theron Tarigo X-Mailer: Apple Mail (2.3445.5.20) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 19:25:08 -0000 On Mar 13, 2018, at 5:16 PM, Theron Tarigo = wrote: >=20 > On 03/13/18 18:23, Bakul Shah wrote: >> Plan9 has no root (superuser) or setuid. You can mangle >> anything in your namespace but it affects only *your* own >> process and its future descendents. >>=20 >> The following paper on Plan9 authentication in Linux may be >> worth reading: >> = https://static.googleusercontent.com/media/research.google.com/en//pubs/ar= chive/34433.pdf >>=20 >> While I have wanted per-process namespace in BSD for a long >> time, I agree with Konstantin this is a non-trivial project. >> Even if the design was fully fleshed out, implementing it >> would likely take longer than 12 weeks. > Although it would limit the usefulness of it, ignoring any and all = file suid bits for any process with a non-empty mount table should in = theory prevent exploitation of setuid. Allowing safe setuid in = combination with ("trusted" ?) namespaces would be something to add = support for much later if someone decides it would be useful. >=20 > By focusing on a narrowed case, that of allowing an unprivileged = process to alter its view into the vfs in a way which is only preserved = through execve() in specific safe circumstances, I hoped to avoid the = insurmountable complexity of implementing the feature in the full = generality that is available on Plan9. IMHO this needs to be designed-in carefully as it touches upon a very central facility of Unix. It doesn't have to be plan9 compatible but it does need to be well integrated and be as orthogonal (widely applicable) as possible. Plan9 design for per-process namespace is well thought out & it should be studied. Ideally increased flexibility provided by per-process namespaces simplifies things. chroot can be reimplemented this way. Any narrowing of goals should be in the context of an overall design. Second, it is likely that many files will be affected and a comprehensive design will force you to look at all these places. Getting the design right will be lot more than just making mount tables per process. Someone mentioned Linux namespaces. The complexity of this feature makes me think it was done the wrong way about. > On 03/13/18 18:31, Mark Saad wrote: >> A kind of related task; FreeBSD could benefit from : Fixing and = improving unionfs / nullfs. There are some weird issues with the current = unionfs and while it works in many cases there are some edge cases where = the comments are something like =E2=80=9C FreeBSD needs a proper = stacking vfs ...=E2=80=9D the examples I can think of ; imagine you = have a jail , chroot or even a Pxe booted system where you want a a read = only null mount from the hosts /bin to the targets /bin . Now expand = that to most of the base system and the mount tmpfs=E2=80=99s for /tep = /var/log etc. most of that works but try to unmount it in the wrong = order or thrash a unionfs with lots of writes ,on top of a tmpfs and = things break . >> So to be clear the project would be to better document the various = uses of unionfs and nullfs that work , for the ones that do not diving = into the stacking vfs and seeing if it could be implemented and if it = would help . >>=20 > Using nullfs / unionfs in combination with chroot could be made = functionally equivalent to per-process namespace, but would have the = very same security problems as already discussed (as any chroot have) so = configuring such environments would be available only to superuser. Note that plan9's bind(2) mechanism is much simpler than unionfs & the latter has never really worked well in BSD. In any case union mounts are global. > So it appears that the most significant obstacle to achieving at least = an approximation of the behavior of user-controlled per-process = namespace is managing setuid safely. A simple initial solution may be to disallow setuid in per-user mounts.= From owner-freebsd-hackers@freebsd.org Wed Mar 14 19:37:03 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1FD3EF3FBB8 for ; Wed, 14 Mar 2018 19:37:03 +0000 (UTC) (envelope-from mail@osfux.nl) Received: from vm1982.vellance.net (vm1982.vellance.net [79.99.187.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A3AAA734E3 for ; Wed, 14 Mar 2018 19:37:02 +0000 (UTC) (envelope-from mail@osfux.nl) Received: from vm1982.vellance.net (localhost [127.0.0.1]) by vm1982.vellance.net (Postfix) with ESMTP id 2FD03202A0; Wed, 14 Mar 2018 20:37:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=osfux.nl; s=default; t=1521056220; bh=8ITRpSiKEpezAvpeAvQ5Y1yM1X3Z6HX1Z9+VJ1WbFE4=; h=Subject:From:To:References:Cc:Date:In-Reply-To; b=IomRGGGqSEA61rEruemrYP8A1Kv0bcJRzOrmvOsZdv8DkIszkMZ8U8rxltd3e3ET+ nQPg/TNTl8VOz/8VTyIbILv+FxA/Kit2XhozS859Mpb3I20ERWC0GRh/ooKVrIS6NA WLomDDZ5iJzQMMkuDCIgqWa33LY8+TApzuj8UQMc6LzI1soMRaOosxm2De77UlAC+R gRHjzlcd2ehpyyM9mn09sCJx3axe3S9+vxW0qBVM/eK+zbNJqXm4qXcvxP+bMV+T5n OBolM2T+BfIEPNaUF+CO3WX+J669eHEVDrxvRzHpNe09Oz4X6Ex/z4hT0JZNXlnlce oOcwOenBwVZ9V+pp1Qt0advryqZY2Aoo5Cc/g0dIEAtz2KsDj3s/IB9t9MOQBWskso aG1LJQdFvUAn0WPm0Q1OtVTGmoC7n3BjA1jnrhJSzRxIpyH5SDgc+mH9y5pSjUp8Od U0JNGFg5BYqUKJmKF9NEnu4MsxamX4rV+Id2cc0jMcn2zjsaLDhMoL138wCX1Y1XQr UiRVBtWgK5ZqzWR8TvHeANkzY5rLs09iQcJyfNiOojVMWDzrs7Kw+AX/GqrEh2r6J6 7Tzupnkz3EDag5ldN52euyUqPVlbmj+CSn/Ze5E821SB/DGLwAx8CIQmp8mR9Zn7u7 /4uh+An+3RVOMmM49FuUZeEU= Received: from vm1982.vellance.net (localhost [127.0.0.1]) by vm1982.vellance.net (Postfix) with ESMTP id 4D28E20170; Wed, 14 Mar 2018 20:36:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=osfux.nl; s=default; t=1521056219; bh=8ITRpSiKEpezAvpeAvQ5Y1yM1X3Z6HX1Z9+VJ1WbFE4=; h=Subject:From:To:References:Cc:Date:In-Reply-To; b=U2IAod159xHbIxrRTmiJEXDDKFXQZpqTHVlRWn7bRL3G7sDiZ3nWQpGuePh4pmSp+ /LV0T/QD8RHUzSoIQ9f/4U8f8cLQ1mWgNsBE07K712Tdt97WwQ3tMa6auiBEiSt/qR HCfB3xFoB1ouWnHmW8nTw6JenrGw7SwzBvlYzr0TleMggIEwmHaJFvnqAs4/7emUp6 Y4/SjfWSY+6Psd7QQEaeOvoB/RYw4fkQLzCGq1nnAIMApteNOlj95bYXwpex4UYhpM E9as0q+s67ytTHHddsEtnJUrnJd27phnUaZYsgZZSgKV+p487dRFMCFVczh8PMxlHT SwBtowTDbaPKh4AJpikI/DRBcdZPcOY/4jTH3MRoB/RXgjvVYjLiTFT8n6NcXOiC02 Sos0J9LIui0jyGN2JhfDB4EJrIptTEfMyHoxLx9q8J7dAUPfhTWG93sUr8R2Kykw2z 86LiKHXjiOl6LdslVVM47e7zVpCBB/u63ckTYL8DjukRGLNuktKKXpxM6CmENsIJ+g Cqs+Bx5SVuBzYob7QXuOKNdf9ISsr0GVg3rtHiHGcOZTmSKO/l9o0UkMDzw3ESko8F xROC29rUsc7/r2OSyrYNLaiiKFTYWlWp1x9ztkzR04r6qTRlNoeejurWiJzXd2o0Gh GRO+tKvT76OuwUK9PCJ4Uvoo= X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on vm1982.vellance.net X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=ham autolearn_force=no version=3.4.1 Received: from rubens-MacBook-Air.local (ip51ccb320.speed.planet.nl [81.204.179.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by vm1982.vellance.net (Postfix) with ESMTPSA; Wed, 14 Mar 2018 20:36:57 +0100 (CET) Subject: Re: cpupdate : Unsupported version for Intel CPU? From: Ruben To: freebsd-hackers@freebsd.org References: <5AA9556C.2010002@grosbein.net> Cc: Stefan Blachmann Message-ID: Date: Wed, 14 Mar 2018 20:36:56 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Virus-Scanned: ClamAV using ClamSMTP X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 19:37:03 -0000 On 14/03/2018 20:22, Ruben wrote: > Hi, > > Thank you for pointing that out. Forgot about the "download from github > thing". > > Cheers, > > Ruben > > > Forgot to mention, the tool did update the microcode once the correct blob was provided. Regards, Ruben [root@fbh4:/usr/home/ruben/cpupdate]# ./cpupdate -vv -I -f /usr/home/ruben/cpupdate/cpu206C2_plat03_ver0000001D_2015-08-04_PRD_F7DC758B.bin File /usr/home/ruben/cpupdate/cpu206C2_plat03_ver0000001D_2015-08-04_PRD_F7DC758B.bin contains 1 update blobs   Blob 1 of 1 headers info:     Date 2015/08/04     ucode rev  0x0000001d     Header ver 0x00000001     Loader rev 0x00000001     Data size  9168 (0x23d0) ProcessorType:  00 ExtFamily: 00  ExtModel: 02 IntFamily: 06  IntModel: 0C SignatureInt:    206C2 -> Family: 06  Model: 2C  Stepping: 02     Flags      3 (0x00000003) [root@fbh4:/usr/home/ruben/cpupdate]# ./cpupdate -w -vv -U /usr/home/ruben/cpupdate/cpu206C2_plat03_ver0000001D_2015-08-04_PRD_F7DC758B.bin Found CPU(s) from Intel /dev/cpuctl0 identification successful! File /usr/home/ruben/cpupdate/cpu206C2_plat03_ver0000001D_2015-08-04_PRD_F7DC758B.bin contains 1 update blobs Updated core 0 from microcode revision 0x0013 to 0x001d /dev/cpuctl1 identification successful! File /usr/home/ruben/cpupdate/cpu206C2_plat03_ver0000001D_2015-08-04_PRD_F7DC758B.bin contains 1 update blobs Core 1 is up-to-date, not updated. /dev/cpuctl2 identification successful! File /usr/home/ruben/cpupdate/cpu206C2_plat03_ver0000001D_2015-08-04_PRD_F7DC758B.bin contains 1 update blobs Updated core 2 from microcode revision 0x0013 to 0x001d /dev/cpuctl3 identification successful! File /usr/home/ruben/cpupdate/cpu206C2_plat03_ver0000001D_2015-08-04_PRD_F7DC758B.bin contains 1 update blobs Core 3 is up-to-date, not updated. /dev/cpuctl4 identification successful! File /usr/home/ruben/cpupdate/cpu206C2_plat03_ver0000001D_2015-08-04_PRD_F7DC758B.bin contains 1 update blobs Updated core 4 from microcode revision 0x0013 to 0x001d /dev/cpuctl5 identification successful! File /usr/home/ruben/cpupdate/cpu206C2_plat03_ver0000001D_2015-08-04_PRD_F7DC758B.bin contains 1 update blobs Core 5 is up-to-date, not updated. /dev/cpuctl6 identification successful! File /usr/home/ruben/cpupdate/cpu206C2_plat03_ver0000001D_2015-08-04_PRD_F7DC758B.bin contains 1 update blobs Updated core 6 from microcode revision 0x0013 to 0x001d /dev/cpuctl7 identification successful! File /usr/home/ruben/cpupdate/cpu206C2_plat03_ver0000001D_2015-08-04_PRD_F7DC758B.bin contains 1 update blobs Core 7 is up-to-date, not updated. /dev/cpuctl8 identification successful! File /usr/home/ruben/cpupdate/cpu206C2_plat03_ver0000001D_2015-08-04_PRD_F7DC758B.bin contains 1 update blobs Updated core 8 from microcode revision 0x0013 to 0x001d /dev/cpuctl9 identification successful! File /usr/home/ruben/cpupdate/cpu206C2_plat03_ver0000001D_2015-08-04_PRD_F7DC758B.bin contains 1 update blobs Core 9 is up-to-date, not updated. /dev/cpuctl10 identification successful! File /usr/home/ruben/cpupdate/cpu206C2_plat03_ver0000001D_2015-08-04_PRD_F7DC758B.bin contains 1 update blobs Updated core 10 from microcode revision 0x0013 to 0x001d /dev/cpuctl11 identification successful! File /usr/home/ruben/cpupdate/cpu206C2_plat03_ver0000001D_2015-08-04_PRD_F7DC758B.bin contains 1 update blobs Core 11 is up-to-date, not updated. /dev/cpuctl12 identification successful! File /usr/home/ruben/cpupdate/cpu206C2_plat03_ver0000001D_2015-08-04_PRD_F7DC758B.bin contains 1 update blobs Updated core 12 from microcode revision 0x0013 to 0x001d /dev/cpuctl13 identification successful! File /usr/home/ruben/cpupdate/cpu206C2_plat03_ver0000001D_2015-08-04_PRD_F7DC758B.bin contains 1 update blobs Core 13 is up-to-date, not updated. /dev/cpuctl14 identification successful! File /usr/home/ruben/cpupdate/cpu206C2_plat03_ver0000001D_2015-08-04_PRD_F7DC758B.bin contains 1 update blobs Updated core 14 from microcode revision 0x0013 to 0x001d /dev/cpuctl15 identification successful! File /usr/home/ruben/cpupdate/cpu206C2_plat03_ver0000001D_2015-08-04_PRD_F7DC758B.bin contains 1 update blobs Core 15 is up-to-date, not updated. [root@fbh4:/usr/home/ruben/cpupdate]# [root@fbh4:/usr/home/ruben/cpupdate]# ./cpupdate -i Found CPU(s) from Intel Processor Core: 0 -> CPUID: 206c2  Family: 06  Model: 2C  Stepping: 02  uCodeRev: 0000001D Processor Core: 1 -> CPUID: 206c2  Family: 06  Model: 2C  Stepping: 02  uCodeRev: 0000001D Processor Core: 2 -> CPUID: 206c2  Family: 06  Model: 2C  Stepping: 02  uCodeRev: 0000001D Processor Core: 3 -> CPUID: 206c2  Family: 06  Model: 2C  Stepping: 02  uCodeRev: 0000001D Processor Core: 4 -> CPUID: 206c2  Family: 06  Model: 2C  Stepping: 02  uCodeRev: 0000001D Processor Core: 5 -> CPUID: 206c2  Family: 06  Model: 2C  Stepping: 02  uCodeRev: 0000001D Processor Core: 6 -> CPUID: 206c2  Family: 06  Model: 2C  Stepping: 02  uCodeRev: 0000001D Processor Core: 7 -> CPUID: 206c2  Family: 06  Model: 2C  Stepping: 02  uCodeRev: 0000001D Processor Core: 8 -> CPUID: 206c2  Family: 06  Model: 2C  Stepping: 02  uCodeRev: 0000001D Processor Core: 9 -> CPUID: 206c2  Family: 06  Model: 2C  Stepping: 02  uCodeRev: 0000001D Processor Core: 10 -> CPUID: 206c2  Family: 06  Model: 2C  Stepping: 02  uCodeRev: 0000001D Processor Core: 11 -> CPUID: 206c2  Family: 06  Model: 2C  Stepping: 02  uCodeRev: 0000001D Processor Core: 12 -> CPUID: 206c2  Family: 06  Model: 2C  Stepping: 02  uCodeRev: 0000001D Processor Core: 13 -> CPUID: 206c2  Family: 06  Model: 2C  Stepping: 02  uCodeRev: 0000001D Processor Core: 14 -> CPUID: 206c2  Family: 06  Model: 2C  Stepping: 02  uCodeRev: 0000001D Processor Core: 15 -> CPUID: 206c2  Family: 06  Model: 2C  Stepping: 02  uCodeRev: 0000001D From owner-freebsd-hackers@freebsd.org Wed Mar 14 21:13:50 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1D38DF4A22C for ; Wed, 14 Mar 2018 21:13:50 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C2C2F77534 for ; Wed, 14 Mar 2018 21:13:49 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id CE30420AB3 for ; Wed, 14 Mar 2018 17:13:48 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute3.internal (MEProxy); Wed, 14 Mar 2018 17:13:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=ylUyC+NMcPTAaF4pMDebiUyrr9RTo Rj4LLSVhhHf0TA=; b=N7//te9n0af60oi7twcrNnvwfxexOxmNX7IRTusiklmLX Z6ViK6LS/G5iEQ0PQNQTRInT6F1LvRNIdARFsKgdQKnoUWgTX6EifdiCQGC42uCa uuXQSGtWgbbFlCJY4wiTR1KPo+RHT7SzjmebuK1O0dsxiR2PfHwvIpa/H314uQCX ZfGS1pelE4cQUcnGK3DQ8zGck9/noBbRiJV9rg5Rio6tJCBh72X3uUFE4hoMroap +nasNflaI5R7Kipi+AbJUErpVuAX5mcVDkKIQQXGo7NqUPoOCKXEgW1uJLxH2Hyh mTsBWuTiPpXTRqh6lBbNbyo7kf34salJCW5pvWxSQ== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id A2DA7BA43B; Wed, 14 Mar 2018 17:13:48 -0400 (EDT) Message-Id: <1521062028.2511351.1303413736.6960BF4F@webmail.messagingengine.com> From: Mark Felder To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-54087d22 Subject: option TCP_RFC7413 is not in GENERIC Date: Wed, 14 Mar 2018 16:13:48 -0500 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 21:13:50 -0000 Hello all, Has there been a discussion about enabling this in GENERIC? Is there a performance impact even if the sysctl knob is disabled? What can we do to get a wider audience of testers? I would gladly test this for apps that support it but the hurdle of requiring a custom kernel to test this is more effort than its worth... Thanks -- Mark Felder ports-secteam & portmgr member feld@FreeBSD.org From owner-freebsd-hackers@freebsd.org Wed Mar 14 23:38:21 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 04F99F524B8 for ; Wed, 14 Mar 2018 23:38:21 +0000 (UTC) (envelope-from herbert@gojira.at) Received: from mail.bsd4all.net (mail.bsd4all.net [IPv6:2a01:4f8:191:217b::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.bsd4all.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9F4C97DAC2 for ; Wed, 14 Mar 2018 23:38:20 +0000 (UTC) (envelope-from herbert@gojira.at) Date: Thu, 15 Mar 2018 00:38:11 +0100 From: "Herbert J. Skuhra" To: freebsd-hackers@freebsd.org Subject: Re: option TCP_RFC7413 is not in GENERIC Message-ID: <20180314233811.GA35025@mail.bsd4all.net> References: <1521062028.2511351.1303413736.6960BF4F@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1521062028.2511351.1303413736.6960BF4F@webmail.messagingengine.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 23:38:21 -0000 On Wed, Mar 14, 2018 at 04:13:48PM -0500, Mark Felder wrote: > Hello all, > > Has there been a discussion about enabling this in GENERIC? Is there a performance impact even if the sysctl knob is disabled? What can we do to get a wider audience of testers? I would gladly test this for apps that support it but the hurdle of requiring a custom kernel to test this is more effort than its worth... https://svnweb.freebsd.org/base?view=revision&revision=330002 -- Herbert From owner-freebsd-hackers@freebsd.org Thu Mar 15 05:18:29 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0A3F7F4D9AA for ; Thu, 15 Mar 2018 05:18:29 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-ot0-x235.google.com (mail-ot0-x235.google.com [IPv6:2607:f8b0:4003:c0f::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9B5A66CA21 for ; Thu, 15 Mar 2018 05:18:28 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: by mail-ot0-x235.google.com with SMTP id g97-v6so5650480otg.13 for ; Wed, 14 Mar 2018 22:18:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=+LQHi5mBnhzbL4WcvUoHLaM6bz1R+BqvAwcGUqBx0As=; b=NZyVr21hyXmjnI6mQ8d6xQrzIcs/CAIPZnnsi0hW7LREzocFdPEn3z8QjYbuT0TGvE pHR7Jk5LlwS4uOeWGQ89eJPSCs+2dnFMcTCuRugxSB0dm7QnDfhAgw9sRE9qtnQ1ause Yl+Ie5Af9IykHuBsb024m35/sBhfvqy9GyHojXoAbuGk7k2LFBGXsemcumCGnKQuM0N8 ts5VH8/RlzS2/SR0B5QS1XIOImJj1Q8iZadEh4ALxVbxHS2Rl0cFZJSC7h4mx8plVknh 443EJoEeovO6ZL0ny0+pHIPDvbJp9UXqQ8c1SLSszgQHJY8qo+Vtp0CmHDUNyZX8WoKj 6Zaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=+LQHi5mBnhzbL4WcvUoHLaM6bz1R+BqvAwcGUqBx0As=; b=f6tWstuCeQ6LjTlvooSJXMrBCV/1+k9I5Hk862uzp2CMXgjoJCcJTl65zqMCwdVF82 uH70WKsLTKRt28qhl89s07Tp0CepDI5sjVUDtHbgqKXwwzWwcax+CQ4mSiGL5Kvn0XvM KoHX0+Cr3hf+noP4b+R5pSr9nxHFgSAX1wY9z1wsoalsJfoCJfQE0cDXw87Dfaml+Y+R ur9PeEJIaJK6t4+1RVi2FQkaczVbvJsEng9nOAh1MuftXWfw7Q+/Y3EWKInv/hAMWsx0 mPoRXme/qsIFiXpTrgkC+apAmBNQEhSMZU/7S+ObxHu9BqYaKnohQj6Kvx/635ugq4H8 sImg== X-Gm-Message-State: AElRT7Fzp/bSsbx2ZSt+Z1nskyR1bo9MgnRlakG69hYnrGMMtse4uwE0 RUWVYebRU5oLMAve363goflUKtgF4aKjdBPcefY= X-Google-Smtp-Source: AG47ELt2+4MsvVoew1UPMBiwDThhGIhuhm3DyLr5K889MyDW9acqhbjmIP5ioNQzKJiPlQ565bFzDrBxe+8Ufs2RHdg= X-Received: by 10.157.35.61 with SMTP id j58mr4986457otb.355.1521091107737; Wed, 14 Mar 2018 22:18:27 -0700 (PDT) MIME-Version: 1.0 Sender: kmacybsd@gmail.com Received: by 2002:a9d:2d89:0:0:0:0:0 with HTTP; Wed, 14 Mar 2018 22:18:27 -0700 (PDT) In-Reply-To: References: From: "K. Macy" Date: Wed, 14 Mar 2018 22:18:27 -0700 X-Google-Sender-Auth: o8FIy-gFDBocZx7M-9r3xh1m_24 Message-ID: Subject: Re: Possible GSoC idea, eBPF for FreeBSD To: Yutaro Hayakawa Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2018 05:18:29 -0000 Do you have your work in progress code on github somewhere?. -M On Sun, Mar 11, 2018 at 4:08 AM, Yutaro Hayakawa wrote: > Dear FreeBSD Hackers > > Hello, this is Yutaro Hayakawa, master student of Keio University Japan. > > I=E2=80=99m now working for implementing eBPF for FreeBSD. I had talk abo= ut this > in BSDCam2017 (https://wiki.freebsd.org/DevSummit/201708 ) and will make > talk in BSDCan2018 (https://lists.bsdcan.org/pipermail/bsdcan-announce/20= 18-March/000168.html ). > > Below you can see some work in progress codes. > > eBPF itself: https://github.com/YutaroHayakawa/generic-ebpf > eBPF + VALE software switch: https://github.com/YutaroHayakawa/vale-bpf <= https://github.com/YutaroHayakawa/vale-bpf> > > To move this work forward, I=E2=80=99d like to make this GSoC project. I = have a rough idea > for what I do in 12weeks, but not yet discuss it with FreeBSD people. > > Is there anyone who willing to mentor this work? Could you discuss about = this with > me? > > Best Regards, > Yutaro > > > P.S > For the people attended to AsiaBSDCon2018, I hope you enjoy Tokyo! > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " From owner-freebsd-hackers@freebsd.org Thu Mar 15 20:00:12 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 02A56F4E6CC for ; Thu, 15 Mar 2018 20:00:12 +0000 (UTC) (envelope-from yhayakawa3720@gmail.com) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 61A8F752AA for ; Thu, 15 Mar 2018 20:00:11 +0000 (UTC) (envelope-from yhayakawa3720@gmail.com) Received: by mail-wm0-x231.google.com with SMTP id e194so12644168wmd.3 for ; Thu, 15 Mar 2018 13:00:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=qaa2qJno8BqXMjeQIEuW4HGY10uXrSsR/jJwASiUAqI=; b=Ds2HfRMn3ugSCtDCXmrUS5vhmMy3XqjxT+8RvnHqDMmdLMF/m664JUf/ejuOsTsHDV 35qeG0qFxy+9QPPgAkN4xreK+fprT6VOP3jgs9UuqG524qNkinwVJui/01l/K2pnxn+1 DHWchkKVTRsKEE98dD75f2QWNd75NGwvIiVvChkOM2r/l8LneSZV5HOT51ocoXlUpDN8 zVGRuKKB1CFifdcHhHQz/9tFdOzUuxlq6PZSzc/JWpz0lEDuAMTVDxaxeGu2R/Etxmgw 7E4Gn0HAallPZSpMms1gc6dscWb9Sk+t/94A+e9aYe28ru24SpjOcI2iMX8YTVj44y3v uy/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=qaa2qJno8BqXMjeQIEuW4HGY10uXrSsR/jJwASiUAqI=; b=URDaQ0x2RoeC+QVsz9zdsz9wq2GnylW1pozhQ8X+q1yK9vA86nm6WwFPZ8khDE4yw6 EBTCpLjI0zax3W0rH4m1/XLvjYNnfHAQevMpyMX5n37x1yXnh+yJ/gOMeXVPEhk9QSWO Bp3aRG1rJELNfSzVps4SNDCofKLac8KoYPGFZZQwUqo1WLIEYfwMAK2jC3plNhY5u8YZ uY+lTy5EFMLfBke7msAD+Y7Yoz0N0SeBZW6Oxg6NtzFCcXo0NS3LTZL6jwuau2xH0wnu KlcdJjN34TGA7REf47ZZ0gKZGfIhhwKQZ3KrZtWS5r3CBJ05z6LFqc0jNf3HSPHJvsSn hniw== X-Gm-Message-State: AElRT7G9hAqUbhg9/qahxi5BZC0HgV37jccF00y6c12Fl0masmoiGJbb JXa0UkZGqvbmQhcrZfDDvIo3S4R0 X-Google-Smtp-Source: AG47ELvEpHT0Drs99z26KHqwerVCUSbHidN9ucsz8Pa41yUqYT5TGelkSopt9H8959+W+i9bwqasjQ== X-Received: by 10.28.196.143 with SMTP id u137mr5363143wmf.74.1521144009080; Thu, 15 Mar 2018 13:00:09 -0700 (PDT) Received: from ?IPv6:2a02:8071:b96:f600:bc36:16b2:208f:6de8? ([2a02:8071:b96:f600:bc36:16b2:208f:6de8]) by smtp.gmail.com with ESMTPSA id r6sm6519582wrg.63.2018.03.15.13.00.08 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Mar 2018 13:00:08 -0700 (PDT) From: Yutaro Hayakawa Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Possible GSoC idea, eBPF for FreeBSD Message-Id: Date: Thu, 15 Mar 2018 21:00:07 +0100 To: freebsd-hackers@FreeBSD.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2018 20:00:12 -0000 Dear FreeBSD hackers, I submitted my first draft to GSoC page. I=E2=80=99m very happy to have = your feedback! Regards, Yutaro= From owner-freebsd-hackers@freebsd.org Fri Mar 16 02:22:40 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8B0FEF41944; Fri, 16 Mar 2018 02:22:40 +0000 (UTC) (envelope-from thedarshansharma@gmail.com) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 26DF385E76; Fri, 16 Mar 2018 02:22:40 +0000 (UTC) (envelope-from thedarshansharma@gmail.com) Received: by mail-qk0-x22d.google.com with SMTP id b198so9565268qkg.9; Thu, 15 Mar 2018 19:22:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=DXCxemrvN3S7XdTr/koI5X1A9NXeR2xhx5VK7k298I8=; b=HMJa0rhz6xC0FmMNj0tZaLz1aRLKOB0Y32VCLeevlhS5Ru0gPp18lxvrEttsDRNZXx p0uw+dL8ORsQvYvxwYCWoEPWCoaagK7yy6UH0BSntqBO6sXKK53mGQuG6KXj8btDGyRr t1x8m08CYKoD24DNI18oyakAQR/WSjzOS75LVLpxSGhmWHp8UdVvfUw77JdfGsG6/+s9 BcN8FYMtOWDrL7fJ4oecKHmfEDZIjrngsHaHIre4sFIDFP6bY46Ee+aJ1qOgvLrPPKOm CdfKk2GwoJTzlIyfxZjLOBiIlvRlfmsEEC12hYJUWDtygDuwzqshpnrLD2PwaumDQJx2 jjOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=DXCxemrvN3S7XdTr/koI5X1A9NXeR2xhx5VK7k298I8=; b=rf2eOh2S52szR9k7vPZonfxRGRevFGrARID/A7flGJLu2GrRJCzooJI7e9xOyedTBU tCsS/MQV8H/AcxbEWW7HVyiK+F+1pN+OZl16QWrA2vmoVFEoRFaO/l6RN93Zlbu3cEM3 LBGPZm47c/kF7fiJiXSS8EruJilS5U9IW9fv++42x98R+ken2NGql6QHUtZSxlOQ9Snr uomvSZVvCEdCGbYV+0qLBTRMNSbs8su4zIufW7knPH/p+b2C0VNlBhRvDA19kFj/ODgy 2z3xfLKPYDix7Q/QHv/VyUds8Qr49yR47jXyfLn9jRIwgIqSesbcl6W4VTaj2o0FdU3C l+8g== X-Gm-Message-State: AElRT7FL1hKs/w1Oy9u1TPhVm8b4RWw7CqdOGy8gHYpYB2WzbOnPqMNM WUDtutyBR3G3pMUV8BawmPbBnKucA/5vUaCMDCUqyQGC+Pg= X-Google-Smtp-Source: AG47ELvdAUGr9os8Gy1GCFgvQOQooiEu2bvMsdaKIZcfA9nmzbSXSfnaVvIv4Vji7yIAhdbjrsuS5ozcQxeBLg4IE/4= X-Received: by 10.55.24.214 with SMTP id 83mr144635qky.267.1521166959433; Thu, 15 Mar 2018 19:22:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.181.226 with HTTP; Thu, 15 Mar 2018 19:22:39 -0700 (PDT) From: Darshan Sharma Date: Fri, 16 Mar 2018 07:52:39 +0530 Message-ID: Subject: GSoC idea: Improve support for an embedded CPU/board To: freebsd-arm@freebsd.org Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2018 02:22:40 -0000 Hello, I am Darshan Sharma a CSE student from Panjab University, India. I like the idea of - Improve support for an embedded CPU/board . I will choose an arm based board for this because that is more easily available in our country. Though I have not selected any specific board yet but soon will. I have used Gentoo before so I am already familiar with kernel programming. I will be happy to learn new things which will stand in my way and I am sure enough that I can complete the project in the given time. Is there anyone who is willing to mentor this project? I will discuss this more with you. My GitHub Profile - https://github.com/darshansharma My Linkedin Profile - https://www.linkedin.com/in/darshansharmain/ Thanks & Regards, Darshan Sharma From owner-freebsd-hackers@freebsd.org Fri Mar 16 16:04:18 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 08DEEF59FA8 for ; Fri, 16 Mar 2018 16:04:18 +0000 (UTC) (envelope-from pkelsey@gmail.com) Received: from mail-pl0-f48.google.com (mail-pl0-f48.google.com [209.85.160.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 713F486785 for ; Fri, 16 Mar 2018 16:04:17 +0000 (UTC) (envelope-from pkelsey@gmail.com) Received: by mail-pl0-f48.google.com with SMTP id w15-v6so6168688plq.9 for ; Fri, 16 Mar 2018 09:04:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=HgsdVwKUQRM6kh09Lw17hb1Z5vV91CIY8oh6XyXM0us=; b=fr9L+CyUyPv54FV5JO33lDpk1QXHxDFofJY5svmxlAL7owGbA6YAIo6QsPrWxM0oG0 L0nbKR/4QzYgbLSjfmrQBVNMEdPPWlPyGdLtOqbzhyCoOZe3qyrMIIe+0/BuuZFRhy5Q 2OgAPU+LqhCLUuWaLVADB0nU76WUPseWRJJv2VBN/EkUeawWoVRPpfP+Ur24o4mZ1+dc iZzIIbnxRuPipQw/RGP3MTAKxnKsVgnCkW9XlPimMLop59DceEEb05b8pIcR3N/GXvKi o0CixLRSD78c76/sC6YNY669m3xigWMhLZ+/cFPAYR/sK9VzKMc72zWq/5LnNBgHvcv6 A2xA== X-Gm-Message-State: AElRT7FgLfQXnPYOU2sivu1kmNxZER6cQCQwx6a2tevhrQLPawTzWVvu Wke3FDxQEJ2QyO+5cjtupq70+wgASv6bXQarHR4= X-Google-Smtp-Source: AG47ELtADxmkjtDTTn67gYYP+ZXmL+s8gT5s7xM8sCBuubZVHmca6nzpr5YIocoRzbu6pi3kl10l/2+rt/kLwLHSkt8= X-Received: by 2002:a17:902:59c9:: with SMTP id d9-v6mr2723192plj.251.1521216254846; Fri, 16 Mar 2018 09:04:14 -0700 (PDT) MIME-Version: 1.0 References: <1521062028.2511351.1303413736.6960BF4F@webmail.messagingengine.com> <20180314233811.GA35025@mail.bsd4all.net> In-Reply-To: <20180314233811.GA35025@mail.bsd4all.net> From: Patrick Kelsey Date: Fri, 16 Mar 2018 16:04:04 +0000 Message-ID: Subject: Re: option TCP_RFC7413 is not in GENERIC To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2018 16:04:18 -0000 On Wed, Mar 14, 2018 at 7:39 PM Herbert J. Skuhra wrote: > On Wed, Mar 14, 2018 at 04:13:48PM -0500, Mark Felder wrote: > > Hello all, > > > > Has there been a discussion about enabling this in GENERIC? Is there a > performance impact even if the sysctl knob is disabled? What can we do to > get a wider audience of testers? I would gladly test this for apps that > support it but the hurdle of requiring a custom kernel to test this is more > effort than its worth... > > > https://svnweb.freebsd.org/base?view=revision&revision=330002 > > I plan on merging all of the TFO deltas between current and stable/11 to stable/11 ahead of the 11.2 release process. tuexen@ has been doing some good bug hunting on the new client-side implementation in -current and there are other parties testing it as well. I think there is still technically a question as to whether it will be enabled by default in 11.2, only because there is still some poking and prodding we have left to do, but I also think we will complete all of that in time. As to performance impact when it is compiled in, but disabled, I have heard that some small differences have been measured, but I've seen neither the methodology used nor the actual measurement results. Mechanically what is going on in that case is you will wind up with some additional flag checks in the TCP input and output paths and in some cases additional instructions that you don't need being pulled into the I-cache, compared to what would occur if it was compiled out. The current thinking is that users who care about such performance differences are dealing with extreme workloads that already motivate them to compile their own kernels, or are working with very resource-constrained platforms, so the way forward is to keep the TCP_RFC7413 kernel option around and enable it by default for the server-class platforms (armd64 and arm64). Best, Patrick From owner-freebsd-hackers@freebsd.org Fri Mar 16 16:12:05 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B9C29F5A840 for ; Fri, 16 Mar 2018 16:12:05 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 44F3A86ECC for ; Fri, 16 Mar 2018 16:12:04 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: c08f8e02-2934-11e8-91c6-33ffc249f3e8 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id c08f8e02-2934-11e8-91c6-33ffc249f3e8; Fri, 16 Mar 2018 16:11:59 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w2GGBrB7029016; Fri, 16 Mar 2018 10:11:53 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1521216713.99081.55.camel@freebsd.org> Subject: Re: option TCP_RFC7413 is not in GENERIC From: Ian Lepore To: Patrick Kelsey , freebsd-hackers@freebsd.org Date: Fri, 16 Mar 2018 10:11:53 -0600 In-Reply-To: References: <1521062028.2511351.1303413736.6960BF4F@webmail.messagingengine.com> <20180314233811.GA35025@mail.bsd4all.net> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2018 16:12:05 -0000 On Fri, 2018-03-16 at 16:04 +0000, Patrick Kelsey wrote: > The current thinking is that users who care > about such performance differences are dealing with extreme workloads that > already motivate them to compile their own kernels, or are working with > very resource-constrained platforms, so the way forward is to keep the > TCP_RFC7413 kernel option around and enable it by default for the > server-class platforms (armd64 and arm64). I have no idea what TCP_RFC7413 even is, but I know I was forced to add it to my kernel config when I installed the bind911 package during a recent upgrade. This is on a tiny NUC for which saturating even one of its gbe interfaces would count as "extreme workload". :) -- Ian From owner-freebsd-hackers@freebsd.org Fri Mar 16 16:47:39 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 782B5F5D149 for ; Fri, 16 Mar 2018 16:47:39 +0000 (UTC) (envelope-from pkelsey@gmail.com) Received: from mail-pf0-f172.google.com (mail-pf0-f172.google.com [209.85.192.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EEF5C68CB5 for ; Fri, 16 Mar 2018 16:47:38 +0000 (UTC) (envelope-from pkelsey@gmail.com) Received: by mail-pf0-f172.google.com with SMTP id q13so4365709pff.0 for ; Fri, 16 Mar 2018 09:47:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=owqApDWUV6Vni4/aZ9glClQ7+EcpNTM+BXqEHCKDlVE=; b=qzZWfY3V7Uw9PnFp+iXK0GyT7/GQB0CYRNddPVtK20LxUqE8i/m2bKBLL1or0ho6i0 +D+pKN4f5RAvjNpX38QhGjEHBwC12VoOFDMFMwVR9g0SzG/1AQ4b5C6pFs4hhfOBrWBU hBWP8N8iJ6FqFqFYbMBvI49xiWeSE3nOlHwPV7q9WDBiEC+qZDx1B3bZI2FU0nZ+2U7m JXh6SD7v0MX2knErK8Pb9AcP1jzbE6x++Gp1Ew/4VSYXZmO9eHil+cUHIWua3t4qwhc1 Gtl+y8CqtdqFQuX8LUlpW+oJZUWsRB9k6CnmSlOpMkpTNuMkrDTPPY4+Ji+sIOZxGvwW moDA== X-Gm-Message-State: AElRT7FwbUaKqhEowQA7RanKzsTpWFniGsIx/zfXxoXs8ility722QdB mx5pZGfcNWp6mPUrrJ5+xl5Aw2UimVlH/VlGVEg= X-Google-Smtp-Source: AG47ELudBhBRaRrhi1AktdgYO3PPYSX9fazdD/6xV1ZkFBO5+3mv2olhytyK4Q/cyIj86/Q18e1PMz4jjIHPgwudQOM= X-Received: by 10.99.112.92 with SMTP id a28mr1921176pgn.17.1521218541005; Fri, 16 Mar 2018 09:42:21 -0700 (PDT) MIME-Version: 1.0 References: <1521062028.2511351.1303413736.6960BF4F@webmail.messagingengine.com> <20180314233811.GA35025@mail.bsd4all.net> <1521216713.99081.55.camel@freebsd.org> In-Reply-To: <1521216713.99081.55.camel@freebsd.org> From: Patrick Kelsey Date: Fri, 16 Mar 2018 16:42:10 +0000 Message-ID: Subject: Re: option TCP_RFC7413 is not in GENERIC To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2018 16:47:39 -0000 On Fri, Mar 16, 2018 at 12:12 PM Ian Lepore wrote: > On Fri, 2018-03-16 at 16:04 +0000, Patrick Kelsey wrote: > > The current thinking is that users who care > > about such performance differences are dealing with extreme workloads > that > > already motivate them to compile their own kernels, or are working with > > very resource-constrained platforms, so the way forward is to keep the > > TCP_RFC7413 kernel option around and enable it by default for the > > server-class platforms (armd64 and arm64). > > I have no idea what TCP_RFC7413 even is, but I know I was forced to add > it to my kernel config when I installed the bind911 package during a > recent upgrade. This is on a tiny NUC for which saturating even one of > its gbe interfaces would count as "extreme workload". :) > > RFC7413 is TCP Fast Open (TFO), which is a way to short-circuit TCP handshakes if conditions are met. I'm curious as to why you were forced to add the option to your kernel config when you installed bind911. Maybe that version of bind was assuming something like 'if the TCP_FASTOPEN sockopt is defined in a header, then all setsockopt(TCP_FASTOPEN) should succeed or else die'? That would be a very weird assumption, as the MacOS, Linux, and FreeBSD implementations all have a sysctl that can be used to disable the feature system-wide at any point in time. -Patrick From owner-freebsd-hackers@freebsd.org Fri Mar 16 17:01:08 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5DBF8F5E0F6 for ; Fri, 16 Mar 2018 17:01:08 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BF822697CD; Fri, 16 Mar 2018 17:01:07 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf0-x22a.google.com with SMTP id z143-v6so10116563lff.3; Fri, 16 Mar 2018 10:01:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=4gvXK8bHgF8Yz4oagJ/GcI0mMCowGON+97osrn1RVBM=; b=vX6Ki6W8eXMtW030BGv5YBRn61F9UNdL80yutN+JdiwBGEH3WAMzWdwKIKJED17ejq Zt0N5Uvytr1C0P0FCz1MtoT3WEmzVwm2MsYyuuuMtxw4vjBUjMmAFhNx9vskjjgbslb0 QQnZo3qlaT1k+RSXrfAhMCWYFFVme/j8f6hz1CJJ9tY5Ju9fLUdPFkiLcD3tnY/NBbdj SY8IRXHVBOeja9AZMAgVZZdoa8PnZBfB8EeacudBjc0Bk5mryeLyHdc5+1E4O3LMnyxo ZtLRWszaG2PPvWR3WcfNiEgE557mcs2ZkhxoqnibRmqg+Zs8LxQTimKfl2Yhxlk7M4Oy GDrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=4gvXK8bHgF8Yz4oagJ/GcI0mMCowGON+97osrn1RVBM=; b=j45MoQUmMPeOGFAlxUU2mGto+r2HjxFS1FPiQSfNQFYjJaZ39CjmRjmy1UdKASxAV0 sVdgLjBb/mNEPy9YYVXnW6N4o/Trpb5bxwiolsTH8n3EjwZh3Q4smTbE9G5wc6AeLSIN Q1nLWc6A1hm4ALovRDB3bBSNcR/0I7Niuw5HkaeKk/zsRPCB+I2aGOBKI+hlZkm3KYNO rpQibKHEVWzZblQIWpqG7tPtVllvqSWYFiGL6uhmgvJSe5zueISkGcGHkZrKMwaY8W3F 6fICU/GxWyFJ1pjiEj6ci27rNnIK1+2KwEayvvc3GCSRkZN9teedXaOnyBq+zxGkCUH7 kH+w== X-Gm-Message-State: AElRT7FITHyvj6CwGeVXZ3NGZdws1wrtrygnU3xZ6SIjKF9PujoIWKsh 7y95Dk+oLG25pyE0cudE/QDWOg047jnWGsuvUyLmEg== X-Google-Smtp-Source: AG47ELuo0W52qufYrgtVLqFhKuYei2ydlqEINDdmQLB6DVZ+xQZjWkQnkJjpY6CCwBaheBxkw2y5OZHlGvsVuqL19qE= X-Received: by 2002:a19:14d1:: with SMTP id 78-v6mr1982210lfu.37.1521219665868; Fri, 16 Mar 2018 10:01:05 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.179.3.226 with HTTP; Fri, 16 Mar 2018 10:01:04 -0700 (PDT) From: Alan Somers Date: Fri, 16 Mar 2018 11:01:04 -0600 X-Google-Sender-Auth: e4xvbtD7F1bVWsPLMXT9Nn9LvOE Message-ID: Subject: Is it time to expose timespecsub and friends to userland? To: FreeBSD Hackers , bde@freebsd.org, Poul-Henning Kamp Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2018 17:01:08 -0000 There are at least 19 system calls that have timeout arguments specified as struct timespec [1]. "struct stat" describes file timestamps as timespecs as well [2]. setsockopt(2), sched_rr_get_interval(2), geom_stats_snapshot_timestamp(3) and pmclog_read(3) use timespecs for other purposes. The sysctl node kern.crypto_stats exposes timespecs. sudo records timespecs in its timestamp files. Who know how many other ports do something similar; I'm not going to grep them all. And yet, FreeBSD provides no way to manipulate this structure. Every program that uses them has to roll its own version of pretty much the same functions. NetBSD does [3], and has for a long time. In fact, NetBSD's timespecsub is old enough to drink [4]. But in FreeBSD, those functions languish inside of an "#ifdef KERNEL". phk added them in r35029 with the comment "XXX: These may change!". But it's been nearly 20 years, so I don't think they're going to change any more. Shall we finally expose them to userland and add a man page? Let the bikeshed begin! If the flame isn't too bad, I'll do it. -Alan [1] syscalls that use timespec timeouts include: aio_suspend(2), aio_waitcomplete(2), nanosleep(2), clock_nanosleep(2), kevent(2), mq_timedreceive(2), mq_timedsend(2), ppoll(2), pselect(2), recvmmsg(2), sigtimedwait(2), thr_suspend(2), cnd_timedwait(3), mtx_timedlock(3), thrd_sleep(3), pthread_mutex_timedlock(3), pthread_cond_timedwait(3), sem_timedwait(3), sem_clockwait_np(3). [2] syscalls that use timespecs for file timestamp related purposes: stat(2), fstat(2), futimens(2), utimensat(2), lstat(2) [3] http://netbsd.gw.com/cgi-bin/man-cgi?timespecclear+3+NetBSD-7.0 [4] http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/sys/time.h.diff?r1=1.19&r2=1.20&only_with_tag=MAIN&f=h From owner-freebsd-hackers@freebsd.org Fri Mar 16 17:24:41 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 861FCF5FA43 for ; Fri, 16 Mar 2018 17:24:41 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from mail.infocus-llc.com (mail.infocus-llc.com [199.15.120.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 29C406A7D9; Fri, 16 Mar 2018 17:24:40 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from draco.over-yonder.net (c-75-65-60-66.hsd1.ms.comcast.net [75.65.60.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.tarragon.infocus-llc.com (Postfix) with ESMTPSA id 402slQ0hTnzCV; Fri, 16 Mar 2018 12:24:34 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 402slP37MvzC47; Fri, 16 Mar 2018 12:24:33 -0500 (CDT) Date: Fri, 16 Mar 2018 12:24:33 -0500 From: "Matthew D. Fuller" To: Patrick Kelsey Cc: freebsd-hackers@freebsd.org Subject: Re: option TCP_RFC7413 is not in GENERIC Message-ID: <20180316172433.GF83683@over-yonder.net> References: <1521062028.2511351.1303413736.6960BF4F@webmail.messagingengine.com> <20180314233811.GA35025@mail.bsd4all.net> <1521216713.99081.55.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2018 17:24:41 -0000 On Fri, Mar 16, 2018 at 04:42:10PM +0000 I heard the voice of Patrick Kelsey, and lo! it spake thus: > > I'm curious as to why you were forced to add the option to your > kernel config when you installed bind911. I suspect it's not quite "forced to", but you otherwise have to ignore all the squawcking it does every time it starts up about failing to set the option on all its sockets... (me, I moved past ignoring it to taking perverse pleasure in it. Haha, silly daemon. You brought this on yourself, so now you must suffffaaaahhhh...) -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-hackers@freebsd.org Fri Mar 16 18:07:15 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 43937F624AF for ; Fri, 16 Mar 2018 18:07:15 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BB6876C9F1 for ; Fri, 16 Mar 2018 18:07:14 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: b45caf0b-2944-11e8-b951-f99fef315fd9 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id b45caf0b-2944-11e8-b951-f99fef315fd9; Fri, 16 Mar 2018 18:06:10 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w2GI75fR029310; Fri, 16 Mar 2018 12:07:05 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1521223625.99081.61.camel@freebsd.org> Subject: Re: option TCP_RFC7413 is not in GENERIC From: Ian Lepore To: Patrick Kelsey , freebsd-hackers@freebsd.org Date: Fri, 16 Mar 2018 12:07:05 -0600 In-Reply-To: References: <1521062028.2511351.1303413736.6960BF4F@webmail.messagingengine.com> <20180314233811.GA35025@mail.bsd4all.net> <1521216713.99081.55.camel@freebsd.org> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2018 18:07:15 -0000 On Fri, 2018-03-16 at 16:42 +0000, Patrick Kelsey wrote: > On Fri, Mar 16, 2018 at 12:12 PM Ian Lepore wrote: > > > > > On Fri, 2018-03-16 at 16:04 +0000, Patrick Kelsey wrote: > > > > > > The current thinking is that users who care > > > about such performance differences are dealing with extreme workloads > > that > > > > > > already motivate them to compile their own kernels, or are working with > > > very resource-constrained platforms, so the way forward is to keep the > > > TCP_RFC7413 kernel option around and enable it by default for the > > > server-class platforms (armd64 and arm64). > > I have no idea what TCP_RFC7413 even is, but I know I was forced to add > > it to my kernel config when I installed the bind911 package during a > > recent upgrade.This is on a tiny NUC for which saturating even one of > > its gbe interfaces would count as "extreme workload". :) > > > > > RFC7413 is TCP Fast Open (TFO), which is a way to short-circuit TCP > handshakes if conditions are met.I'm curious as to why you were > forced to add the option to your kernel config when you installed bind911. > Maybe that version of bind was assuming something like 'if the TCP_FASTOPEN > sockopt is defined in a header, then all setsockopt(TCP_FASTOPEN) should > succeed or else die'?That would be a very weird assumption, as the MacOS, > Linux, and FreeBSD implementations all have a sysctl that can be used to > disable the feature system-wide at any point in time. > > -Patrick Oh, then I assume it's because TCP_FASTOPEN is in the default options when the package gets built. -- Ian From owner-freebsd-hackers@freebsd.org Fri Mar 16 18:08:42 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8FB93F62658 for ; Fri, 16 Mar 2018 18:08:42 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1B6276CB1F for ; Fri, 16 Mar 2018 18:08:41 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 0e1f51cb-2945-11e8-91c6-33ffc249f3e8 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 0e1f51cb-2945-11e8-91c6-33ffc249f3e8; Fri, 16 Mar 2018 18:08:41 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w2GI8ZLi029318; Fri, 16 Mar 2018 12:08:35 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1521223715.99081.62.camel@freebsd.org> Subject: Re: option TCP_RFC7413 is not in GENERIC From: Ian Lepore To: "Matthew D. Fuller" , Patrick Kelsey Cc: freebsd-hackers@freebsd.org Date: Fri, 16 Mar 2018 12:08:35 -0600 In-Reply-To: <20180316172433.GF83683@over-yonder.net> References: <1521062028.2511351.1303413736.6960BF4F@webmail.messagingengine.com> <20180314233811.GA35025@mail.bsd4all.net> <1521216713.99081.55.camel@freebsd.org> <20180316172433.GF83683@over-yonder.net> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2018 18:08:42 -0000 On Fri, 2018-03-16 at 12:24 -0500, Matthew D. Fuller wrote: > On Fri, Mar 16, 2018 at 04:42:10PM +0000 I heard the voice of > Patrick Kelsey, and lo! it spake thus: > > > > > > I'm curious as to why you were forced to add the option to your > > kernel config when you installed bind911. > I suspect it's not quite "forced to", but you otherwise have to > ignore > all the squawcking it does every time it starts up about failing to > set the option on all its sockets... > > (me, I moved past ignoring it to taking perverse pleasure in it. > Haha, silly daemon.You brought this on yourself, so now you must > suffffaaaahhhh...) > > I vaguely remember that dire-looking messages in syslog is what "forced" me to build a new kernel, probably because it wasn't clear that they could be safely ignored. -- Ian From owner-freebsd-hackers@freebsd.org Fri Mar 16 18:09:55 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6CD98F62804 for ; Fri, 16 Mar 2018 18:09:55 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ED7656CCCC for ; Fri, 16 Mar 2018 18:09:54 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 38ba0007-2945-11e8-91c6-33ffc249f3e8 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 38ba0007-2945-11e8-91c6-33ffc249f3e8; Fri, 16 Mar 2018 18:09:54 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w2GI9lJK029325; Fri, 16 Mar 2018 12:09:47 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1521223787.99081.63.camel@freebsd.org> Subject: Re: Is it time to expose timespecsub and friends to userland? From: Ian Lepore To: Alan Somers , FreeBSD Hackers , bde@freebsd.org, Poul-Henning Kamp Date: Fri, 16 Mar 2018 12:09:47 -0600 In-Reply-To: References: Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2018 18:09:55 -0000 On Fri, 2018-03-16 at 11:01 -0600, Alan Somers wrote: > There are at least 19 system calls that have timeout arguments specified as > struct timespec [1]."struct stat" describes file timestamps as timespecs > as well [2].setsockopt(2),sched_rr_get_interval(2), > geom_stats_snapshot_timestamp(3) and pmclog_read(3) use timespecs for other > purposes.The sysctl node kern.crypto_stats exposes timespecs.sudo > records timespecs in its timestamp files.Who know how many other ports do > something similar; I'm not going to grep them all. > > And yet, FreeBSD provides no way to manipulate this structure.Every > program that uses them has to roll its own version of pretty much the same > functions.NetBSD does [3], and has for a long time.In fact, NetBSD's > timespecsub is old enough to drink [4].But in FreeBSD, those functions > languish inside of an "#ifdef KERNEL".phk added them in r35029 with the > comment "XXX: These may change!".But it's been nearly 20 years, so I > don't think they're going to change any more. > > Shall we finally expose them to userland and add a man page?Let the > bikeshed begin!If the flame isn't too bad, I'll do it. > > -Alan > > [1] syscalls that use timespec timeouts include: aio_suspend(2), > aio_waitcomplete(2), nanosleep(2), clock_nanosleep(2), kevent(2), > mq_timedreceive(2), mq_timedsend(2), ppoll(2), pselect(2), recvmmsg(2), > sigtimedwait(2), thr_suspend(2), cnd_timedwait(3), mtx_timedlock(3), > thrd_sleep(3), pthread_mutex_timedlock(3), pthread_cond_timedwait(3), > sem_timedwait(3), sem_clockwait_np(3). > > [2] syscalls that use timespecs for file timestamp related purposes: > stat(2), fstat(2), futimens(2), utimensat(2), lstat(2) > > [3] http://netbsd.gw.com/cgi-bin/man-cgi?timespecclear+3+NetBSD-7.0 > > [4] > http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/sys/time.h.diff?r1=1.19&r2=1.20&only_with_tag=MAIN&f=h IMO, it's long overdue. I've never understood why they weren't exposed on the day the were added. -- Ian From owner-freebsd-hackers@freebsd.org Fri Mar 16 19:01:18 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 36B17E02 for ; Fri, 16 Mar 2018 19:01:18 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id C848F6F3F1; Fri, 16 Mar 2018 19:01:17 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id B2CB9273B5; Fri, 16 Mar 2018 19:01:10 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTPS id w2GJ0sVD065725 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 16 Mar 2018 19:00:54 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.15.2/8.15.2/Submit) id w2GJ0sjI065724; Fri, 16 Mar 2018 19:00:54 GMT (envelope-from phk) To: Ian Lepore cc: Alan Somers , FreeBSD Hackers , bde@freebsd.org Subject: Re: Is it time to expose timespecsub and friends to userland? In-reply-to: <1521223787.99081.63.camel@freebsd.org> From: "Poul-Henning Kamp" References: <1521223787.99081.63.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <65722.1521226853.1@critter.freebsd.dk> Date: Fri, 16 Mar 2018 19:00:54 +0000 Message-ID: <65723.1521226854@critter.freebsd.dk> X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2018 19:01:18 -0000 -------- In message <1521223787.99081.63.camel@freebsd.org>, Ian Lepore writes: >IMO, it's long overdue. I've never understood why they weren't exposed >on the day the were added. I have a faint recollection that there were many copies in userland already which I didn't want to deal with right there and then. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@freebsd.org Fri Mar 16 19:31:09 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A1BCCF417E3 for ; Fri, 16 Mar 2018 19:31:09 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1FC5970858; Fri, 16 Mar 2018 19:31:09 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf0-x231.google.com with SMTP id h127-v6so16919099lfg.12; Fri, 16 Mar 2018 12:31:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=uMHq4UOgb/hfYtWgNKs+JhDOe5bvaE8iM9X2ku//1+4=; b=YGoFFBqk8L1pn5S+mBa+/VZqPPi6uTxSEzFDy0E+9wFBu61IX7J9+ZXvVpZtbF9Iub 7Ex+1TRZnM26jGlbjIM3xZJdq4sYQf6SD6LqVy5TS0chpOpoCWK7n8gzdZeFRGr2EeOm mXqVY4SlfaQfHLtdxpdcQYjH5LlWonQHoeihLIfx5ICfUAF7pp6dJ3PUW4z9rhB7D1cO ghQP6h+/MhUb1XNMnlnkOycVQ7hEiDzyuHZDrU9CKg1s28ksgAOk95/i/E+N4E6hOqEt OE+RdKiCSnwR5tOpWLBLL2v6EGyugOzbCjE+/mxqJehcPViHe4w3o471SRNth2Bvr+Dd IVGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=uMHq4UOgb/hfYtWgNKs+JhDOe5bvaE8iM9X2ku//1+4=; b=LEsCCf5ZLgQqGbm7C3TfrmyUZI4Ur1BDP9kg3IH/qFdR8qfiEXlUGpIDr7SZ+p5ods L68k30qq8jSx7TCAyzgVZoRv7sBKQ0ZJmykg1JDF8SSx12vtoM/oDHK+R24HjLEgcd9P mrhTsEsHz2ecDMWJyhkTQXzaWjk/t7cA3qUTbOtffHlhM0BNVjo+nMso5tbFMp+zaRHE HRvo6r1A0ZFcr795zNuWjZtDWQ9VhRCm2T02f324ZMGTIlvRb/3WS+//40CvuiTeN1Xe 1cVKumEOcLmW/+ZiPWbFWw9sdkOvlOlA5K2B021h0POMiX5BgVaQJ8UFcoqB8vlm4GEI YeLw== X-Gm-Message-State: AElRT7FctExg14rueEUaJ7E79X/PMn9FdKMn7hGqkqSxoMT1MG+urMiW 5X2Jh0J8bzmmvKHVSby2SYyZ0Wdgts4FlcKGLRs= X-Google-Smtp-Source: AG47ELvVDnQos6aq82xU9JCoNye6FXV5mCuf2cnHQWxnFLMNQTI6YyHn6dbKSHyzJspGQUTmWLYtftjIe7zBXQZR6gE= X-Received: by 10.46.154.213 with SMTP id p21mr2112335ljj.59.1521228667638; Fri, 16 Mar 2018 12:31:07 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.179.3.226 with HTTP; Fri, 16 Mar 2018 12:31:06 -0700 (PDT) In-Reply-To: <65723.1521226854@critter.freebsd.dk> References: <1521223787.99081.63.camel@freebsd.org> <65723.1521226854@critter.freebsd.dk> From: Alan Somers Date: Fri, 16 Mar 2018 13:31:06 -0600 X-Google-Sender-Auth: WAXh1hiNLUF_vNz0392wI7voWd8 Message-ID: Subject: Re: Is it time to expose timespecsub and friends to userland? To: Poul-Henning Kamp Cc: Ian Lepore , Alan Somers , FreeBSD Hackers , bde@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2018 19:31:09 -0000 On Fri, Mar 16, 2018 at 1:00 PM, Poul-Henning Kamp wrote: > -------- > In message <1521223787.99081.63.camel@freebsd.org>, Ian Lepore writes: > > >IMO, it's long overdue. I've never understood why they weren't exposed > >on the day the were added. > > I have a faint recollection that there were many copies in > userland already which I didn't want to deal with right there and then. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > Good point. A quick grep finds a few examples. I'll make sure to remove them. From owner-freebsd-hackers@freebsd.org Fri Mar 16 19:35:33 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C2488F41FCA for ; Fri, 16 Mar 2018 19:35:33 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4764870DA9 for ; Fri, 16 Mar 2018 19:35:33 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 0e6ad06f-2951-11e8-b951-f99fef315fd9 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id 0e6ad06f-2951-11e8-b951-f99fef315fd9; Fri, 16 Mar 2018 19:34:35 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w2GJZUxZ029473; Fri, 16 Mar 2018 13:35:30 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1521228930.99081.66.camel@freebsd.org> Subject: Re: Is it time to expose timespecsub and friends to userland? From: Ian Lepore To: Alan Somers , Poul-Henning Kamp Cc: FreeBSD Hackers , bde@freebsd.org Date: Fri, 16 Mar 2018 13:35:30 -0600 In-Reply-To: References: <1521223787.99081.63.camel@freebsd.org> <65723.1521226854@critter.freebsd.dk> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2018 19:35:33 -0000 On Fri, 2018-03-16 at 13:31 -0600, Alan Somers wrote: > On Fri, Mar 16, 2018 at 1:00 PM, Poul-Henning Kamp > wrote: > > > > > -------- > > In message <1521223787.99081.63.camel@freebsd.org>, Ian Lepore > > writes: > > > > > > > > IMO, it's long overdue.I've never understood why they weren't > > > exposed > > > on the day the were added. > > I have a faint recollection that there were many copies in > > userland already which I didn't want to deal with right there and > > then. > >[...] > > > Good point.A quick grep finds a few examples.I'll make sure to > remove > them. Hmm, I'll bet there are some ports that also define the obvious names locally and that'll cause problems if we move the names out from under #ifdef __KERNEL. So an exp-run will probably be needed too. -- Ian From owner-freebsd-hackers@freebsd.org Fri Mar 16 19:41:49 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E8CFBF43883 for ; Fri, 16 Mar 2018 19:41:48 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 31FFD71213; Fri, 16 Mar 2018 19:41:47 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from [192.168.0.102] (c110-21-101-228.carlnfd1.nsw.optusnet.com.au [110.21.101.228]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id 5F82E42D588; Sat, 17 Mar 2018 06:41:45 +1100 (AEDT) Date: Sat, 17 Mar 2018 06:41:45 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Alan Somers cc: FreeBSD Hackers , bde@freebsd.org, Poul-Henning Kamp Subject: Re: Is it time to expose timespecsub and friends to userland? In-Reply-To: Message-ID: <20180317042931.N23257@besplex.bde.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=VJytp5HX c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=kj9zAlcOel0A:10 a=4Y-zwQCBEnCh_dXso9oA:9 a=Ncd7HRGRlZGPC89y:21 a=Od9-zSrT0hJy28m1:21 a=CjuIK1q_8ugA:10 X-Mailman-Approved-At: Fri, 16 Mar 2018 20:43:55 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2018 19:41:49 -0000 On Fri, 16 Mar 2018, Alan Somers wrote: > There are at least 19 system calls that have timeout arguments specified as > struct timespec [1]. "struct stat" describes file timestamps as timespecs > as well [2]. setsockopt(2), sched_rr_get_interval(2), > geom_stats_snapshot_timestamp(3) and pmclog_read(3) use timespecs for other > purposes. The sysctl node kern.crypto_stats exposes timespecs. sudo > records timespecs in its timestamp files. Who know how many other ports do > something similar; I'm not going to grep them all. > > And yet, FreeBSD provides no way to manipulate this structure. Every > program that uses them has to roll its own version of pretty much the same > functions. NetBSD does [3], and has for a long time. In fact, NetBSD's > timespecsub is old enough to drink [4]. But in FreeBSD, those functions > languish inside of an "#ifdef KERNEL". phk added them in r35029 with the > comment "XXX: These may change!". But it's been nearly 20 years, so I > don't think they're going to change any more. > > Shall we finally expose them to userland and add a man page? Let the > bikeshed begin! If the flame isn't too bad, I'll do it. These functions fill a much needed gap. POSIX provides the correct number of APIs for manipulating the simple timeval and timespec structs (none). glibc also doesn't support these functions or any others for manipulating these structs, at least in old versions. The easiest way to manipulate timevals in userland was to convert them microseconds in floating point. 53-bit doubles work up to 4.5G seconds = 142 years without losing precision. Unfortunately, this doesn't work for timespecs, since 0.142 years is not enough. However integer types with at least 64 bits have been standard since C99. uint64_t or uintmax_t holds at least 184G seconds = 584 years. sys/time.h is now polluted with other conversion functions: - bintime*() (under __BSD_VISIBLE) - field names like sec and frac in the application namespace. The older timeval and timespec structs are missing the bug of not having prefixes for field names. - sbintime*() and SBT*. Also under __BSD_VISIBLE, but no user APIs use these AFAIK, so they should be under _KERNEL. - sb* and bt* for sbintimes. bt is a better prefix than bintime, but is more likely to conflict with an application name, especially since it is missing an underscore. - us*, ns*, ms* - timespec2bintime() and similar bad names with timespec and bintime spelled out but "to" punned to "2". timespec* might actually the in the namespace reserved for this file, but it is too verbose. - OTOH, there is tstosbt(). I talked someone into not punning "2" in this. But it is hard to read without some underscores, and has larger namespace problems from being shorter. The latter is not a problem if it is kernel- only. Older timespec*() macros are still under _KERNEL, as you noticed. Inlines are correctly not used for the older APIs. This reduces their pollution. Even older timer*() macros are also under _KERNEL. These are marked NetBSD/OpenBSD compatible. These have even worse names -- they are for timevals, not for generic or specific 'timer' structs. There are also problems with arg order and the number of args. timeradd() takes 3 args (tvp, uvp, vvp). timespecadd() takes 2 args in the opposite order (vvp, uvp). It is easier for me to just to the addition than remember the order. Namespace pollution continues after the timespec and timeval macros: mainly: - struct clockinfo; all of its fields are missing prefixes. This is not even under __BSD_VISIBLE. Now looking at only !__BSD_VISIBLE && !_KERNEL code: - earlier there is some nested pollution, struct timezone and its fields which at least have tz_ prefixes, and DST*. - the NetBSD/OpenBSD mistakes are actually under #ifndef _KERNEL, so they pollute userland but not the kernel. The kernel mostly uses non-macro non-inline functions for these. - lots of pollution from the nested include of . The contents of sys/time.h and time.h are still soft of backwards. - explicity pollution from the nested include of . IIRC, POSIX was broken to allow this. The earlier include of sys/types.h already included this nested in the __BSD_VISIBLE case. Example of converting unportable timer*() to floating point: kdump/kdump.c: XX if (timestamp & TIMESTAMP_ELAPSED) { XX if (prevtime_e.tv_sec == 0) XX prevtime_e = kth->ktr_time; XX timersub(&kth->ktr_time, &prevtime_e, &temp); XX printf("%jd.%06ld ", (intmax_t)temp.tv_sec, XX temp.tv_usec); Replace the last 3 lines by: printf("%.6f ", kth->ktr_time.tv_sec - prevtime_e.tv_sec + 1e-6 * (kth->ktr_time.tv_usec - prevtime_e.tv_usec); If this isn't accurate enough, then the calculation in intmax_t arithmetic is needed and messier: intmax_t nsec; nsec = (kth->ktr_time.tv_sec - prevtime_e.tv_sec) * 1000000 + (kth->ktr_time.tv_usec - prevtime_e.tv_usec); printf("%jd.%06jd ", nsec / 1000000, usec % 1000000); (Actually even messier if nsec can be < 0 -- see below). XX } XX if (timestamp & TIMESTAMP_RELATIVE) { XX if (prevtime.tv_sec == 0) XX prevtime = kth->ktr_time; XX if (timercmp(&kth->ktr_time, &prevtime, <)) { XX timersub(&prevtime, &kth->ktr_time, &temp); XX sign = "-"; XX } else { XX timersub(&kth->ktr_time, &prevtime, &temp); XX sign = ""; XX } XX prevtime = kth->ktr_time; XX printf("%s%jd.%06ld ", sign, (intmax_t)temp.tv_sec, XX temp.tv_usec); These complications are to avoid misprinting for example a timeval of { tv_sec = -2; tv_nsec = 999999; } as -2.999999. It is actually -(1.000001). timersub() is foot-shooting to give an unwanted representation. Simply calculating the difference in floating point works the same as before. Even C's broken division works right for this case (division should round the integer part down, giving the same problem as for timevals, but its brokenness is that it rounds towards 0). XX } The cases where using timer*() is not just worst are when you have to convert a value in usec back to a timeval. Then an extra conversion step is necessary. Something like: struct timeval finish, prev, resid; ... timersub(&finish, &prev, &resid); /* Should have error handling for resid here. */ select(..., &resid); which would be converted to: usec = (finish.tv_sec - prev.tv_sec) * (intmax_t)1000000 + (finish.tv_usec - prev.tv_usec); /* Error checks like usec >= 0 are easier with a single number. */ /* Extra conversion: */ resid.tv_sec = usec / 1000000; resid.tv_usec = usec % 1000000; select(..., &resid); Note that if usec < 0, C's broken division by negative numbers usually gives an invalid timeval with tv_usec < 0, so the error checking is more needed. This the reverse of the problem for printing negative timevals. Negative timeouts should be treated as 0, but invalid negative timeouts should be errors. sbintimes are essentially optimized versions of representing everything in nsec, with minimal conversions to struct types. Unfortunately all of the standard time APIs except difftime() use struct types. Bruce From owner-freebsd-hackers@freebsd.org Fri Mar 16 21:44:47 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A8AA0F502DB for ; Fri, 16 Mar 2018 21:44:47 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 58F6C76891; Fri, 16 Mar 2018 21:44:46 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id A196820B3B; Fri, 16 Mar 2018 17:44:46 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute3.internal (MEProxy); Fri, 16 Mar 2018 17:44:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=ik4i0x 1C/lpG3Z6ubvZmDkz2WO+zvKXaEpNkwT8snDA=; b=UU95+csobKGKm2S+3T41Tr kXCxbUPN/Puq8QF36+KchAX+36ahhg1gIJoJWLAgmMWRpbR2xl5qwaH9UgwQ0ZwP wvPMdJgaoE2YtEp4toSlzpGZbCVyTglgPTK+VDv5ragEVXRXFZ8ix+yYVKykgTeA iHVr5wrmZLdC94gQ4eZb9qqONn7mDpKWVEAtMvlopved1aoskrP7xYmnh+COobaN WbY0klz+sjualr9gH4ZKT2kE043cYNZWq5+uq65q5xUU1NGB5mskjI0RyL8VqmVL hqO+3PkRo7/0OK83iT8iy7nLKhFk0Zdtz8z3S+XVAo4kR1DupZfafY2IKn0tHutg == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 80AE4BA1AE; Fri, 16 Mar 2018 17:44:46 -0400 (EDT) Message-Id: <1521236686.3747283.1305998104.4B75D739@webmail.messagingengine.com> From: Mark Felder To: Ian Lepore , Patrick Kelsey , freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-b3834dbb Date: Fri, 16 Mar 2018 16:44:46 -0500 References: <1521062028.2511351.1303413736.6960BF4F@webmail.messagingengine.com> <20180314233811.GA35025@mail.bsd4all.net> <1521216713.99081.55.camel@freebsd.org> Subject: Re: option TCP_RFC7413 is not in GENERIC In-Reply-To: <1521216713.99081.55.camel@freebsd.org> X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2018 21:44:47 -0000 On Fri, Mar 16, 2018, at 11:11, Ian Lepore wrote: > On Fri, 2018-03-16 at 16:04 +0000, Patrick Kelsey wrote: > > The current thinking is that users who care > > about such performance differences are dealing with extreme workloads t= hat > > already motivate them to compile their own kernels, or are working with > > very resource-constrained platforms, so the way forward is to keep the > > TCP_RFC7413 kernel option around and enable it by default for the > > server-class platforms (armd64 and arm64). >=20 > I have no idea what TCP_RFC7413 even is, but I know I was forced to add > it to my kernel config when I installed the bind911 package during a > recent upgrade. =C2=A0This is on a tiny NUC for which saturating even one= of > its gbe interfaces would count as "extreme workload". :) >=20 Funny, BIND911 is what sent me down this rabbit hole as well. Thanks for the feedback and information, all! Look forward to these improve= ments :-) --=20 Mark Felder ports-secteam & portmgr member feld@FreeBSD.org From owner-freebsd-hackers@freebsd.org Fri Mar 16 21:00:26 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 59A26F4D3B8 for ; Fri, 16 Mar 2018 21:00:26 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail108.syd.optusnet.com.au (mail108.syd.optusnet.com.au [211.29.132.59]) by mx1.freebsd.org (Postfix) with ESMTP id 8DD28741DF; Fri, 16 Mar 2018 21:00:24 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from [192.168.0.102] (c110-21-101-228.carlnfd1.nsw.optusnet.com.au [110.21.101.228]) by mail108.syd.optusnet.com.au (Postfix) with ESMTPS id 3DCEB1A694D; Sat, 17 Mar 2018 07:30:44 +1100 (AEDT) Date: Sat, 17 Mar 2018 07:30:43 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Ian Lepore cc: Alan Somers , Poul-Henning Kamp , FreeBSD Hackers , bde@freebsd.org Subject: Re: Is it time to expose timespecsub and friends to userland? In-Reply-To: <1521228930.99081.66.camel@freebsd.org> Message-ID: <20180317070040.X23799@besplex.bde.org> References: <1521223787.99081.63.camel@freebsd.org> <65723.1521226854@critter.freebsd.dk> <1521228930.99081.66.camel@freebsd.org> MIME-Version: 1.0 X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=FNpr/6gs c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=nlC_4_pT8q9DhB4Ho9EA:9 a=6I5d2MoRAAAA:8 a=lKypuvrlE3pYhWAQYfsA:9 a=45ClL6m2LaAA:10 a=IjZwj45LgO3ly-622nXo:22 X-Mailman-Approved-At: Fri, 16 Mar 2018 21:58:53 +0000 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2018 21:00:26 -0000 On Fri, 16 Mar 2018, Ian Lepore wrote: > On Fri, 2018-03-16 at 13:31 -0600, Alan Somers wrote: >> On Fri, Mar 16, 2018 at 1:00 PM, Poul-Henning Kamp >> wrote: >> >>> >>> -------- >>> In message <1521223787.99081.63.camel@freebsd.org>, Ian Lepore >>> writes: >>> >>>> >>>> IMO, it's long overdue.=A0=A0I've never understood why they weren't >>>> exposed >>>> on the day the were added. >>> I have a faint recollection that there were many copies in >>> userland already which I didn't want to deal with right there and >>> then. >>> =A0[...] >>> >> Good point.=A0=A0A quick grep finds a few examples.=A0=A0I'll make sure = to >> remove >> them. > > Hmm, I'll bet there are some ports that also define the obvious names > locally and that'll cause problems if we move the names out from under > #ifdef __KERNEL. =A0So an exp-run will probably be needed too. The bug of these APIs existing is only clearly in NetBSD, OpenBSD and Oracle. For Linux and glibc, google reports that as late as 2011, users are confused by timersub() not existing except possibly under a BSDSRC ifdef. FreeBSD should continue to avoid this bug for timespec*(). FreeBSD's timespec*(9) APIs are fully incompatible with NetBSD, OpenBSD and Oracle timespec*(3) APIs. The latter have 3 args with the target last, like the timeval*(3) APIs, but timespec*(9) still has 2 args with the target first. The incompability might be intentional, to keep the APIs out of userland, but more likely it is just to have the same number of args and order as the old timeval*(9) APIs. These are better designed than timer*(), except they take only 2 args. Their args are in the correct order, with the target first, and their name is not too generic. timespec*(9) copies these APIs except for s/timeval/timespec/. NetBSD's timer*(3) might have a different though worse name to since their different args make them very different. This difference would reduce conflicts with application APIs. However, for timespec*(), using the same name increases conflicts with application APIs. The special reserved symbols in sys/time.h in old versions of POSIX were just ones with prefix tv_, it_ and a few more from sys/select.h. Not timespec* or timeval*. So it is very reasonable for applications to name their own APIs timespec*. Using the system's pollution is just harder -- it needs autoconfig or something to use it when it exists, and possibly macros to convert between 2-arg and 3-arg forms, and also private APIs to use when the system headers are not polluted. Bruce From owner-freebsd-hackers@freebsd.org Sat Mar 17 17:46:23 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EFE97F5BE6A for ; Sat, 17 Mar 2018 17:46:22 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 717CE8677C; Sat, 17 Mar 2018 17:46:21 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id w2HHcFTI052028 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 17 Mar 2018 10:38:15 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id w2HHcF96052027; Sat, 17 Mar 2018 10:38:15 -0700 (PDT) (envelope-from jmg) Date: Sat, 17 Mar 2018 10:38:15 -0700 From: John-Mark Gurney To: Eitan Adler Cc: John Baldwin , FreeBSD Hackers Subject: Re: gf128_add can be marked as __pure2 Message-ID: <20180317173815.GM75576@funkthat.com> Mail-Followup-To: Eitan Adler , John Baldwin , FreeBSD Hackers References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.0-RELEASE-p7 amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Sat, 17 Mar 2018 10:38:16 -0700 (PDT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2018 17:46:23 -0000 Eitan Adler wrote this message on Mon, Feb 19, 2018 at 19:15 -0800: > Is there any reason not to apply this patch? I don't see why there wouldn't be.. > __pure2 means __attribute__((const)) which is correct in this case as > gf128_add read no global memory: Are these documented some where? Looksl ike __pure2 was created instead of using __pure for some reason... I wish these things were documented properly so others could know the correct usage... > Index: gfmult.h > =================================================================== > --- gfmult.h (revision 329611) > +++ gfmult.h (working copy) > @@ -108,7 +108,7 @@ gf128_write(struct gf128 v, uint8_t *buf) > be64enc(buf, v.v[1]); > } > > -static inline struct gf128 __pure /* XXX - __pure2 instead */ > +static inline struct gf128 __pure2 > gf128_add(struct gf128 a, struct gf128 b) > { > a.v[0] ^= b.v[0]; -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@freebsd.org Sat Mar 17 18:39:01 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2CBB4F5F830 for ; Sat, 17 Mar 2018 18:39:01 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B87D968F16 for ; Sat, 17 Mar 2018 18:39:00 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mail-yw0-x22c.google.com with SMTP id y203so9095482ywg.5 for ; Sat, 17 Mar 2018 11:39:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=R7X7stRJ0nRP7RJMh7y/TypjYiKbQG/AMS8UZznRff0=; b=fRAi2no3mRJYztAZ15JCGAf4sSr52r+Ovj4koUEfr34hRVzUKiIv6Ukpl/Mch8pbkL pNA2nGndOaEov3Zl0jWUKbpwwdaqnO9OJPx3CI1m31b7xPYX6j3R6UV0VqdUCQh6osGg CgwaZcTg4RPzP1iNJWHPBoepxmeohLj0w5D9Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=R7X7stRJ0nRP7RJMh7y/TypjYiKbQG/AMS8UZznRff0=; b=kh6hC0NCJYycdhVzkKR3GP/H0msMri4QRM5RLGYKh1kbgjCvSA2RxLjuy5K1/Jcjdb 5laZN5+1BVp1leo8VnX1xTlFZfFU4GuSKQSaH+TQPm6bAVozmdTvRHIwr4sYsuZ5iUiC 0+7IX7WY7yiZw+Z2ijzoYcj7/xATpKwkFBijv2QrPOb3AaibbYaMLtYEdkAvGfJF4u/y XCgWSiBUAmc29VLe6cznZmQeTuW0gzEo+xPFZzOmd/WhE8rl12uWA+CMEpQhnKL49Hrh 4ExW3nhPYzc9Rs70jwNcd1/TcDr9lZIYuWRI0GqbdMFwoAvdLzbq+malQ2mnvjKd+iKi JLtA== X-Gm-Message-State: AElRT7GbDncuYnsoG8mK1eF90o61SPfJYXVDe4AbKYvOsYuuLOa+hC7F Z6uqC3EpoysowyLUzf4GKnM1MS6hKNK8n5FbOn2pFp0J X-Google-Smtp-Source: AG47ELunc9nNHqHm0ts8qMzmZ/51v/L6lSrS7EBrvLh+6YkUWULd6kaBEH+kOzF42RIblW/sI2W4gUGyE8/PGYqLq8M= X-Received: by 10.129.114.6 with SMTP id n6mr38932ywc.113.1521311940017; Sat, 17 Mar 2018 11:39:00 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:23d2:0:0:0:0:0 with HTTP; Sat, 17 Mar 2018 11:38:29 -0700 (PDT) In-Reply-To: <20180317173815.GM75576@funkthat.com> References: <20180317173815.GM75576@funkthat.com> From: Eitan Adler Date: Sat, 17 Mar 2018 11:38:29 -0700 Message-ID: Subject: Re: gf128_add can be marked as __pure2 To: Eitan Adler , John Baldwin , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2018 18:39:01 -0000 On 17 March 2018 at 10:38, John-Mark Gurney wrote: > Eitan Adler wrote this message on Mon, Feb 19, 2018 at 19:15 -0800: >> Is there any reason not to apply this patch? > > I don't see why there wouldn't be.. > >> __pure2 means __attribute__((const)) which is correct in this case as >> gf128_add read no global memory: > > Are these documented some where? Looksl ike __pure2 was created instead > of using __pure for some reason... I wish these things were documented > properly so others could know the correct usage... I don't know where the FreeBSD macros are documented (they are implementedi cdefs.h). https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes documents the attributes __pure2 is const __pure is pure -- Eitan Adler