From owner-freebsd-hackers@freebsd.org Sun Oct 22 21:57:44 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 09564E37484 for ; Sun, 22 Oct 2017 21:57:44 +0000 (UTC) (envelope-from zbeeble@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 8D79F76645; Sun, 22 Oct 2017 21:57:43 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: by mail-wm0-x231.google.com with SMTP id m72so6194000wmc.1; Sun, 22 Oct 2017 14:57:43 -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=dHuxmpyKev+x0nIKqDNnlA2BtNs0jjSyAE9rRxH9FuQ=; b=DzeL34/YsneNQqzKDXX07N7uIuN9rfHP2ut42Bcby0XdMQFp9gKxekVr2xoX1Ikd9M +/UigKCpyhVyZFGMkW4ErHajdwKwxj3CrxYhCbwKu4WzEx7XJ/QVrciLbrntiG/vOqBu vZAX2yGIJ6bqRYH2TZlYuvM8jVeHG7K6Oa/n0mjfHYDrqgBkyvNJEIU1+v04MftkiWos 5EZ3Qf6Yla0WAgKpM5Ys4BV5My9ctF1n3wfgPsTGh2AROF6sHnC7r8UzY6I5wx9vKcJI o3M9BSfnE8cV1IfxGkKTp59tbQABWs10+WjW+vi9dPdMEknxqI64zmmJuB29GI1HtH8e Am3g== 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=dHuxmpyKev+x0nIKqDNnlA2BtNs0jjSyAE9rRxH9FuQ=; b=J/lHzzddsbFwDvmGj8v8i4xpKgAqpMz8iHAp/bCaJjn0GEZIadG9E1rImv+WrZXDJ5 O7APJfNkM1ANpB9MoERGq9BbGgDnCG+xVD0Xj7xsaUXkJZnFOZRW8P4Usitalcd2kB6M epeTcoJPXe01RxJrBIBlpVnEwrGObe++YbNCTu9M7mkp9+8DK7c2Fah6CcuvHiF4rZHy obEn69xrOSPloxEjJJG7z47pnTLVV5AyXHzqfjLScfpDxXgO5/c50+TK0Mh/LiyvJKtA osE62U2xz4SBbKJ0zZBi9k2jSbGOZqRHqURzBmdDfVRJlgNMlwKgs2QJEYPSW7mSkIPd lsUA== X-Gm-Message-State: AMCzsaX10XoL+5+Ul5f97LC6vc3CONbk9uRFtXC+6CWyUlU6sACkqd4j DTbcMBdyBO8gyWFoxOCjXRAo7N07OUoAxC53vA== X-Google-Smtp-Source: ABhQp+R2b6Scm2mQiUkOs43fM/a39KN9T+PA+qe/KWMQ8s8y70hhrIo2va468cCG/e6yXEIx1rR9IBDBOuMLvTMVUD8= X-Received: by 10.80.139.65 with SMTP id l59mr14460945edl.187.1508709461199; Sun, 22 Oct 2017 14:57:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.189.139 with HTTP; Sun, 22 Oct 2017 14:57:40 -0700 (PDT) In-Reply-To: <1508611656.1383.100.camel@freebsd.org> References: <1508425713.1383.6.camel@freebsd.org> <1508432312.1383.18.camel@freebsd.org> <20171019172246.GU2473@kib.kiev.ua> <1508511786.1383.50.camel@freebsd.org> <1508611656.1383.100.camel@freebsd.org> From: Zaphod Beeblebrox Date: Sun, 22 Oct 2017 17:57:40 -0400 Message-ID: Subject: Re: We do serial differently. To: Ian Lepore Cc: Kyle Evans , Konstantin Belousov , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2017 21:57:44 -0000 Firstly, this is an excellent and awesome summary of behavior. Would that we could turn it into some form of change proposal. But: here's my little state diagram: linux: arduino works, pronterface works FreeBSD:arduino works, pronterface fails arduino is a big pile of java, but it successfully talks to the arduino. Maybe in a different mode? I dunno... but it works on both OSs. pronterface is a big pile of python. It works on linux and doesn't work on FreeBSD. Now... the one possible point was that cutting the arduino's DTR trace might make it work on FreeBSD (with the proviso that using arduino would require pressing the reset switch on the hardware). Can these facts be put together in a manner that makes pronterface work on FreeBSD without the hardware hack. In particular, the "driver" for the arduino's USB serial emulation is a separate driver that we can hack. On Sat, Oct 21, 2017 at 2:47 PM, Ian Lepore wrote: > > First, a word about DTR being asserted vs. de-asserted... > > RS232 signals are inverted from the corresponding UART signals. That is, > when the DTR signal is 0 at the output of a uart chip, it runs through an > RS232 line-level converter which inverts the signal to a 1 on the RS232 > output side. Often with embedded system stuff there is no RS232 > conversion, the signals remain at uart levels on both ends. In this case, > "DTR asserted" means 0v on the DTR pin of the uart chips. > > Okay, after some digging, here's what I've found about how freebsd > behaves with DTR... > > On first open(), DTR is asserted. There is no control over that, it's > just always going to happen. (Slightly buggy: multiple serial drivers > do this, and the tty layer does it too. I think only the tty layer > should do it.) > > On last close(), DTR is de-asserted unless -hupcl has been set. This > seems to be done ONLY in various drivers, and not be the tty layer, > which seems differently-buggy than the open-assertion case. Maybe > there is a reason the tty layer can't do this, I didn't dig into it. > > If you set both /dev/cuaU#.init and /dev/cuaU#.lock to -hupcl, that > will ensure that once the device is opened for the first time, DTR will > remain asserted forever after that. (setting .lock prevents any > program from changing that setting.) > > There is no way to prevent DTR from ever being asserted. > > Things I've read about linux while searching for info on this seem to > indicate it behaves the same way (but it lacks the .init and .lock > features). Apparently only on Windows is it possible to configure > serial drivers to leave the DTR line completely untouched. > From owner-freebsd-hackers@freebsd.org Sun Oct 22 22:14:45 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9C3FBE37B81; Sun, 22 Oct 2017 22:14:45 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 7967E770EB; Sun, 22 Oct 2017 22:14:45 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id CD4FE2D07; Sun, 22 Oct 2017 22:14:40 +0000 (UTC) To: "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org, freebsd-arch@freebsd.org From: Eric McCorkle Subject: Trust system write-up Message-ID: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.net> Date: Sun, 22 Oct 2017 18:14:40 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2017 22:14:45 -0000 Hello everyone, The following is a write-up of my current design for a public-key trust system: https://www.metricspace.net/files/freebsd_trust.pdf Some of you are certainly familiar with some or all of this; I've discussed parts of it before on -hackers and -security, and I discussed it in greater detail in BoF sessions at vBSDCon. It seems things are heating up in this direction, so I'd like to get this out there and get discussion and feedback. I plan on undertaking work on this in the very near future, especially since the commit-train for GELI EFI is ready to arrive in HEAD. A bit about the format: this is sort of the "meat" of what I hope will be a paper some day, but it's still an initial draft. Moreover, it talks about things I'm planning as if they exist, mainly because I don't want to have to go back and rewrite everything in the future. In reality, most of what I talk about is just a proposal at this point, with a few bits being implemented as a PoC here and there. Please read and consider the designs I've proposed. I welcome any feedback and suggestions. I'll give it a week minimum from today before I resume any work on this stuff. Note: Apologies for the external link; I had originally included this as an attachment, but it was too large. From owner-freebsd-hackers@freebsd.org Sun Oct 22 22:31:42 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 82E9EE3833E for ; Sun, 22 Oct 2017 22:31:42 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::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 4413B779FB for ; Sun, 22 Oct 2017 22:31:42 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qt0-x229.google.com with SMTP id h4so24091144qtk.8 for ; Sun, 22 Oct 2017 15:31:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=bSyhe9uYPpe7TOlfCzaPDkrNgbYDdmbbs/LdFqmQ8Sk=; b=e4hbPJ7fOT9GE8X35njVH+ahYhtbSVCkhIY6nkC03CXws/BCRJ0T+RD7nMBS5RIzfo yUBzc39yerQu5Ym95YRwcku9uBRYcv1FN5/j34xxnNmsRvGq3oqvnotANbabplzNdVot jpNH5yojNwwpT7YLAfNP42rJqekWPB0AZ3j6bLLs2Lr2t0Gsqr9SoX2oMyOWwueLh11U JwrGW/Pji8namtmd45JT3j6O8OSwO1tv7IbxPXfltPKXI9nM5PENPZKQCrO/YSNFP7et os1LAIvQ1P+Bv2iscfMRf6LY9FClCRYzY9GDMGMrUEUffauMXbT2jgWAdlh21tvQR4qx Ggcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=bSyhe9uYPpe7TOlfCzaPDkrNgbYDdmbbs/LdFqmQ8Sk=; b=jAOoGaC84pUJIKbdmcqnrIzOq8C9zFT+tUgKIq0GUp3MElgacxLF5TLK1Jd9abXy18 KAJj64BjDFY/Eq3qLZfMrDbatMvHZ/u4vVaRglnIoc9ZIZn0ZnNnfgP2wMUg/7vR0kRj 6PmiCyBH/vmRQ3rZv33hhj3KZrXDE+vSLRqz4lIlDjw3k0JGDn5JKP5DxejZGL80qNiI IzdyL1LXYRXcRNtkLtHBOx2e6UVJdXnfJr00aET7YDEgYPoSfbz/T6sJ4CBq27hZ+ThW IAICG1XuJh3wsY9Wv2cFu5LGk6xoxDr0LcyIfIEkyEmG1AJfnrkiS9drMWeOYVLqaCx4 JCFQ== X-Gm-Message-State: AMCzsaXfJPv1KYgn/vS2HzkeoteEG+udapKmLG3xnlyNZa4nOubHC3sS S5rAWBsEr8y2g3U7QH82E2KhkA== X-Google-Smtp-Source: ABhQp+RxR23Uchv3/7x9v7yj6V5tlmfgNjACTmSN6H/nMM6RJbSZb/DKulUrNfLsO5q+gQVJTJTdPw== X-Received: by 10.237.42.230 with SMTP id t93mr17709929qtd.317.1508711501122; Sun, 22 Oct 2017 15:31:41 -0700 (PDT) Received: from mutt-hbsd (pool-100-16-230-154.bltmmd.fios.verizon.net. [100.16.230.154]) by smtp.gmail.com with ESMTPSA id k79sm3809705qke.28.2017.10.22.15.31.40 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 22 Oct 2017 15:31:40 -0700 (PDT) Date: Sun, 22 Oct 2017 18:31:33 -0400 From: Shawn Webb To: Eric McCorkle Cc: "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Trust system write-up Message-ID: <20171022223133.nkcpkhtl7s7kzgs5@mutt-hbsd> References: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="zanh2tn2izgbdqkn" Content-Disposition: inline In-Reply-To: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.net> X-Operating-System: FreeBSD mutt-hbsd 12.0-CURRENT FreeBSD 12.0-CURRENT X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20170912 (1.9.0) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2017 22:31:42 -0000 --zanh2tn2izgbdqkn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 22, 2017 at 10:14:40PM +0000, Eric McCorkle wrote: > Hello everyone, >=20 > The following is a write-up of my current design for a public-key trust > system: >=20 > https://www.metricspace.net/files/freebsd_trust.pdf >=20 > Some of you are certainly familiar with some or all of this; > I've discussed parts of it before on -hackers and -security, and I > discussed it in greater detail in BoF sessions at vBSDCon. It seems > things are heating up in this direction, so I'd like to get this out > there and get discussion and feedback. >=20 > I plan on undertaking work on this in the very near future, especially > since the commit-train for GELI EFI is ready to arrive in HEAD. >=20 > A bit about the format: this is sort of the "meat" of what I hope will > be a paper some day, but it's still an initial draft. Moreover, it > talks about things I'm planning as if they exist, mainly because I don't > want to have to go back and rewrite everything in the future. In > reality, most of what I talk about is just a proposal at this point, > with a few bits being implemented as a PoC here and there. >=20 > Please read and consider the designs I've proposed. I welcome any > feedback and suggestions. I'll give it a week minimum from today before > I resume any work on this stuff. Hey Eric, Thank you so much for working on this. I do have a few questions. I'm curious about the rational behind not requiring expiration of trusted root key material. Can jails contain a different trust chain than the host? Thanks, --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --zanh2tn2izgbdqkn Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAlntHEIACgkQaoRlj1JF bu585g//SLA5OM7zRX/0SziOYf5ref5HARdM9T0BjmEejcLGA9ZgcwH3i0krPJXY IznjVMVlIpXcqUA5CYrNjSaaxs1h2TIS/wxVrhPrtpM8NOezZNxOT0fm8IaG624h V1E0YO+TYn2Iy3yBrzAJI+kFnJ998cvTauapAWxtvpo3AJUfDI/Lx02yEbq21U+J JJV5vvYE029on0irPWepCJdRz9hiwUCI/f9t3yXlJLae01RgJObwpU+SXgtGOx43 e/HO/za/EEgDmB7njSUyw0sw4QWm7F1VXhemClP9jq7C+yedIkExJFfE6VynRDta crR9StOctmkdnf4M/48NGmGUndRBLDrwf0b6+gmSuZTrzP4WOkYMK5bJYJPA2xx5 DbRCOpqIc+Jvr+Qfnr2mXnUKmjM+WWo/FCx/pc7eFMaNyFQpSBpBptO/syuOTvJU MAmCBdreT56Tz1uce7JH6Q3sOQ3C3HLFn4kB1F5l4kTskiZSMOykFEUmgEfz75kF gnXCT/dJVfsYQCbGeQlU2+wCK1tt03p+4pcSyCK7cMdSd7RCjrt7H2G44UGet+lH fH3Q0FuCxfD8TuLaG5az8NpdrAB24cPPM8wghyunqDllNqb19731d6fK4+EJBmbF OOniNXf0EA3CalTN1dtRluABHZyxWidZKudUot77xJ1jqlPLDKM= =vbis -----END PGP SIGNATURE----- --zanh2tn2izgbdqkn-- From owner-freebsd-hackers@freebsd.org Sun Oct 22 23:21:11 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 010C3E3979C; Sun, 22 Oct 2017 23:21:11 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id CE34D7D9D7; Sun, 22 Oct 2017 23:21:10 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 9DA2D2D2D; Sun, 22 Oct 2017 23:21:09 +0000 (UTC) Subject: Re: Trust system write-up To: Shawn Webb Cc: "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org, freebsd-arch@freebsd.org References: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.net> <20171022223133.nkcpkhtl7s7kzgs5@mutt-hbsd> From: Eric McCorkle Message-ID: <96ff2a56-5089-eb4e-cf57-6c6d2cb4667e@metricspace.net> Date: Sun, 22 Oct 2017 19:21:09 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171022223133.nkcpkhtl7s7kzgs5@mutt-hbsd> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2017 23:21:11 -0000 Accidentally replied to -arch only, re-replying to all lists On 10/22/2017 18:31, Shawn Webb wrote: > I'm curious about the rational behind not requiring expiration of > trusted root key material. > So, I'd say consider most of this written in pencil at this point (minus the signed ELF extension; I think that's a particularly good point in design space). My thinking on root keys is that there really ought to only be one for a given system, but I'm not so convinced of that that I'd bake it into the spec. Certainly, though, you need at least one good root key to stay operational. If you have expiring root keys, you get into all sorts of nasty cases where your last root key expires, forcing the system down, or a system can't be booted because its root keys all expired. And expiring root keys + can't add more root keys means every system effectively has a countdown to running out of root keys. I didn't mention it, but I could see provisions for adding/revoking root keys that hook into some sort of deeper hardware mechanism, say TPMs. I think that's out-of-scope for now, but it's worth thinking about. Perhaps expiring root keys could be added along with a mechanism like this. > Can jails contain a different trust chain than the host? I hadn't really folded jails into this yet, but I'd say that's a definite requirement. It kind of kills the whole virtualization capability of jails if you can't do that. I'd say you'd probably want jails to have the option to inherit their parent's trust DB, as well as establish their own root keys. From owner-freebsd-hackers@freebsd.org Mon Oct 23 07:11:27 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CDA9CE42CB3; Mon, 23 Oct 2017 07:11:27 +0000 (UTC) (envelope-from romain@blogreen.org) Received: from marvin.blogreen.org (blogreen.org [151.127.25.53]) by mx1.freebsd.org (Postfix) with ESMTP id 7A5F864CBC; Mon, 23 Oct 2017 07:11:26 +0000 (UTC) (envelope-from romain@blogreen.org) Received: by marvin.blogreen.org (Postfix, from userid 1001) id 7A2A2A6DAD; Mon, 23 Oct 2017 09:11:20 +0200 (CEST) Date: Mon, 23 Oct 2017 09:11:20 +0200 From: Romain =?iso-8859-1?Q?Tarti=E8re?= To: freebsd-security@freebsd.org, "freebsd-hackers@freebsd.org" , freebsd-arch@freebsd.org Subject: Re: Trust system write-up Message-ID: <20171023071120.GA72383@blogreen.org> Mail-Followup-To: freebsd-security@freebsd.org, "freebsd-hackers@freebsd.org" , freebsd-arch@freebsd.org References: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="PEIAKu/WMn1b1Hv9" Content-Disposition: inline In-Reply-To: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.net> X-PGP-Key: http://romain.blogreen.org/pubkey.asc User-Agent: Mutt/1.9.1 (2017-09-22) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 07:11:27 -0000 --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Eric, On Sun, Oct 22, 2017 at 06:14:40PM -0400, Eric McCorkle wrote: > The following is a write-up of my current design for a public-key trust > system: >=20 > https://www.metricspace.net/files/freebsd_trust.pdf Two minor things while reading: 1. p2: from a end-user perspective, `trustctl` expects DER encoded certificates and CRL; while `certs` and `rootcerts` outputs PEM encoded certificates=E2=80=A6 So the formats are not the same, and may= be consistency would be advisable here; 2. p3: 'the preferred configuration' is said to be the most used one, but as described it only includes a single crt+key and does not look suitable for distributing upgrades with freebsd-update(8). Unless I missed something, I guess it's just the way it is described that needs disambiguation: - "local nodes" are basically what is described as "Preferred configuration", and have a single key+crt. So these nodes can only run the code they signed. - "high-security institutions" are kept as it, that is a single crt; So these nodes can only run code signed by the institution. Hybrid systems can be built by having more than one root node: - "preferred configuration" have a local key+crt (as an local node) AND the FreeBSD's project crt. So these nodes can run FreeBSD's code and their own code. - "standard FreeBSD images" as described have the FreeBSD's project crt. When installing, they generates a local key+crt and add them with the FreeBSD crt to the new system's trust store. So these images have the "high-security institutions" scheme, and install systems in the "preferred configuration" scheme. Thanks! Romain --=20 Romain Tarti=C3=A8re http://people.FreeBSD.org/~romai= n/ pgp: 8234 9A78 E7C0 B807 0B59 80FF BA4D 1D95 5112 336F (ID: 0x5112336F) (plain text =3Dnon-HTML=3D PGP/GPG encrypted/signed e-mail much appreciated) --PEIAKu/WMn1b1Hv9 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAEBCAAdFiEEgjSaeOfAuAcLWYD/uk0dlVESM28FAlntlhUACgkQuk0dlVES M28IUAwAkC1TcnDuhF67t+1RbvZL5oTxtDBQjzzOTiIhX+W/Q8oZDMPGa2xpAyPP BxPX8oCbLLsWCP/FkVmMzxHz0zNSFTMQSPCzLfkhPUZzVNlG6XcF211U97umofQf ij2pvazZXLYcaH6sFkVbpjIGqoLehCgCnU87imD/stB8v1bpmr8qTOrNG0qVH5BF pWFa1rnRCouY6YRvyNxwmzW/tNbEeFqJ07t8vDSjG48bF7jbSezM/SLzmettl9Fi EFGs1GTLtqAVLX3XomajDGd+N76xAq6WEL+g5ys2Rm31BJoj3JcfREoHzEzSGiEW LaTJllt2r5Bz3EMPKGqf6i/fd8YiyJfSn/FUrpdO4iWHnYPEqBCVQ74ran/l3trX OYlFTyjwbG0/ocTxO1ZQ3wmdQ06dor41PiL6Rylis2ZZNxXI0IzjjK667Bs0LxHm +cBsCGDnmgcAhRPy7pgeXpfEd/w3VZY3mIB3kGYpYXQ8a5aJiqv7Pq5JEt/xndqM rPX0N+/z =ihHe -----END PGP SIGNATURE----- --PEIAKu/WMn1b1Hv9-- From owner-freebsd-hackers@freebsd.org Mon Oct 23 11:56:35 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A1B2FE49424; Mon, 23 Oct 2017 11:56:35 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 701E66D98F; Mon, 23 Oct 2017 11:56:35 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id A2E352E4F; Mon, 23 Oct 2017 11:56:33 +0000 (UTC) Subject: Re: Trust system write-up To: freebsd-arch@freebsd.org, freebsd-arch@freebsd.org, "freebsd-hackers@freebsd.org" References: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.net> <20171023071120.GA72383@blogreen.org> From: Eric McCorkle Message-ID: Date: Mon, 23 Oct 2017 07:56:33 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171023071120.GA72383@blogreen.org> 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.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 11:56:35 -0000 On 10/23/2017 03:11, Romain Tartière wrote: > Hello Eric, > > On Sun, Oct 22, 2017 at 06:14:40PM -0400, Eric McCorkle wrote: >> The following is a write-up of my current design for a public-key trust >> system: >> >> https://www.metricspace.net/files/freebsd_trust.pdf > > Two minor things while reading: > 1. p2: from a end-user perspective, `trustctl` expects DER encoded > certificates and CRL; while `certs` and `rootcerts` outputs PEM > encoded certificates… So the formats are not the same, and maybe > consistency would be advisable here; There's a reason for that. The binary DER encoding is very easy to parse, and is far less likely to end up with vulnerabilities. Prior to learning about the discussion surrounding BearSSL, I had been working on a minimal PKI implementation which only parsed binary DER because it confers a number of advantages. Each element has a length, so it's easy to detect malicious or bad data and avoid overruns. Also, you can easily skip over data you don't need (such as the complex distinguished name structures), and since it's a distinguished encoding, you can treat any element as an opaque byte pointer for comparison purposes. All this closes off a number of attack vectors. PEM encoding is what applications use, and it's much easier to generate than to parse. Generating it is straightforward if you have the DER-encoded data lying around, whereas parsing introduces a number of possible errors. > 2. p3: 'the preferred configuration' is said to be the most used one, > but as described it only includes a single crt+key and does not look > suitable for distributing upgrades with freebsd-update(8). > Unless I missed something, I guess it's just the way it is described > that needs disambiguation: The idea is that you'd sign FreeBSD's vendor certificate with the local system key and add this to your intermediate certificates that get loaded at boot time. The installer would probably generate a local keypair, install it as a root trust certificate, then sign the FreeBSD vendor certificate and install it as an intermediate trust certificate. This would be enough to get an initial system up and running. Users that don't want to trust the FreeBSD cert could then do a buildworld and delete the signed FreeBSD cert from the intermediate certificate store. > Hybrid systems can be built by having more than one root node: > - "preferred configuration" have a local key+crt (as an local node) > AND the FreeBSD's project crt. > So these nodes can run FreeBSD's code and their own code. > - "standard FreeBSD images" as described have the FreeBSD's project > crt. When installing, they generates a local key+crt and add them > with the FreeBSD crt to the new system's trust store. So these > images have the "high-security institutions" scheme, and install > systems in the "preferred configuration" scheme. That is also an option; however, I prefer the configuration where only the local system key is a root and everything else is an intermediate, as each root key represents a source of trust that is hard to revoke (you have to power-cycle). It's almost always better to have a single root, and make everything else an intermediate, though I'm not sure enough of that to bake it into the specification. From owner-freebsd-hackers@freebsd.org Mon Oct 23 13:46:00 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5F8F8E4C495 for ; Mon, 23 Oct 2017 13:46:00 +0000 (UTC) (envelope-from kevans91@ksu.edu) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0078.outbound.protection.outlook.com [104.47.36.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EA666714F5 for ; Mon, 23 Oct 2017 13:45:58 +0000 (UTC) (envelope-from kevans91@ksu.edu) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ksu.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=c52+5lOssv2MhOtJs5AQBmK08enDYs45wG+hwxunPm4=; b=YOSe8+TGGYxAsaIBcoUdjumwh0GpA8jXUF+6eEC+xISbeW08sF+fu9YupXVsIXc5365YkgHv+LbI1xQHX/IAVcRRZAkW5VHD44JUwrj1vEyBBStl7qsd92QdSSuAv+5QtSetbvrvFFUvEFtZvaFk3tbB74xgPUK/xdfeMPZjiQM= Received: from SN4PR0501CA0017.namprd05.prod.outlook.com (10.167.112.30) by CY1PR05MB1964.namprd05.prod.outlook.com (10.162.216.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.3; Mon, 23 Oct 2017 13:45:57 +0000 Received: from SN1NAM02FT005.eop-nam02.prod.protection.outlook.com (2a01:111:f400:7e44::201) by SN4PR0501CA0017.outlook.office365.com (2603:10b6:803:40::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.178.3 via Frontend Transport; Mon, 23 Oct 2017 13:45:57 +0000 Authentication-Results: spf=pass (sender IP is 129.130.18.151) smtp.mailfrom=ksu.edu; freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=bestguesspass action=none header.from=ksu.edu; Received-SPF: Pass (protection.outlook.com: domain of ksu.edu designates 129.130.18.151 as permitted sender) receiver=protection.outlook.com; client-ip=129.130.18.151; helo=ome-vm-smtp2.campus.ksu.edu; Received: from ome-vm-smtp2.campus.ksu.edu (129.130.18.151) by SN1NAM02FT005.mail.protection.outlook.com (10.152.72.117) with Microsoft SMTP Server id 15.20.156.4 via Frontend Transport; Mon, 23 Oct 2017 13:45:54 +0000 Received: from calypso.engg.ksu.edu (calypso.engg.ksu.edu [129.130.43.181]) by ome-vm-smtp2.campus.ksu.edu (8.14.4/8.14.4/Debian-2ubuntu2.1) with ESMTP id v9NDjr3G025077 for ; Mon, 23 Oct 2017 08:45:54 -0500 Received: by calypso.engg.ksu.edu (Postfix, from userid 110) id D9B1424835B; Mon, 23 Oct 2017 08:45:53 -0500 (CDT) Received: from mail-io0-f173.google.com (mail-io0-f173.google.com [209.85.223.173]) by calypso.engg.ksu.edu (Postfix) with ESMTPA id BFA8724833B for ; Mon, 23 Oct 2017 08:45:51 -0500 (CDT) Received: by mail-io0-f173.google.com with SMTP id j17so20134377iod.5 for ; Mon, 23 Oct 2017 06:45:51 -0700 (PDT) X-Gm-Message-State: AMCzsaVHor5oZP81VSSBpVITtqLskkXlwjPlI+8sjZ5F6z/vhGf8fO5W CZa/DvuiYk9vQB46OZid6ghBeAqHj/HEgW+rxmM= X-Google-Smtp-Source: ABhQp+Sieul2JOk2BBT+JxOBURQZC1kZeFyV/UX8vSg52hHyTxxMEWwpfmh6fVmaj7rdee2UsUfZ6sOKOpaLP8lH++s= X-Received: by 10.107.27.7 with SMTP id b7mr6811765iob.136.1508766350940; Mon, 23 Oct 2017 06:45:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.23.129 with HTTP; Mon, 23 Oct 2017 06:45:30 -0700 (PDT) In-Reply-To: References: From: Kyle Evans Date: Mon, 23 Oct 2017 08:45:30 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: We do serial differently. To: Zaphod Beeblebrox CC: FreeBSD Hackers X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:129.130.18.151; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(346002)(39860400002)(376002)(2980300002)(438002)(24454002)(199003)(189002)(2950100002)(95326003)(229853002)(498394004)(9896002)(61726006)(8936002)(8576002)(606006)(8676002)(75432002)(34040400001)(246002)(356003)(305945005)(55446002)(189998001)(90966002)(84326002)(2906002)(106002)(88552002)(5660300001)(76176999)(54356999)(316002)(50986999)(93516999)(786003)(42186006)(59536001)(16586007)(512874002)(6862004)(53546010)(478600001)(4326008)(3480700004)(1411001)(45336002)(61266001)(966005)(106466001)(6246003)(236005)(9686003)(86362001)(46386002)(6306002)(55456009); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR05MB1964; H:ome-vm-smtp2.campus.ksu.edu; FPR:; SPF:Pass; PTR:ip-18-151.net.ksu.edu; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; SN1NAM02FT005; 1:5qVXNsvx+qnqxJ6yarz1YlOiAK/cUgNBbg4p9FdT4qBz5RrLLvfM79NTGzma/2Ro0lwZs+aUJ76o26M0NC6AEGuEgoO2qMgF7f3LwBb/X1Ghd1vP4aOZaRCDLAuXjS34 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 63501c0e-d07e-4eeb-183d-08d51a1c61f7 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(8251501002)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:CY1PR05MB1964; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB1964; 3:TgVRc4g4de1DXmYOSXFVal6vtjHc8ze7l9RHbndMxX1GC9/5WvQanL1WD9kO9ffciSkINIGkPXX/D6RWKOF4BY1ykmArrrU8GRDfkIPXwIqJES/FpTF4+Z8HtME4xLOm1qc/HfIcI4jVtAOlZRKdGpM4uCuhns4Oq4I16lFVwzi4wp8nQU+LlxnQTPhtJ63sl7jI6/pHq6VLkkPt/G6Wt6ByyyJdimyqy6fIEhgK0TrItYQq7UxeKxPIbPisVYcMqNJcfBjLLsBWJPY1sp1ENxMOZEYwlMbtrYG4Fj7Hktn4tJ04ALWXtO527XLSsxIamhXsczOgcdMiW0F4xxqutI8GWQ3aQmQEQG5Ox5Fp9hI=; 25:egE82lC1c1cL8E4RtHoBaT6dIFE0TS99iEU2gReN1g4sJ3fEejIZEf3BnLQXwdPaHPpm72B06Y8QLL24l7FnSLJc5pAbQNm3QR+YkBqA9bP3RH5k1wWu3XRscoCv69A/7yynnucO9X4fYiR5dlpGUVE1VsPGrL4NLsJFJmjOvQsfgxWDZdlDUs3Ms2d7u/9mzX2OFJ86J9yAuqEoa+qOSMmg9mM8QDLhB9I52/J7B9Yr73qFu5Lk3mMRoZJ1AVaT7dxX+CDNLFBERlXIsV4eKLRXalYbscYoUyx/169IhbjTlQC/nHWVNy5o4Sbd1UeA9+ZVI5qmOjKWdxdb2hlG+g== X-MS-TrafficTypeDiagnostic: CY1PR05MB1964: X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB1964; 31:zak6HWUw4g6/Ezg66oDDptD61by0061qpUeWayzwf0jFAQx+4WZp+tSEziFR/eCwDuKTR0Qg4TdUnw4PWdqTX733bYM7cDi+hNoN7Kx8irr1aq2P9+fb/i/CiOveznUTxxZ2jHPwSDLSg3t26gQvBVpA/2hrDXE6WnzwNx8FhAhBgQ5uRrKlsaBAo5Kiu0mvpLIlqvOMDM314WEj7L/mG5tUFV9h7wmn/e37yRkOCac=; 20:OTa+tKR1gHDEtNoo2GSW5rWzgVOz/wNrYyUzzkuew3PWqtDa3A80Wg/vOYgyIsgtdFWGapF9l443MQCPD6h14C2ROadkai1TmuObWuOya/wJdJWe4jpv4QM3h9AiqGrnAEVgzeD1dhVz7nYw/UvJ4uzwRYJT5RqGTP4iXPE9LT5/YY98XFSGrrQ/9PpneKKeFl+AwKwMDee4YiNsUjojLgqUfvn/sxhW0FvOFgpa6JZJ+h/f/Zw96LGrhE1LvJ20b3gMosbuDS8ZXKNu7fqR2TEXPRSkDezvXdARj2sWvyT4GOeBh6g0O4vfVQXLNSTcVsSnO+Fp6CAO2Lsy+e2THXko3e/2XhMtLrr+N72/mLWsGLUBrzY4YqvXqc8Jr9MWuYyc6t6P9siwVqsLqB2kMy2PQoQ08C+sO/pa3TXbzD6vdtTL9Dnfa8K+src63v/c2JS2FBI6SujrHtM6uWpfQxoimNr8xfLYdUKbtjvoeIaWc4xnPBgbcFgNxgvj1igI X-Exchange-Antispam-Report-Test: UriScan:(211936372134217)(80641642340047)(75325880899374)(21532816269658); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(3002001)(3231020)(100000703101)(100105400095)(93006095)(93004095)(920507026)(6041248)(20161123558100)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR05MB1964; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR05MB1964; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB1964; 4:JRFrzOB5J24j8Q4ztNRcJ6cck1Ha2eTp/Tfy5tkcLcF1jKZ59P9fJGu3KUDOGs04Th1bZSn0x/8i19roRzi4WyxcPayjxWOZzmkuOwqbR73hL7iPeOOckl1PWTHhEmxPuU2oDBLPoTb7fzvxJlX0Kep4Vj0R2M7IQEstQxPWzRkiY7rBT9Qsokdztg5z3Hs9YTta9zUe4h6cjDwOyUOFQyc3x2bi904UXwOUZLu0YYPIipH6UDDOwj7pDefHMilIzdGyqWu2Nulf2mFsneFqsF74gVIOWm02HIuLdIknaC887/E25GLFuHGqGhAvmdOYm/48EjXmaJ0k2D+a8mgAXqMgLKN7lP2/qA/opImqfxmNFgxvccSooKNUhwLa3ysZf3hVy9hSKwDWAoDZ65I1KTtv1dLZ8MEFdlwnHvJvVbs= X-Forefront-PRVS: 046985391D X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB1964; 23:7p3IuioqfLVjfyJhBwFAQXYtdK34WNzmPPXRUNtLi?= =?us-ascii?Q?EOaroZK8zNVg6utcLMbxHRx7mJizyBz6D/dgmATJAQEXDgNG3TDj5dAMWpM0?= =?us-ascii?Q?mvh+glEBjfZY1S1OzYFw0g8bX6Y8bPnoI2J5bCkt3j2mcx1e/9tgJ0rDbCik?= =?us-ascii?Q?WYUjEdMZlivLt/9K109B8zTBeKxIo0nbK2+7VXPh8mcJH2zXXKOhl6RQ75sO?= =?us-ascii?Q?cEpjPAkBoBTHZ/8YITpJQYCTzfhTr9qWO4JND1oeY7RIg8nxycYquQkML42N?= =?us-ascii?Q?PZJBB6QvrxhkWofZrjVm+ynrjawHK7M7zKhax5nCsLioj/J4oOR2ClPQ471H?= =?us-ascii?Q?REpxZVUeobDo+uxZmGDsHuNWdsgCjVG99jOc2X6fsohz7YYabxVzGTuJAzUJ?= =?us-ascii?Q?A5LXY8ykWbdENU8xEtgJVCrBAH/P6IumeZVUyzjt1OCEk7zMsMbP8CmPXhzn?= =?us-ascii?Q?l0PjtvMbhSUI2dGLwPHaeAC6EOn1HSl7Vfwmuev6ly6nTeeRPdxlHGvWgeoj?= =?us-ascii?Q?hXnjJrzhzoNDbW/P6o3gTm/jj9zdkvjGnSqtJvvNupC/Y8opCT301py02y1c?= =?us-ascii?Q?RWrWGxcuiK8XMpUGzxkZ7XpMGFl0rfBIVShLGSnxJEW6i0geu9uceN6uL7qM?= =?us-ascii?Q?dOhaDDrwlpZ1vvzav9fi90+081Iw01KMwZE7RLbpymQ9at45b2ntzfnUEmK8?= =?us-ascii?Q?Kg6b0j1vFIOd7Dd+NoiPaWvTj0x5x7dBNmlBfgZldOpzZsy1f/IQNR0hkZO9?= =?us-ascii?Q?XYHXbomcbSK9YyytZ7InpbkM9CBYQmamCnu60splWA5+j2K2GXMEHPJfgeHT?= =?us-ascii?Q?JtA1igf35tNvEU9bEOh0NC5Ve4NQSPQ+CvHICJyJ9CMIJF/iYoSeBN08Dnnm?= =?us-ascii?Q?pHNiFuzAAHh5sSPGG8KBOkwB+9wYYVBd1rbG4Cda5W31GaRJ0jxgfNH1t41r?= =?us-ascii?Q?Sf63KpJHhQXrdGWBYrNKb87tKK9fCt+aJMzhkPRdd2psGC5U1ycadnAMjXLr?= =?us-ascii?Q?NDuN30y/JqwA8NHzx+kVVHkaXlbw4auy2xpAnleXaSDDW1dnIaz/7R1uuuXc?= =?us-ascii?Q?6BtpZIuW8aM/MU22JWOHPCfo5hyw7iOZec47GyUTS3SQC6cviTWGH4SVwxri?= =?us-ascii?Q?q6CTL31q67HEwtjwN96f+XyNH59ZNofccH9MRmJLfSX5SVEhjJOdyzOxI5xS?= =?us-ascii?Q?KspJT5ax+D5uGrE7QxpYDSDzQVYVr7xOJUKL78KZ2NrfmcIrhqV7o2Gvyh39?= =?us-ascii?Q?T58zdoh5NhMVwmiTzhpihdlY9l5z1MGjYYzeKTje2V1fI1qGtYlOy28WktTQ?= =?us-ascii?Q?QVxia84vGczAXWgivHqJfs=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB1964; 6:09su2dsG3XgwHZ3bTSmNl++EY2YRHneYT2+Jfu9fvIxNhXCyBRarPsgV+PaY9YAkyqzWjguXp9cLMXCOldkhvtYaMYFp8vmCJLmwTTyKjGf7GwITcSf3fsAFjPtX0HPjKH8pIm+4XkmdCwAyYKUCA9EjMS65IAs4n6T6Uq3Bbsiy9XYd0sQr/Lxu9hGMOssXnpvaPSpPvn01gysuZNZ7nlj3wYnXEQcOiwQO+n9gJGQk/H4/KoW2EKAjOUzqSDbgydR0+t5C+fg/zC7Mpk805sj4wskVgBARPdZiBBrNhcA0mcxLoycA+B70rcQLzBYbWpaQFsqMJZ/NWPRqZ6rG5IvLNAyTW/g9DAzDuMUXwgo=; 5:cdUT7d2iApwxNPEfYnLpG/d/m6rS7BdiAgfD6Whm16R15F7O+3oy96/SNCgMHZMl4rsfHm4UKMb1dweSum/+0Cgp+w9BHRFy8KfGCEfD1LkVx15EHNZmBMXfv4XYxS5h3oMsoZyFLqySPbk7OCP/n2O+szc7l+3LJRikBtMfpUQ=; 24:RMS1L2ucpqIfgRBmSQazpQPQ1ntdWTL3sjpKT92QbqCofj7e/Wdc+fUdeBQH2jG8j+XIkMRXgOgtMPTk21olpaJ3Zad5IrO5KjVepiq9ZeI=; 7:t+PIcEjlmv0x6Vzy6nZAqakd9K42KZPT4uZoYEJMc3sXNXiDs3jAHYSeDjlW8A+5SIf7yu3deoFJR5MWrjzHDIalckJhl0A9iMV5tWAcbDzRkgsGobkWN2MhCEEnfiojbAidi19uP/wXatx0m31FnRBDsnarfkAXygApIhmOlSIzvHM6OKIPiA4vZgbvVs0wz/1IpFbkVsqMr/q85xaEeIfMrNDkvyoJR74LJJCFmkczaWY+aEYagzk2V/an55Np SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB1964; 20:gHvMQ2NcFKN8Ga0rC/nkGWSAOVZo7WGj7Gp4BDPA76n/U90ZqIAljp/ev8NIjsENc7DOy7GSSGZbunWn+qOWm0hm2tX0ouuBiG+r8+d72mQNKhVCRnD+MADKcqz5vr1R4KcwbJ7rO1lb/7WMqSHIJ/T56XdAF2tvUCwGDdncBhc= X-OriginatorOrg: ksu.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Oct 2017 13:45:54.5751 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 63501c0e-d07e-4eeb-183d-08d51a1c61f7 X-MS-Exchange-CrossTenant-Id: d9a2fa71-d67d-4cb6-b541-06ccaa8013fb X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=d9a2fa71-d67d-4cb6-b541-06ccaa8013fb; Ip=[129.130.18.151]; Helo=[ome-vm-smtp2.campus.ksu.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB1964 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 13:46:00 -0000 Hi, Are you able to connect to it otherwise (w/ cu or friends) and issue, say, an M105 manually? Also, which version of Arduino IDE are you using that *does* work? (for the sake of digging into why it might work while nothing else does) Thanks, Kyle Evans On Wed, Oct 18, 2017 at 11:25 PM, Zaphod Beeblebrox wrote: > How does FreeBSD do serial differently than Linux or MacOS or Windows? > > Now... this isn't _exactly_ serial, but the serial that is emulated by the > arduino driver in ports. > > The issue is that running the arduino IDE works (and it boots with the > loaded code), but then running 'pronterface' fails to connect --- looking > all-the-while like one-way communication. > > I see someone else basically having the same problem and claiming that > hacking a trace (that affects the DTR response) on the arduino fixes it for > FreeBSD (see https://plus.google.com/+MiroslavPrymek/posts/6TDdbuoNhzH > )... > > Given this information, can I stty my way out of this problem? Can I make > a small modification to pronterface? > _______________________________________________ > 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 Mon Oct 23 16:14:59 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 61B26E4F228 for ; Mon, 23 Oct 2017 16:14:59 +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 F1D3C75C7E for ; Mon, 23 Oct 2017 16:14:58 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 4b3e415d-b80d-11e7-a893-25625093991c X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 4b3e415d-b80d-11e7-a893-25625093991c; Mon, 23 Oct 2017 16:14:50 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v9NGEjrb001381; Mon, 23 Oct 2017 10:14:45 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1508775285.34364.2.camel@freebsd.org> Subject: Re: Trust system write-up From: Ian Lepore To: Eric McCorkle , "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org, freebsd-arch@freebsd.org Date: Mon, 23 Oct 2017 10:14:45 -0600 In-Reply-To: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.net> References: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.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.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 16:14:59 -0000 On Sun, 2017-10-22 at 18:14 -0400, Eric McCorkle wrote: > Hello everyone, > > The following is a write-up of my current design for a public-key trust > system: > > https://www.metricspace.net/files/freebsd_trust.pdf > > Some of you are certainly familiar with some or all of this; > I've discussed parts of it before on -hackers and -security, and I > discussed it in greater detail in BoF sessions at vBSDCon.  It seems > things are heating up in this direction, so I'd like to get this out > there and get discussion and feedback. > > I plan on undertaking work on this in the very near future, especially > since the commit-train for GELI EFI is ready to arrive in HEAD. > > A bit about the format: this is sort of the "meat" of what I hope will > be a paper some day, but it's still an initial draft.  Moreover, it > talks about things I'm planning as if they exist, mainly because I don't > want to have to go back and rewrite everything in the future.  In > reality, most of what I talk about is just a proposal at this point, > with a few bits being implemented as a PoC here and there. > > Please read and consider the designs I've proposed.  I welcome any > feedback and suggestions.  I'll give it a week minimum from today before > I resume any work on this stuff. > > > Note: Apologies for the external link; I had originally included this as > an attachment, but it was too large. > _______________________________________________ Any thoughts on how to validate executables which are not elf binaries, such as shell scripts, python programs, etc? -- Ian From owner-freebsd-hackers@freebsd.org Mon Oct 23 16:44:44 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C2BF7E4FB48; Mon, 23 Oct 2017 16:44:44 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0115.outbound.protection.outlook.com [104.47.36.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5A23276DE8; Mon, 23 Oct 2017 16:44:43 +0000 (UTC) (envelope-from sjg@juniper.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=yMde/2kKxMrODPN/KYl1VtOtyrUSnW7Dzu4Nz07SchI=; b=XArATkeXvmDqbQv/+8lqV0OAlyCJBMhl1ooCRPCYzjAXkajGiDk0CWRtQAp4twqas8erprSx1j2iJZBHqfkKTqvjYIt/enYm0SEtCpCE5h3KkeyKbC2yMlmcFer/+HXoUl1Rkjl92Qghwax7c+N8p85ud7Kd+Vz2s5tuQoW7nGc= Received: from DM5PR05CA0010.namprd05.prod.outlook.com (10.173.226.20) by BY2PR0501MB2070.namprd05.prod.outlook.com (10.163.197.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.3; Mon, 23 Oct 2017 16:44:42 +0000 Received: from DM3NAM05FT035.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e51::204) by DM5PR05CA0010.outlook.office365.com (2603:10b6:3:d4::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.156.4 via Frontend Transport; Mon, 23 Oct 2017 16:44:42 +0000 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by DM3NAM05FT035.mail.protection.outlook.com (10.152.98.148) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256) id 15.20.156.4 via Frontend Transport; Mon, 23 Oct 2017 16:44:41 +0000 Received: from p-mailhub01.juniper.net (10.47.226.20) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 23 Oct 2017 09:44:34 -0700 Received: from kaos.jnpr.net (kaos.jnpr.net [172.21.30.60]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v9NGiXmw010661; Mon, 23 Oct 2017 09:44:34 -0700 (envelope-from sjg@juniper.net) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id 6302B385567; Mon, 23 Oct 2017 09:44:34 -0700 (PDT) To: Eric McCorkle CC: , "freebsd-hackers@freebsd.org" , Subject: Re: Trust system write-up In-Reply-To: References: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.net> <20171023071120.GA72383@blogreen.org> Comments: In-reply-to: Eric McCorkle message dated "Mon, 23 Oct 2017 07:56:33 -0400." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 25.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <67124.1508777074.1@kaos.jnpr.net> Date: Mon, 23 Oct 2017 09:44:34 -0700 Message-ID: <67125.1508777074@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(39860400002)(2980300002)(189002)(199003)(24454002)(81156014)(81166006)(16586007)(55016002)(316002)(229853002)(9686003)(68736007)(8936002)(76176999)(54906003)(305945005)(478600001)(106466001)(97756001)(77096006)(105596002)(8676002)(86362001)(356003)(46406003)(53936002)(4326008)(189998001)(5890100001)(69596002)(23726003)(76506005)(117636001)(47776003)(50226002)(6246003)(7696004)(6266002)(53416004)(97736004)(2810700001)(7126002)(50986999)(97876018)(50466002)(6916009)(107886003)(2906002)(5660300001)(2950100002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0501MB2070; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM05FT035; 1:2iRSCjxPQjeczHQT2ucvAqOHva/Yprb/WaCmqZWnYTMc9sLV9qRxVVpWQq9XJO2hYBYmlBVhG45k/hTlnPVR96LrlcPfa8XDtMdl1o9xjh3BCiW8cnj6sS6NkApUdBlG X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 5807dd2c-0f3d-4b38-9dd3-08d51a355be6 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603229); SRVR:BY2PR0501MB2070; X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB2070; 3:woq6UcgmC6fyVTTCEIUZ9/rELmslIJVnaRcUb/gvVop9EzBBOEeGrpREaSLDbHl77sgZJfi673tCJsSEaUUDq/DMqKHIjZOXeK+nUp22ew+WmdXDsj7vb9pI27WtYscmFgSV5oOyuJUWyGtVjWMmchFz2CWZmPkRTwqWn1D5IRJAxDCWRo4F9hf1cUbVMympaYMMuLwPFJgjE4qVPWHCyYnhe+M3fDNMEFWQ27nQetHheuOptL3EjHxbjQ8YsBjAKaI3IovC2mTOUpd84f9HiJkhfPvJCYUcnPgKb5GM9YRijk+0S0nhEhFLhXjyI0f+6SZKDotTwZApfF9TFo3t/+VItP//yNsb241GJJHw54U=; 25:FVPBOKX7nTAC+zzX9eHPk6snClOGLjnl9IiKpsAfwmXezR1AxC+5/NHbIVP9uQrsj4sNt95UPIzZlgX7OFwL7rvR1Ramq9brWIiZ/5JEguje/yJtMd6YishuA/+S8CT42oqTULd79D3FmwpU/9Mop3V8TR5VbJ1nWowGAoVfiqhkhJf+f1gkD8J/A0irgzc54RcPoS9lStj9Oh/42MBLMNNfUq1UG0JewnNlaWudATs816nCe0tiQxmiPQdOvYo1ph/sedtOL3QnwR8Nd9bLsOxp8of0QK3v4lw2dWgyDw+7QgNAlgqiYg3vOW6oz653tA8IH9mwr3mwcK32+e6Y0A== X-MS-TrafficTypeDiagnostic: BY2PR0501MB2070: X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB2070; 31:P6lSPaSXcWBJ4z1J5ykj37uAHobclxUyq4+F3jhNTv4oWQVMMyPwUJaaW2Otm2iIwz9e29q+nCSNMNbZSlEs6/1YaDI+R62pS6Q3Q93C4XsogWM2gM5TgHYTF5omF14+WGMOt/WH6O/ZwL+BMkVWb0wrtnRkVUu1hxENA0SkNRXN2rXhh5meydMl29ixTZXRloltWk//aVA1CejaX2+Y/hCLGBhomM7lW9ovDhoEYew=; 20:5tjKzPZaPyVonTB/6AQC3Pb5c/2tkB4V/l51CL6s/BGUUQPZV3O2OF1tbsgJoEtkHGbTj0Z6XbCxTjZHwhr6mk6H3oEvhEgzbEXZeW0m7zA33gJ7/WRbV5u5DqxkcjfzJekNCR0aKVIodovqT1MOLLKr853NMqGZmKcbHaQpyVdA1fZbeaaJ0uoKojdiZL/ejTnIVZPd3rMZ2z9JCtDuje2klZzrgR9RUuPOY9PCDZSav8GO86YSDhB+RDtjR6WcIUyl84haHD9cwd4FbaX9Gj7RzMfsydI5auaox5j0G1tlrr7XVQKhrtOnF2PZ1M3Yh6TYfMXYvFRGaQjUkaMxSsEzUXLxKW/w1D7yL/ITgjffOFAm4wQtUwGyxoo0Qk87Ke7UjukhTlOnqfCzZWb8ULqIPHJ7xaVJZ0DJwkMmliri5XlAZD43I5mvhDqY+wsxG8aooZHZF5S+OAFnuP/NGiHxjh+pYw8NEmK4fwurcSQU95NbdnMAz0Vt58+nnOPo X-Exchange-Antispam-Report-Test: UriScan:; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(3231020)(100000703101)(100105400095)(93006095)(93003095)(10201501046)(6055026)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BY2PR0501MB2070; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BY2PR0501MB2070; X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB2070; 4:z/giGsvgobfxUErTwig0r/dstWtq43Q44ddWpdNAmF6Kb0wHLkzAT8jBN/ljy7zUoWvdXOWUbkCeZ51ui4TYP6uCPvpq6ZLBQOXe9SH9/n3CNCujsJN4n8gooXKJ3OF2la2LF4kDqguf2ms4DhWijkwtsYGMhPKZZFiRde8dPTxnqqtOosqxgyjM4zD4t2F5b32TVMQGZ5I9p13KGXmvAYsmiUM1A/1VyPrWr6jfLRwuZWW7VURjykLrBx1zKVMqCLMoaeoeD095MEBMmsr9/w== X-Forefront-PRVS: 046985391D X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2PR0501MB2070; 23:tvkNoxYOcb2BtQGCASrI0zNkdAOprOys1fqQ34J?= =?us-ascii?Q?WIu7CqnFlkk+yeis/Q3Zt7SZhwgUZVnPoLcBjRJEpxq3RjN1mkxlqC0fqCFm?= =?us-ascii?Q?7OlzAyDtyUaZyeIufqv+0DzuZ60f36MfvKpK+9Dbeg2g0LXMNe4ggEclcQ2v?= =?us-ascii?Q?YiKaMljOLTLOrhBNNvbHfUCLu8elPpwCu/mayOoNgeqnhC+/C21pHXpq5emI?= =?us-ascii?Q?FzXqjjaWSD9NWc1xT82wcsfv0W7+wcEFoeks/OWMVJBAb0qxjBtYrvrL4ba4?= =?us-ascii?Q?xqHXsTQCqhsGPoH7cHo/A8pArM1SQYUgqswbim+1kl3a5wjM6a2tLAmR2zii?= =?us-ascii?Q?Vfm6IGQluw9b/NALryezr1Az5VQfStCp7IzvgvhbR9g7NPWHGYF/fl/PbQm5?= =?us-ascii?Q?8dUTJx23C3Hsu0jhMFNGDAmR1nW2NFbTlcoK62xE9NPF3BAt5shufCfH51Jt?= =?us-ascii?Q?ywUkPvnFMTwmlAJLunm+cxru1bGn+hAmJL+LmgcRhdePXHta+0ULnxGzXyZz?= =?us-ascii?Q?LVE/cBT8svuMv8wlKfGkf+NPOBbbPUdCWB99Xb1qogtplfOsonscXmwmfLyQ?= =?us-ascii?Q?NuJoS3E52k4T9qZ4SzWiHWp9+T9ym4SIH4R+tHyjAQwDkbrOtozBVSjGYAmw?= =?us-ascii?Q?Mp5Q7aNhOY2dPE7MLLJruWN3QJHUW+KyitLwzi0TNvVZkH4UU2pUGW7ZKjY4?= =?us-ascii?Q?gX6ipXrujNGd74WMNjIQX/UTt9TSq/fC2ixnZYoJqnH85gseoTMNDWQ42jmH?= =?us-ascii?Q?ZAzB0u9GZKJn81E5CdVNCKkB/r63zv8drob6e52Ko5/bEmSQVlCwuvZ5Cmlj?= =?us-ascii?Q?oBdWWS6vABDMoD9sIgl/hRusIdUZzDcBCGdvIkyLoPQzyzDlPl9ie8JYr03W?= =?us-ascii?Q?U/Tv548FWT/QqV+wgDk8tK6p20BQGXNzYbznuRIhbeoDEiTtH8s/2Sy2rWof?= =?us-ascii?Q?05+u51VDPCsrCWzFR0PSUn0V2/hdmdt674bxVOZjXu+OgDbdppwT3oQeLvmE?= =?us-ascii?Q?dzoW2smjBpBYTEQdcVZZJxM45wgvmAE1WDCX31ijOzmQd6Ra3cesBgNdY0FL?= =?us-ascii?Q?rT6GhHdOKtnaw8kTv35PrslcfV4TASJZq/taEjc38o5xel+7FSiI5eF2wK41?= =?us-ascii?Q?9j4MbFj0icinmqHH8FncVtK6yePOq4YEF4D2PHWPMEXCV07zHUxcvFOF4pJQ?= =?us-ascii?Q?G2gmaAbWPq9LIRqoo4ovK7JMV6p1H8/j3gXrnLHVNblwGvvQZpaFQTT82wQZ?= =?us-ascii?Q?xw4q49uCD17S23rwkZ3OKG98bzMfvQMN2R+uMPdZ4E3DJLzxt2DHINUwf/VP?= =?us-ascii?Q?C8Q=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB2070; 6:/a6En+FiEU8v5YF0hQdK3BLQLD/FTBOkmsYlPqMP/YwDlilpqScCysb84yZ900J0AIipA47xy+MqVUP7AxESq6NQhe7CUBRHX0XOF2unHlIqGLjCRTp9+3EkB9YjKcuk1kUoRS+3ZW0H9CsmQDZuJJUru0jX5YpPXGoAbr5hzX5M/ouqu+8gy3vB1nuaqECIESQACvwXaukcsquPQRh0tv8oDPt/8eIydBx/F4sH70Q+W2nUzdcT8Bg90ZtJrkdObxrgndQnGqaxPNRKkuhsIe/Ztag+u0nztfb+7ySn+7c8rCJRdZ7trJ+LL3RjH2Qnvq6VdHRKf3Tb6nEohEQue0CBxJ7rZHDXL1rvd3wMupw=; 5:IgAebuozMqZ1rzsCFqkGD7AocGN8942XS1DVXGr+BOT+TSVLprtBp6xZarj2Tze3e6tv/nQq3T5Y/8NHQs3+V6qwfjwgjRMbM6qaJ06aGvUtaaBfJUpKGas4pzHAkLkjpXxT9NPjdsOsB+8o6clRwD1r2yBBjcIm1coaUKKVm9g=; 24:X3pga876BuvSCEgZqETIt3sBV1rjTd08sl2vF7es6H57XJVQ5da30y3/3v0rO54RKpWtZPbSpFlSfylciX4SciMnrBN9FHO0sCHaDieVYIY=; 7:Todev4OSTdtNncpszEYJdskeCAAzZ8GyDbP8DEAM+C5QOjnJoMw+zRVHBL0hTGjLHMozvv3cdsd/bzxNAqIN+C6/JDaz7TxAeLEy2QtOpVysSHjd46c0mOz1Hj8miOH+5U6EtV7oUykJgOoOkGzieRQHcCaTetm1jOptsVu626Ad8dcKpBhVl5M9zRA32F1HHCYyqYfWjZH0gm7pfZyAu2W//Vl66gsFUvZPY8V+v9R4H4YNAaH5rW55N/ukNqIC SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Oct 2017 16:44:41.6472 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 5807dd2c-0f3d-4b38-9dd3-08d51a355be6 X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0501MB2070 X-Mailman-Approved-At: Mon, 23 Oct 2017 17:55:34 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 16:44:44 -0000 Eric McCorkle wrote: > That is also an option; however, I prefer the configuration where only > the local system key is a root and everything else is an intermediate, > as each root key represents a source of trust that is hard to revoke > (you have to power-cycle). It's almost always better to have a single > root, and make everything else an intermediate, though I'm not sure > enough of that to bake it into the specification. While we as an embedded vendor might not necessarily want to support any local signing ability - or to be able to limit the scope of any such ability, there should be no reason you cannot allow a FreeBSD.org root cert to be honored in parallel with local root. This should allow updating system with both locally build s/w and pre-built packages from FreeBSD. FWIW when designing the trust model for Junos, preventing any local control of trust store was an explicit goal. With the advent of secure boot and TPM's, there is potentially scope to allow for mixed control. Please have a look at stevek's mac_veriexec patches in phabricator. The verified exec model easily allows for "signing" any sort of file, not just ELF binaries or needing to use special "attached" signature formats. Thus it allows adding "signing" with minimal impact to most of the system. This could probably work well in conjunction with your trust database. And of course my loader mods follow the same model, so signing loader.conf, modules etc is all simple with minimal impact to loader itself. --sjg From owner-freebsd-hackers@freebsd.org Mon Oct 23 22:28:03 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 82F3DE56925; Mon, 23 Oct 2017 22:28:03 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 520192A40; Mon, 23 Oct 2017 22:28:03 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id B28ED2F80; Mon, 23 Oct 2017 22:28:02 +0000 (UTC) Subject: Re: Trust system write-up To: Ian Lepore , "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org, freebsd-arch@freebsd.org References: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.net> <1508775285.34364.2.camel@freebsd.org> From: Eric McCorkle Message-ID: Date: Mon, 23 Oct 2017 18:28:02 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <1508775285.34364.2.camel@freebsd.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 22:28:03 -0000 On 10/23/2017 12:14, Ian Lepore wrote: > Any thoughts on how to validate executables which are not elf binaries, > such as shell scripts, python programs, etc? I hadn't really thought in depth about it, as my main initial goal is signed kernel/modules, but I have given it some thought... Arguably the "right" way to do it would be to have the signing mechanism be part of the platform. For example, the JVM has conventions for jar signing. Not clear how this relates to shell scripts though. An alternative is something like the NetBSD veriexec framework, where there's MACs for specific files. That stuff is mostly orthogonal to the public-key approach I'm working on here, but there's possibly some interplay. From owner-freebsd-hackers@freebsd.org Mon Oct 23 22:41:36 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AEB1FE56F21; Mon, 23 Oct 2017 22:41:36 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 88048339F; Mon, 23 Oct 2017 22:41:36 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id B733A2F8E; Mon, 23 Oct 2017 22:41:29 +0000 (UTC) Subject: Re: Trust system write-up To: "Simon J. Gerraty" Cc: freebsd-arch@freebsd.org, "freebsd-hackers@freebsd.org" References: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.net> <20171023071120.GA72383@blogreen.org> <67125.1508777074@kaos.jnpr.net> From: Eric McCorkle Message-ID: <1923f560-debf-b913-5cd0-a349444e451d@metricspace.net> Date: Mon, 23 Oct 2017 18:41:29 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <67125.1508777074@kaos.jnpr.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 22:41:36 -0000 On 10/23/2017 12:44, Simon J. Gerraty wrote: > Eric McCorkle wrote: >> That is also an option; however, I prefer the configuration where only >> the local system key is a root and everything else is an intermediate, >> as each root key represents a source of trust that is hard to revoke >> (you have to power-cycle). It's almost always better to have a single >> root, and make everything else an intermediate, though I'm not sure >> enough of that to bake it into the specification. > > While we as an embedded vendor might not necessarily want to support any > local signing ability - or to be able to limit the scope of any such > ability, there should be no reason you cannot allow a FreeBSD.org root > cert to be honored in parallel with local root. This should allow > updating system with both locally build s/w and pre-built packages from > FreeBSD. You could do that. You can have as many root certs as you'd like. The rationale behind the "preferred" configuration is that it's simpler (fewer attack vectors) and it takes a stance that users should have exclusive control over their own machine. But nothing stops you from installing any number of vendor certs as roots. > > FWIW when designing the trust model for Junos, preventing any local > control of trust store was an explicit goal. > With the advent of secure boot and TPM's, there is potentially scope to > allow for mixed control. That sounds similar to the high-security setup I described. > Please have a look at stevek's mac_veriexec patches in phabricator. > The verified exec model easily allows for "signing" any sort of file, > not just ELF binaries or needing to use special "attached" signature > formats. Thus it allows adding "signing" with minimal impact to most of > the system. This could probably work well in conjunction with your > trust database. > > And of course my loader mods follow the same model, so signing > loader.conf, modules etc is all simple with minimal impact to loader > itself. I've seen that work. The NetBSD veriexec stuff is of interest. I don't really see it as a "competing" approach, more of a closely-related security mechanism. I don't see any reason why both mechanisms couldn't coexist, and there's probably some sort of beneficial interaction between the two. I could see, for example, veriexec being used to protect specific files from tampering, with the MACs themselves being provided by a signed file. I'm a bit less enthusiastic about veriexec in the loader. The problem there is it requires an update to the loader every single time you build a new kernel, whereas the public key approach only needs updating if you change root keys. (That's really the key difference: veriexec is an anti-tampering mechanism, where the trust system I've described is a trust-delegation mechanism). From owner-freebsd-hackers@freebsd.org Tue Oct 24 00:00:55 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 88E19E2BA92; Tue, 24 Oct 2017 00:00:55 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 5F6CE652C5; Tue, 24 Oct 2017 00:00:55 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 13E7B2FC6; Tue, 24 Oct 2017 00:00:54 +0000 (UTC) Subject: Re: Trust system write-up To: "Simon J. Gerraty" Cc: Ian Lepore , "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org, freebsd-arch@freebsd.org References: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.net> <1508775285.34364.2.camel@freebsd.org> <72903.1508799185@kaos.jnpr.net> From: Eric McCorkle Message-ID: Date: Mon, 23 Oct 2017 20:00:53 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <72903.1508799185@kaos.jnpr.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 00:00:55 -0000 On 10/23/2017 18:53, Simon J. Gerraty wrote: > Eric McCorkle wrote: >>> Any thoughts on how to validate executables which are not elf binaries, >>> such as shell scripts, python programs, etc? >> >> I hadn't really thought in depth about it, as my main initial goal is >> signed kernel/modules, but I have given it some thought... >> > >> An alternative is something like the NetBSD veriexec framework, where > > Yes, as previously mentioned the verified exec model deals with this > neatly, and btw is more efficient than signing individual files - as is > needed with ELF signing etc. I think for linux based platforms using IMA we > need to generate 20-30k+ signatures, vs about a dozen for platforms using > verified exec, verification is also more expensive I'm told. Hmmm. There's advantages both ways, and I'll probably end up supporting both, as it's useful to have an in-band mechanism as well (also, I've already implemented signed ELFs). However, there is a definite advantage to having one signature for a huge number of MACs. Moreover, as I mention in the paper, the most feasible quantum-safe signature scheme at the present is SPHINCS, which has signatures about 40Kib in size. That's pretty terrible if you're signing each executable, but if you're signing 20-30k MACs at 16-32 bytes per code plus a path, suddenly a 40Kib signature doesn't look so bad anymore. It would be pretty great to roll out a trust infrastructure AND viable quantum-safe signatures. I could also see a combined scheme, say, where ELF files carry a UUID which indexes into a MAC manifest. From owner-freebsd-hackers@freebsd.org Mon Oct 23 22:53:10 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2C03BE5735F; Mon, 23 Oct 2017 22:53:10 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0134.outbound.protection.outlook.com [104.47.33.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B3FFF3BF3; Mon, 23 Oct 2017 22:53:08 +0000 (UTC) (envelope-from sjg@juniper.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gL7yP/zlyheW2y6AMkUzAYLenl6Y/1mSP8BNcXkHekU=; b=g+txXp8dUJNVcuXgqnIVZRS+qnMG0U6q70skpVRHgModiRdorjGO8AeaLfq63AafcOaCKc7OpqaEtOWE1ACkNwZSUh63ZPjhCYHjtPa9gBmNY5RkNFlrwJDymi65snE4WM87bPJOlXjAqExGc5Mi/jQvHfaFzIYgpvgqi8QPBjw= Received: from BY1PR0501CA0003.namprd05.prod.outlook.com (10.162.139.13) by BN6PR05MB3012.namprd05.prod.outlook.com (10.173.19.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.4; Mon, 23 Oct 2017 22:53:06 +0000 Received: from BY2NAM05FT037.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e52::201) by BY1PR0501CA0003.outlook.office365.com (2a01:111:e400:4821::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.178.2 via Frontend Transport; Mon, 23 Oct 2017 22:53:06 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by BY2NAM05FT037.mail.protection.outlook.com (10.152.100.174) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256) id 15.20.156.4 via Frontend Transport; Mon, 23 Oct 2017 22:53:05 +0000 Received: from p-mailhub01.juniper.net (10.47.226.20) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 23 Oct 2017 15:53:05 -0700 Received: from kaos.jnpr.net (kaos.jnpr.net [172.21.30.60]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v9NMr4LT015550; Mon, 23 Oct 2017 15:53:04 -0700 (envelope-from sjg@juniper.net) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id 29CAE385567; Mon, 23 Oct 2017 15:53:05 -0700 (PDT) To: Eric McCorkle CC: Ian Lepore , "freebsd-hackers@freebsd.org" , , , Subject: Re: Trust system write-up In-Reply-To: References: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.net> <1508775285.34364.2.camel@freebsd.org> Comments: In-reply-to: Eric McCorkle message dated "Mon, 23 Oct 2017 18:28:02 -0400." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 25.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <72902.1508799185.1@kaos.jnpr.net> Date: Mon, 23 Oct 2017 15:53:05 -0700 Message-ID: <72903.1508799185@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(39860400002)(2980300002)(24454002)(199003)(189002)(50986999)(76176999)(4326008)(105596002)(46406003)(97876018)(7696004)(6916009)(69596002)(2950100002)(2810700001)(50466002)(305945005)(81166006)(23726003)(68736007)(81156014)(47776003)(106466001)(8676002)(50226002)(356003)(478600001)(53416004)(76506005)(2906002)(8936002)(5660300001)(229853002)(107886003)(86362001)(189998001)(97736004)(117636001)(54906003)(7126002)(316002)(9686003)(55016002)(16586007)(6246003)(53936002)(6266002)(97756001)(77096006)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR05MB3012; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM05FT037; 1:5lJiF6R0vHAsKDfuqb2+3kH0xb8WP8vB4mkUgyffEu2FZ2sejv5TP+BQoLP+sbYTD3d0kfvtZTEYhh8aYmuP/s2SxWdzikUa9w6XjpXyhPH89pMlNrzz6g01HZbMwq1b X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: ea03b818-4e0d-41cb-a096-08d51a68d2a9 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:BN6PR05MB3012; X-Microsoft-Exchange-Diagnostics: 1; BN6PR05MB3012; 3:dMgwDwonGgbA4DypvWJOlt/WLcRJp93C1OhdCdwlHaaQbbVe+1/oHLkS8SipU3WRn0jBEEXf36SXKxtQKEBz65SW42KufjTTLmNyQMdm6RW4zJIey3FRxmGOjln+NpL8G7WEwvLeVXhRK4NjV4brlz6XuCOu0skftdK1SZGLSzGT+hQ9omQFqGiNCnrKkGxmSfAbOdj6uox+Qy/A8DytZYq5A/uA1K9vrVXwmKvZmlZLFu5fOLID39Zmw7cyOvd1oMKkWPYMzlAMWnrh9m2sNpwH6qTpc24sTOHbn8dBuztsm40WL+0hRlTYI/2KMsgBg8L5o1FKZPXT/Qk30sRJM6Ezlg3bFGogj7EApyy3fPQ=; 25:9kBWzNzt4Dvpf5/1sJkDwBBC2zx+TYXtOb2HY0QMiVj0gtkQqTLc8L1W6NDBjRrGnOb3TkYb1QWgeotEV4zX6k09d0uJ7/5xhNUhQj/6jWFimP2MbvpIpCn9HrdRofYg41/GfvuhuTlcOZ4wDAkJC0gq+pdqtTBM98UCGVoJbME4LyLDfE1t54Jm4Z9PpaJokleAIgcdS/T1pQr4VZ4v8Vo1XGcfUpsap6ucjajRRwLpxkqGX8WvurF6Fygyw4fCNSJpRFD46GwLMFaSFg3YRQ1D/EByEM/PljrK0DNThWWeKHdVZKY4hCNGOWRfff02eA/OzUNlZLBQUU8EE56m4J3HWZwUwQKV2ptHGUYgWFc= X-MS-TrafficTypeDiagnostic: BN6PR05MB3012: X-Microsoft-Exchange-Diagnostics: 1; BN6PR05MB3012; 31:27pbbRLJkKVTUAU8eICFT1zeQS5Q/EJYrfAcGHX7Z7jsml6qlVnDmEVYGhoz/dgF9WhE6tSAIM5170RP8KDJJ3dhLXY6iOs8G789IdjEDefbB23RUvSUu0xokuLQpToR6gN8PANmp4QccmTd3XzkAn2yfacQVSWQHt95OnGgbWr973pu8EIM6ep0sTCgBNXR9k21tLhaLl1+PWsuaviPNA+o2NCDXQBMLnLY+l4c7lc=; 20:1VMgI5TTgxM0pmryAlMQQiQsjmyDE4/6YqoAGkS3q3pYUlaRXgk57MSM3npci28N8h6oVKINA06wSmJUyUvDoT8mF87Zn+mL/wkIgeG8yRYT+TkCqZWOLeaHSQe0ymUCN1GgIa0SPbEnS8M9F2gGKRgeuiZkr8GJz3tJHmYo0pprGNnPnxvMWwWb7R11QC3pDUdrxJu+4+Xe8W2bW4ov9t0K7TA3kVRBSwtetPgGK7p54weykkgHGy0k+PJpRRnRsR/wStbCF4Xe9fWBjwqqKQ9Xh+qdrkfYDxnKEIpDo6b4kxLAJFlwBicpTLbFW+cGnWuvkm35pRTTxdC1zTFrryG0/b3rDRGGJ222snpBwbWemHAOo7uWBt/dWuyMkh6V1XNUm6P0XH5jPqsDu+zLQSye8tUaEfapRRYYIpIXzTJ50wa7UDNYU56VYo6FIXxbPL/7pJFm3tZn+rSp0ST/MJdckGtjuJAA7c3iRPIQ7F5hK2Le/vm8/A2DHwOAftON X-Exchange-Antispam-Report-Test: UriScan:; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3231020)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93003095)(6055026)(6041248)(20161123562025)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN6PR05MB3012; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN6PR05MB3012; X-Microsoft-Exchange-Diagnostics: 1; BN6PR05MB3012; 4:4Bd8ehGZAtnIbEXO+/Dcn/9fU1qJyT1ALvlMakdQW0BfmtFx/Q6IMpYWvONMihbrdSz3LwAfKV/ji8hUlZ80aDWbXo9O9W42PD27sYYz5VkdqjZJvH/cVk4B9hZQeCKHW6EKddLicLc+9NPVV0c+zTHlJHI/AY7DCm5ILC5KqSiBBcNChRs0ZYdWxE1Zl6g0s6GnGu2OHtMupdEUHJzvzBbUXbSG3dTVMeVhRyT21yM4+95TtM0q6D4YS9cU9b+I X-Forefront-PRVS: 046985391D X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN6PR05MB3012; 23:2kUZ3nPRndR2j3HQUmgN+XSe7N80N5pxeMwIEwfQO?= =?us-ascii?Q?K1lkehWoyQfZ5JPi741lT5MKpUv9iNSL65j5KQyW6XOVJWS2HONwfcfIqfSE?= =?us-ascii?Q?X3rP+AWhDLjUNoD9Iy1q41+wXnMjt+WVVbBmIiMa9Pegej9c0Up6uW+SkwW/?= =?us-ascii?Q?xy3g+ZeFYewr9SIubJRjBObGfz18JBAq65w17bMGWqDKgWGIOONIMUlICP6S?= =?us-ascii?Q?nHzB6suYMHerPDnLp6SO0bJrzdbzBcMPUDdYkPEnpDJC1Xvon5qON+eLLg4b?= =?us-ascii?Q?teZfEMdqGDIZ8u+dz1t1ehwhzhE5mH34GJk5VLPblVEqmUgAcSAytAXAElwZ?= =?us-ascii?Q?FgrsX/NpsHlzNsiApouwBpr2X0HBQqjzVIvoNYxsjVIBmsl1oDFDSXT4PO1j?= =?us-ascii?Q?Pkw4x8oOrEH9ynwtmZGIwxfN28sK0v84FIbWiUjJaDKTHq/PbJkjQ+gvPwXA?= =?us-ascii?Q?88Gcq/CaqdZ5OgATksOv/8M0M1mdSnzlwO8mr7vlYc3QqEkNvp5ui/sRX6ZY?= =?us-ascii?Q?LPFJvpRwxEOLvPvPlzLE6MU/Jr3lzt83UcKiskck+rkAx/6NQZ1+GKR99cLO?= =?us-ascii?Q?44TsClPe5hJhbt0ixz7O26quxv6tuiy828LGHAMBWj2IYzejCtHcNi4OErad?= =?us-ascii?Q?fwLSCnbesmylClBOl1oC1y0mnMSNXN2hj3tlEiDOs8IQjYyh9wwDbHCHC92+?= =?us-ascii?Q?t6M2AENHyyrudF/pt5KvepDWUItoXqWmxFbolh9NPyoeJa6u4fBqIE3y/i4q?= =?us-ascii?Q?mk/RPKzGdgzDMyVMGdxoayCR/zvLcua7IiDy69S0i5SVsQlFkb9E/TBmnjqQ?= =?us-ascii?Q?+LY99mTiQAifBhMEgwQaRua9yFYprC806c1nU1malK92u8lVxR8XccYN4nm3?= =?us-ascii?Q?cv5PP6ftehtRnrWmE52j9f98Vlm7by2oiY91daNSRch32Wrz+rSAv6Hngg/7?= =?us-ascii?Q?QjWxZSHgq/mpPbVbZLjls+g461gzufGRvs828tB4m5cTudzGF+jaf1RGZQ1V?= =?us-ascii?Q?1Yq4GWEQgdDYImDAHNDiTWL0DxqblpF2QXMZe1v02iBhpukaDCDCoS+MU7sy?= =?us-ascii?Q?05CxxtRzAVguz6+XXg8fcU6x79OGcx6XTunV1IcUx0YHX79E+6OIDJXHFFPC?= =?us-ascii?Q?o7iW9msaqJcJP504Va39qiHDYtg7hkbYaAwmuM0p2g66TBqmGKMICYZ7o3jt?= =?us-ascii?Q?iL/2i00BqaE0TvGte7krSN0SSw+QV7qwaONXwl8S0q2axCNbxliKXUwcqc0s?= =?us-ascii?Q?PbCUo4uXD/lvTZtd0U=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN6PR05MB3012; 6:brZ9nsuRsrOq5KmSpuuGtCM0V4sPmmdUklsBw5odC9hyrLrpzgCvRZuaVbUHf1udppt9z9vACH2/O7GUiSi37A1hZyq6jMXjZVEyQ7Q4wPbwNVxPdx5QNjxE3ibv+0aOMRMVve+tXoM7MbXEIJeDf5PDeleGjXntuvArnvUYezfn9I23w5Fy1snt4uJLTwmdkZaK49Rdm6O9NJVb+VRhMJzfqUju+SSa0itDDttbWAhGKvrw0yqk0kuPCK2Iqyx12CrNEsNNQLa1thXGIos7ZkDYmh4D9p8I7YyzJoomStVpbQOhOsmjGR5NRr1QP11be80j4sesOMva1Bk6b3Y09Q==; 5:Pp9fw2YGFeP9+MRHfff0bvFe5MHIgrPkGmf3BCX92KWRrKQ+PQmrfRb1s53WUOVfUfh5VwXplSNJUVP09vITSmMeVUrLSmr0o0ORvExToCZlcA68q+ys7F0vu1yQZHrunJFeT5M/b6KgCdZxRdaUKw==; 24:X9QyNlQ6eY3+yAS6VWm0qtudtozFOrpr/FKai/+77nEfvvT3WYnzemgcihe4846ZbW3txqmgiwhLV+gSjcw1GdXWyVmVbCmxtjXud2I+a9A=; 7:7i8VKfrFK2EpPAKeAz/eSwcOkYNveEdMGB7gRFL7lhb+KGQqR95fvAV2qZXoFmAdARuMx/lZE9odW5Qo06g7nYTkDW8QRjIISzD0/AiHdUclIzAeOOtNkukX5ynMfPl+GMu9dIgslK9NOvYSeTCMiF9X7fiez81lA+M4ZRYZ/3BEBtNxtl9B+Wj1GVAk/OPfwrjD2/USP7K41EaVskQCm/X3yMnb3RgSZingVXatgCc= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Oct 2017 22:53:05.3702 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ea03b818-4e0d-41cb-a096-08d51a68d2a9 X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR05MB3012 X-Mailman-Approved-At: Tue, 24 Oct 2017 00:49:00 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 22:53:10 -0000 Eric McCorkle wrote: > > Any thoughts on how to validate executables which are not elf binaries, > > such as shell scripts, python programs, etc? > > I hadn't really thought in depth about it, as my main initial goal is > signed kernel/modules, but I have given it some thought... > > An alternative is something like the NetBSD veriexec framework, where Yes, as previously mentioned the verified exec model deals with this neatly, and btw is more efficient than signing individual files - as is needed with ELF signing etc. I think for linux based platforms using IMA we need to generate 20-30k+ signatures, vs about a dozen for platforms using verified exec, verification is also more expensive I'm told. > there's MACs for specific files. That stuff is mostly orthogonal to the > public-key approach I'm working on here, but there's possibly some > interplay. Yes, you use the public key stuff to sign the manifests containing the blessed fingerprints. This is what Junos has been doing for more than a decade. Your "trust" database, might be useful in being able to extend that to general use. The trust model we use for Junos is deliberately very restrictive and thus of most use to embedded vendors. From owner-freebsd-hackers@freebsd.org Tue Oct 24 01:10:33 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F3409E3087A; Tue, 24 Oct 2017 01:10:33 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::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 7E97767434; Tue, 24 Oct 2017 01:10:33 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: by mail-lf0-x234.google.com with SMTP id r129so22123855lff.8; Mon, 23 Oct 2017 18:10:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=ZboOZVl0nIACsuyzxRDNJSmPYeLUor75y7l61mcEXjQ=; b=XMO8Z1GuBMQviChZeFizydHK9VZCDVtOyq4fy9ZeTz8Fat6O9wstwhnRbkMBjLRLyS st54s4KkUll8UGOeSDqDgRzc08m5bZQtC330CNGojrBKbd7zYuuYjKJ2N9UDflAgbDhj AlytCgIfe57I6hSkahZgqi3PkEXImPXSMtasAfh48CsmhvKOzU5xr4pNjj+V8PwaHD1a 3vSmUWn+fY2NrQHcPMQqzTqEqOIw4MFE+3r4TbznaUv5y4Txaqf9x8gvvi5FWuFEvl29 H0HBBZJ4Tfm/Te56n4kL7MDEzCCJC3ckUmSNPUgJV783MouuNbTM7wJ1zwEDTmjCYD/u B8jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=ZboOZVl0nIACsuyzxRDNJSmPYeLUor75y7l61mcEXjQ=; b=cCvPQ2LY8lNpPsnG2fdgZQd619fXDhwDD9HvemKtFOAP+doBkK+LoIyMhXsPhOMuNf qicKbbV3ukNsnkYq8iO/QDp60tycOYDQoLnPP/6/Sy0Qbzey0JJB4ilTqu15jBmAhz0C 73Es8gfjLgrhFM0fE/RQVIvO3FjD3g3w+Qu9dQHebfko3lqXKQ/BYAqPw61ppFLLn6uo oy942FgL1YX/r3xMJwP3uyHJ7169Gd0cDzPG+Qjn+HFadW06+Mth60s4SVgdM58SznUE IaqjwuklNTcxSB3mZmNQpLPBLh7MuikcJja420p+yirwUTf3/wzzLa83QX9ufnr6mZUr eRow== X-Gm-Message-State: AMCzsaXq3sqDGszMsBqrRIf5a/gGBHAH0OLAGEhATdyDnkeOecwd/FRf a3j/29ShlMBAN3rHw3WLP/M= X-Google-Smtp-Source: ABhQp+QytgGuoosSzODoCt+/3qvVlUwAea/azsslwU7ylOzRyJR1cwZYlBC2Dgc13gHslSCLzpQyow== X-Received: by 10.25.41.85 with SMTP id p82mr5897548lfp.186.1508807430911; Mon, 23 Oct 2017 18:10:30 -0700 (PDT) Received: from rimwks ([185.44.68.92]) by smtp.gmail.com with ESMTPSA id n63sm2283888ljb.1.2017.10.23.18.10.29 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 23 Oct 2017 18:10:30 -0700 (PDT) From: Rozhuk Ivan X-Google-Original-From: Rozhuk Ivan Date: Tue, 24 Oct 2017 04:09:25 +0300 To: "Simon J. Gerraty" Cc: Eric McCorkle , "freebsd-hackers@freebsd.org" , freebsd-arch@freebsd.org Subject: Re: Trust system write-up Message-ID: <20171024040925.1918f3cb@rimwks> In-Reply-To: <67125.1508777074@kaos.jnpr.net> References: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.net> <20171023071120.GA72383@blogreen.org> <67125.1508777074@kaos.jnpr.net> X-Mailer: Claws Mail 3.15.1 (GTK+ 2.24.31; amd64-portbld-freebsd11.1) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 01:10:34 -0000 On Mon, 23 Oct 2017 09:44:34 -0700 "Simon J. Gerraty" wrote: > With the advent of secure boot and TPM's, there is potentially scope > to allow for mixed control. TPM is closed hardware and software: you dont know what inside and how it works. Secure boot same crap: closed source with many known security holes. From owner-freebsd-hackers@freebsd.org Mon Oct 23 23:15:38 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E8818E57E77; Mon, 23 Oct 2017 23:15:38 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0090.outbound.protection.outlook.com [104.47.33.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 654E2642F3; Mon, 23 Oct 2017 23:15:37 +0000 (UTC) (envelope-from sjg@juniper.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bpfZjxVg6JF7BOp7G6fWL6NSDMq+OVGKrzQwhZzlddU=; b=EvRYCeqbB16KsODRcu/spbodsBiJgoFJPL8BLBr8WY/Lz4qziQyGCBDEt3bz3LOVbdhNYZka8nblvqaSEpOs9ot358Y9VT9Vqv0mygGYYlNXbL/gt5GwsElvOeKP8c1pKGw3LXLFi9nRRQGwT2Az1bYEAWjcYhtspQbFfgGkWr4= Received: from BY2PR05CA039.namprd05.prod.outlook.com (10.141.250.29) by CY4PR05MB3607.namprd05.prod.outlook.com (10.171.244.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.3; Mon, 23 Oct 2017 23:15:36 +0000 Received: from BY2NAM05FT019.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e52::207) by BY2PR05CA039.outlook.office365.com (2a01:111:e400:2c5f::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.178.2 via Frontend Transport; Mon, 23 Oct 2017 23:15:35 +0000 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by BY2NAM05FT019.mail.protection.outlook.com (10.152.100.156) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256) id 15.20.156.4 via Frontend Transport; Mon, 23 Oct 2017 23:15:35 +0000 Received: from p-mailhub01.juniper.net (10.47.226.20) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 23 Oct 2017 16:15:21 -0700 Received: from kaos.jnpr.net (kaos.jnpr.net [172.21.30.60]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v9NNFK60020696; Mon, 23 Oct 2017 16:15:20 -0700 (envelope-from sjg@juniper.net) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id BF0A2385567; Mon, 23 Oct 2017 16:15:20 -0700 (PDT) To: Eric McCorkle CC: , "freebsd-hackers@freebsd.org" , Subject: Re: Trust system write-up In-Reply-To: <1923f560-debf-b913-5cd0-a349444e451d@metricspace.net> References: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.net> <20171023071120.GA72383@blogreen.org> <67125.1508777074@kaos.jnpr.net> <1923f560-debf-b913-5cd0-a349444e451d@metricspace.net> Comments: In-reply-to: Eric McCorkle message dated "Mon, 23 Oct 2017 18:41:29 -0400." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 25.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <73295.1508800520.1@kaos.jnpr.net> Date: Mon, 23 Oct 2017 16:15:20 -0700 Message-ID: <73296.1508800520@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(376002)(346002)(2980300002)(199003)(24454002)(189002)(305945005)(97756001)(356003)(68736007)(77096006)(8676002)(7696004)(117636001)(229853002)(50466002)(6266002)(6246003)(23726003)(4326008)(107886003)(97736004)(86362001)(55016002)(53936002)(9686003)(5660300001)(16586007)(7126002)(478600001)(105596002)(76176999)(2810700001)(2906002)(316002)(106466001)(76506005)(53416004)(81166006)(50986999)(81156014)(2950100002)(50226002)(8936002)(69596002)(6916009)(93886005)(54906003)(97876018)(47776003)(189998001)(46406003)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR05MB3607; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM05FT019; 1:2qsTOlgJYkWcdIwfd4JOJ+Z2fI0/DqP6KsoqJHXIK05iIQrEzAi+aT59kWO547PgYziBZUnpYzsP8EmdiN1rG9Cx3J2SqwH0tASB1sUNiDQNitH6O1/gCEniIzuAAqoD X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: c120c167-01d1-4cc2-f3be-08d51a6bf777 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603229); SRVR:CY4PR05MB3607; X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3607; 3:Ke37Bm0FJhdwoAQ3N/gfXPDdiLoSK5MONeHntiChzQO8UDlnmqOP9oTnrKQxR8qxeAWLvTc0ESvMyBH4xS3xvo0+eqEP6bDtjih27T0hla/a3HTwOUZ2j0nqp3Spe4QFWORMOzIxEhultzpm88ZQTVVsPgfHaayNWGWVoRAovvo/jJcB5j0o9jRh9477MUTaHQcb7/oXW+4i4WtHWgk1bH+7w9MX/2Upj3bZjITRu/yv0rMNEkC8fUNuPIViy9kvKsrRjz4u1p7kypGzhgSLdJOvt77Jaah6FpLyx7XA4xbfa1iY3XTxFg3hx4puL3pMP4PpwmL0RSFZSUxcBsAlNry3P6ST2IMvfiDLQ22zihw=; 25:fA+uVwwTc1DW27XpA5RTlV9NICwS+LyuU/q5KPjgPwRv+wd6j5LHPYC61+K+mcku6QFXh6KoAxYShMalcaT0VRNOgZZ18omirUIOxo9BZ75AHhI8rwuPlWzADZKY5LcifHmlVmBcgQWfUXg25Nm+g75nBSSZUbNzsGrSFYh9L/dAd8iIhJ3eSxifj6H9g1j5rl/sB3+PeQQNbdjVcZfBOtL5pey1RSgbi6ZJk7no2MoSnhorebolBl2R79Tw7GsLmfdmI6k7aamzZVVsMHh1LvniOYDEumUGUI2/NuZsP29sVNtejFFZ8DKM27w7NXJgzGcvbIwAdPBkIAsVsBEAPA== X-MS-TrafficTypeDiagnostic: CY4PR05MB3607: X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3607; 31:w4CkATwTztXIkm24WZS4QaSAKUuosqfG+6yUujfkduLgzmpYuYBY6S0ljM8Y4eRWSA5P5ALl+pHMUMUWKxGkwdvLY5Wvr2bP0/B2be6pOQw6KqcxGIPcTxWgsXPyqhlM2zbWGEloqQbFum6ACpsTAcwLPKgsE/v41MRILaV8LpOUfzluHwlS2L/8SetY5Le79K23Fwerb4qknpjLqmuukuuXSIqwkmfyHB5JU5d9M9M=; 20:pKJ768HlZkN+1MUMxYoD9scay7IiXewmnDw0gPK+fVosVv5KQcsSOt6Y6Qz1z1ySCBMH0budGBWwKtnXkkd3oM35tLhrhtMIZF0UTQWMBTimtB7w+TzMbyR++FSigVUzFdEiIzH/mTwYCaRcgGOIgRG94o5kEugYhfbaP/UYaJ61VFWlS3PP6vUiTPoNNTrEXeLAP2YEmqd4WdtXB5RnZs2nceb+2dXcpisFYqHchQUj0Ljk8lrlaaqCpAWS25c6jHaDMk4XQjRJUwihxZ3UrPsnStIZ0pPF6bwOwcPKppJ9NnR+ZHPIl8AkVf2LofvezfHf67RHoZl18mocR06HKsyJ4qzNVraiwHK6udY5oTPo3bYoMLMqX8+giqxe9nEOXGnopKrve7KWU+gTFSyN39A66bfytId9JVeaPZmAmwIJhxPEJzhanVsfwo73KlC6Y2+aoyI0SbvUTWL7+bzjMQldhJ4IWoS2882iWvfyhtb1u6Z8PfhPRkpb+lQwWhvi X-Exchange-Antispam-Report-Test: UriScan:; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(3231020)(93006095)(93003095)(100000703101)(100105400095)(3002001)(6055026)(6041248)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123558100)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR05MB3607; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR05MB3607; X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3607; 4:fTcub7/5gis2BZNGIm8GU+uEuCeW0sQ1xicyjd5jLn9RUXhN/Ey0YpOSTQeZFdkWGYFuT8xWOMkk++JXM7RdRyR6uI5TFrC4ONAbYhJyO9pkxqNYRIhFopWLRh10ADuSMS6AhE0PkOl+5hmc76O+5HwW4eq7cVR1iVGvAaZexEgwFTJ9exvLXGnn21xHjpmQ8cTqlS3MYJveqX3JHrG9WkKFhMrsE/o7z2AsSNQ6RbDnp1XXQhmET3P0N5qMOQt9TPaGpW2BneXW2MNyLnK5VA== X-Forefront-PRVS: 046985391D X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY4PR05MB3607; 23:YsvxPENMmT8Gpb1zvih/+oVZxEngBMkJIht/cNBFe?= =?us-ascii?Q?ilKTnvY6ZBy1G5JsA0Zjl0jthrl7l0Nq7uc4nQC7UnCg64YPJau4ZjlccCMs?= =?us-ascii?Q?zu6VFZCxP5IGpH4B9+s502Q1555J7TVnJNYWg2Mh087IVAGWN4KkFzYA1ME7?= =?us-ascii?Q?VIW7kz6N++dKfk/pFCn7upGXn15W6hxkKTyWKwnvFraxOLzaT08D79W5R2UQ?= =?us-ascii?Q?o45mEjy0J4CmF0qvW/WqOW8yjLJbHOs259rIqF4PHd+N/vbRBvKBZkw2iKv7?= =?us-ascii?Q?nnQXrysxtW2IiN7Yxa1edvx7HYdNexD2JmFrCnR7kdPB172VqO8W8+fSJbtY?= =?us-ascii?Q?cqdYxjAfworKzB6Ysp8wHvXAdP2yjrNz4TxMW3tORk2/FYO5nU7l5DrNjijX?= =?us-ascii?Q?VYMA5W4JRljmB2lf3q6Rh0SaRkZimSXSY0e2yn7Hv4mp+XmmdJv/VVEGDLYY?= =?us-ascii?Q?Kkf9bmcxVzgFeAK4pr8XRcB5CjjiJ2h1t16TC2SSeH2aWrQ/on6alz97YdJD?= =?us-ascii?Q?4/YsDzmkNy/cZ8iB0x4MCV2WGK9wHkXAy3pctpxxnB2b8ziQaZXJH2cnt/7z?= =?us-ascii?Q?Mzezt+YQ2v7wutzlY6OV8bzx6oJ092QV3jyxGd2Nkt2rWYEv6hDoeTp0y2XR?= =?us-ascii?Q?KWjcVUA0dDIWKvmq31goj5ZfOQu+Iv/J9ls80TAkLwLVBFuWpW1LjEulG0at?= =?us-ascii?Q?DmGRw7cB7X9Ag2dJlzNacQD2lPVp9Or5bbByI3D9AhXMCMNobPlttqK1ziW6?= =?us-ascii?Q?t4+Jwzij8b12Iz06hqJWvCSe7CPvKIiaKwNe8i3xmtfP0qRR8s88XzT88uEq?= =?us-ascii?Q?XoyjBxC9pWgLCbv0v1d8nO52X7ya0zQoO40JhVTxzWcXHnM/I9OZiuqoIs2o?= =?us-ascii?Q?yN0zbJN7/gxyW8O3E0Yexh0CNXJnWq7qwKdA70Jk6nPVqAYWq+r174XVtCnE?= =?us-ascii?Q?FLfhV00NGNm8Z0JhYiOME/M20gAObcJMb4Va/e9XRWmWTJtQACgCmS9fvYVz?= =?us-ascii?Q?1H25WMDJjEqMYR8BMhEi3TC0Nxk1FZDZjIZicv2tVKK5QsKACX40VmYpCof+?= =?us-ascii?Q?KJeMjpkKgHDMzil/Op2NXWQSHQywpHua7FzvZRa2pDYxnQYBaoLjBtLAyix1?= =?us-ascii?Q?G3uIsGJxZlUvLTQpPo+rIRJHTJUOCI4RIfYzZjyrwHL+hET69tLSzZl5LkgP?= =?us-ascii?Q?qNLfoksRsA21fjeSCZlNhjJjnleP+NFCK30yrh/HenDW1rmC9lNQ77CLhucl?= =?us-ascii?Q?UVTf3RM48gONZflJ+UkMXTnk0Tfwcdn4Apx2N6Y?= X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3607; 6:lz9gbF0F+5OylRqbfc8oPxH948Av9NuOfaJQps+1DXlh+Uh3OP1OZ9ccXTFe8ROpPD0Q+HBJrUAEULyw2Ow7JQ5sM61cB1yRug00D2ONCFberHsv/xvh2dYca5J8eGmGDdJXKXg5xn34n1vmY1SSAsg4ZRptunlRs899AnGYS613Vp5GgMUMldt1j43Yo2crFTDHZ511Uf7IUk6jksI0VB52+ITSjYfywh4+5+D1kjsWJT1tibt2hd3M009z0KBzUuMNRl6pTsUs8Q6d/rQ4+SnfytjLvuqISP81osg67hWybDOcTe/71KFHhPFfm3UuSMA+iCeB6S6ZQtd9Tf1FqB6M47bPFbwYfE6rozY8vRA=; 5:3sOP3j/SLDeWbhkveNegUpRxiMcXhV6/ZydgjsCySBjxeolM3Hj8xAXLtVK4Izb8QKXYlzrZ4Gppf81jQo5L+3w6S9QXfmUde+UYY4m2JV2AS8hXJrS7kp6BZvb3EhxXiu/tyOFRWLfQfivgm6JJ/gqUkogdhWEzYu5Ouxae8Ss=; 24:0BsSYP8Z/mkLYLzox5cgUQB1JRpZdzxsp88sr6RpnsLLdguDKByay5/Fr91iTD0E2/hHmiODGDekFaRkx/zvGaIOayFAKFyXkEnAlUr+Ouw=; 7:UPbTzekTAoSi1edcY34dABn6cEOpzCGvDK2XvOb/HQq+B5bmcfl0ERSbhm7NNRZOLUegTbVcBjgN9toOFPYSXR0qsH5Meqvib9KBghOaRGHuk3N/iUGarlvj0pbct82UsDkt/KwlJFGrWM9EUNe1SjEg/wHNuc2vl1o1rvg9atbfccmQXVY1Y+L8wuzg0d+ktveIO0Hv9QN3Net1LUrpLTiZ0l/QbG+9CQhMamosbx6fTLknsfkHA9bVNxI7X5gl SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Oct 2017 23:15:35.6261 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c120c167-01d1-4cc2-f3be-08d51a6bf777 X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB3607 X-Mailman-Approved-At: Tue, 24 Oct 2017 01:41:07 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 23:15:39 -0000 Eric McCorkle wrote: > I'm a bit less enthusiastic about veriexec in the loader. The problem > there is it requires an update to the loader every single time you build > a new kernel, whereas the public key approach only needs updating if you No, that's exactly what you don't need to do. The whole advantage of the loader changes I've done is the flexibility of verification. One loader binary can be used to load any Junos release we've built in the last decade or the next. The only time we need a new loader binary, is if some code in the loader needs to change - or a new rootCA needs to be supported. The root CA is the only key the loader needs to know. The signed manifests have an associated certificate chain used for verification - exactly as we do for normal veriexec. > change root keys. (That's really the key difference: veriexec is an > anti-tampering mechanism, where the trust system I've described is a > trust-delegation mechanism). Take a closer look, the veriexec manifests can convey additional information to the kernel (not relevant to loader of course), which we've made use of to allow apps signed by keys given to 3rd parties to be run given suitable configuration. We can also assign labels to apps as a side effect of verification - labels that other mac modules can use. --sjg From owner-freebsd-hackers@freebsd.org Tue Oct 24 03:43:55 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 09E87E3B113 for ; Tue, 24 Oct 2017 03:43:55 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-164.reflexion.net [208.70.211.164]) (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 BC80E6D97E for ; Tue, 24 Oct 2017 03:43:53 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 15101 invoked from network); 24 Oct 2017 03:43:52 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 24 Oct 2017 03:43:52 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Mon, 23 Oct 2017 23:43:52 -0400 (EDT) Received: (qmail 22553 invoked from network); 24 Oct 2017 03:43:52 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 24 Oct 2017 03:43:52 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 6EAD9EC7848; Mon, 23 Oct 2017 20:43:51 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: BPI-M3 booted via a variant of head -r324743 with an external ECHI USB root file system: what I changed to have it happen Date: Mon, 23 Oct 2017 20:43:50 -0700 References: <3AD6B1F8-512C-43BB-AC76-7721454AD02F@dsl-only.net> <20171021195812.5bdb902401b8e756b6abfe40@bidouilliste.com> <20171021204356.47e3cd6066144bcd07f46699@bidouilliste.com> <50728566-11C2-45EB-8367-00CAF38D4548@dsl-only.net> <8696CCFA-AE7D-4324-90A8-BB73402FA124@dsl-only.net> <06B9A4AD-EA28-41A8-91B9-FE368EF622FE@dsl-only.net> <68CB464E-6FC6-4CB9-963B-9E7A683041EB@dsl-only.net> To: Emmanuel Vadot , freebsd-arm , freebsd-hackers In-Reply-To: Message-Id: <17D6B79E-F7AF-4395-B8A2-2CE9A5157ABF@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 03:43:55 -0000 [This largely ignores my questions about mp_ncpu <=3D cpuid happening when there are 4 unused cores (of 8), as there are for the BPI-M3's A83T support.] For head -r324743, by making: sys/boot/fdt/dts/arm/a83t.dtsi slightly more modern (reg-names, phy_ctrl, pmu0, and pmu1) and putting in my guesses for A83T in: /usr/src/sys/arm/allwinner/aw_usbphy.c I've gotten -r324743 to boot with a root file system on an external USB drive in ECHI mode. I've tried both USB ports and both have worked as ECHI for this. The changes: # svnlite diff /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi Index: /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi (revision 324743) +++ /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi (working copy) @@ -179,6 +179,9 @@ reg =3D <0x01c19400 0x2c>, <0x01c1a800 0x4>, <0x01c1b800 0x4>; + reg-names =3D "phy_ctrl", + "pmu0", + "pmu1"; clocks =3D <&usb_clk 8>, <&usb_clk 9>, <&usb_clk 10>, Other than some include file usage, the BPI-M3 is not and has not been using sys/gnu/dts/ files. The above makes the .dtb that FreeBSD produces be something that the modern kernel will not reject parts of. # svnlite diff /usr/src*/sys/arm/allwinner/aw_usbphy.c Index: /usr/src/sys/arm/allwinner/aw_usbphy.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/arm/allwinner/aw_usbphy.c (revision 324743) +++ /usr/src/sys/arm/allwinner/aw_usbphy.c (working copy) @@ -58,6 +58,7 @@ AWUSBPHY_TYPE_A13, AWUSBPHY_TYPE_A20, AWUSBPHY_TYPE_A31, + AWUSBPHY_TYPE_A83T, AWUSBPHY_TYPE_H3, AWUSBPHY_TYPE_A64 }; @@ -90,6 +91,13 @@ .phy0_route =3D false, }; =20 +static const struct aw_usbphy_conf a83t_usbphy_conf =3D { + .num_phys =3D 3, // SATA via USB bridge as well + .phy_type =3D AWUSBPHY_TYPE_A83T, + .pmu_unk1 =3D false, // ???? + .phy0_route =3D true, // ???? +}; + static const struct aw_usbphy_conf a31_usbphy_conf =3D { .num_phys =3D 3, .phy_type =3D AWUSBPHY_TYPE_A31, @@ -116,6 +124,7 @@ { "allwinner,sun5i-a13-usb-phy", = (uintptr_t)&a13_usbphy_conf }, { "allwinner,sun6i-a31-usb-phy", = (uintptr_t)&a31_usbphy_conf }, { "allwinner,sun7i-a20-usb-phy", = (uintptr_t)&a20_usbphy_conf }, + { "allwinner,sun8i-a83t-usb-phy", = (uintptr_t)&a83t_usbphy_conf }, { "allwinner,sun8i-h3-usb-phy", = (uintptr_t)&h3_usbphy_conf }, { "allwinner,sun50i-a64-usb-phy", = (uintptr_t)&a64_usbphy_conf }, { NULL, 0 } The SATA is why there are 3 USB phys for the BPI-M3 instead of 2. The root filesystem is on: da0: Fixed Direct Access SPC-4 SCSI device da0: Serial Number da0: 40.000MB/s transfers da0: 228936MB (468862128 512 byte sectors) da0: quirks=3D0x2 One new thing is: module_register: cannot register simplebus/ahci from kernel; already = loaded from kernel Module simplebus/ahci failed to register: 17 module_register: cannot register simplebus/ehci from kernel; already = loaded from kernel Module simplebus/ehci failed to register: 17 module_register: cannot register simplebus/pcib from kernel; already = loaded from kernel Module simplebus/pcib failed to register: 17 module_register: cannot register simplebus/ehci from kernel; already = loaded from kernel Module simplebus/ehci failed to register: 17 I've not figured out what those messages are about yet. There is also: real memory =3D 2147483648 (2048 MB) avail memory =3D 2089332736 (1992 MB) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs vs. cpulist0: on ofwbus0 cpu0: on cpulist0 cpufreq_dt0: on cpu0 cpu1: on cpulist0 cpu2: on cpulist0 cpu3: on cpulist0 cpu4: on cpulist0 cpufreq_dt1: on cpu4 cpufreq_dt1: no regulator for cpu@100 device_attach: cpufreq_dt1 attach returned 6 cpu5: on cpulist0 cpu6: on cpulist0 cpu7: on cpulist0 My understanding is: only the first cluster of 4 cores is supposed to be active/used and the 2nd cluster is supposed to not be in active use. I'm not sure that the 2nd cluster is being handled as intended, or what the intended details are. But top does show only 4. An old thing is still true: a10_mmc1: error rint: 0x00000100 a10_mmc1: error rint: 0x00000100 a10_mmc1: error rint: 0x00000100 a10_mmc1: error rint: 0x00000100 a10_mmc1: error rint: 0x00000100 a10_mmc1: error rint: 0x00000100 a10_mmc1: error rint: 0x00000100 a10_mmc1: error rint: 0x00000100 a10_mmc1: error rint: 0x00008018 a10_mmc1: error rint: 0x00000100 a10_mmc1: error rint: 0x00000100 a10_mmc1: error rint: 0x00000100 a10_mmc1: error rint: 0x00000100 mmcsd1: 8GB at = mmc1 52.0MHz/8bit/65535-block mmcsd1boot0: 4MB partion 1 at mmcsd1 mmcsd1boot1: 4MB partion 2 at mmcsd1 mmcsd1rpmb: 524kB partion 3 at mmcsd1 FYI: # uname -apKU FreeBSD bpim3 12.0-CURRENT FreeBSD 12.0-CURRENT r324743M arm armv7 = 1200051 1200051 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Tue Oct 24 08:50:27 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D8001E44F2D; Tue, 24 Oct 2017 08:50:27 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2BF1F75F59; Tue, 24 Oct 2017 08:50:26 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 7d9d1fd1; Tue, 24 Oct 2017 10:50:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=4KV1VlfbFp64nsPuEcpgvb0uLjE=; b=JSVxGr+lLUn3wJc1xTX6nPZkx447 030ESUN+SORyrS3umMSUId1TY1xeyHPWnPiDS7qfps0bn4EaU/ei9oVSVQBdCUOA FnEHp3hc6hs0z1PmTMvjFO2ga/gS1L8Ly2e3vkMlDb8Zpa+g1N0+IsJraFphHIGp 9PokqN7K8do/mPU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=gGz7GQh++5CLyaMqH5xwDCrEOMmuIjHvFXjPrCVuUevHtSBNpA8oqJe8 j9464gZ/PwXFYzmqK4VGQzJBqNFB8kwxD7aY33a0Tn7EhgQJMGts2OA5S8D7vHlq XoEsRGlKulSp7Q8vC2Bgpq0VlbmBEG2nsyKjE/1SUVeGg5wVV/M= Received: from arcadia (evadot.gandi.net [217.70.181.36]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 13f4c937 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Tue, 24 Oct 2017 10:50:15 +0200 (CEST) Date: Tue, 24 Oct 2017 10:50:14 +0200 From: Emmanuel Vadot To: Mark Millard Cc: freebsd-arm , freebsd-hackers Subject: Re: BPI-M3 booted via a variant of head -r324743 with an external ECHI USB root file system: what I changed to have it happen Message-Id: <20171024105014.cd2012898a602408ee605183@bidouilliste.com> In-Reply-To: <17D6B79E-F7AF-4395-B8A2-2CE9A5157ABF@dsl-only.net> References: <3AD6B1F8-512C-43BB-AC76-7721454AD02F@dsl-only.net> <20171021195812.5bdb902401b8e756b6abfe40@bidouilliste.com> <20171021204356.47e3cd6066144bcd07f46699@bidouilliste.com> <50728566-11C2-45EB-8367-00CAF38D4548@dsl-only.net> <8696CCFA-AE7D-4324-90A8-BB73402FA124@dsl-only.net> <06B9A4AD-EA28-41A8-91B9-FE368EF622FE@dsl-only.net> <68CB464E-6FC6-4CB9-963B-9E7A683041EB@dsl-only.net> <17D6B79E-F7AF-4395-B8A2-2CE9A5157ABF@dsl-only.net> X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 08:50:28 -0000 Top posting as there is too much stuff in that mail. I find it really hard to understand you mail as there is too much data in it. But, to clarify the A83T situation (And general info on Allwinner clocks) : - Old Linux DTS (~4.8 iirc) for Allwinner SoCs had the clock directly defined in them under a /clock nodes, with jmcneill@ we added support for most (if not all) of them and this supported every Allwinner SoCs. - With the H3 DTS added things started to change, they removed the /clock node and simply add a ccu node (Clock Control Unit) as it's commonly done in ARM DTS. - This move a lot of information from the DTS to the kernel driver for the CCU. - Around that time the first H3 dts that was written (but not added in the Linux repository) was from the model, with the /clock node. And we added those file in FreeBSD under sys/boot/fdt/dts - I finally wrote a driver for the new clock ccu driver and currently it support H3, A64 and A31. - Linux started to convert old SoCs from /clock to ccu (A13 is done, A83T too and for A10 and A20 it will be available in 4.15 iirc) - I don't want us (us = FreeBSD) to derive from the Linux DTS as it's a pain to maintain, every change should be sent to Linux directly (it's really not that hard). So, that being said, what needs to be done for A83T support to stay in FreeBSD is adding a ccu driver for it. With the clkng stuff I did (see sys/arm/allwinner/clkng) it's not that hard, it's just a matter of reading the user manual clock section and translate table to macros/struct. You can have a look at H3 (or any other ccu driver) to see how it's done. As of today support for A83T and A13 don't work anymore if you use the current DTS, I've started working on A13 and should commit the driver soon. Someone with A83T should do the same. Cheers, On Mon, 23 Oct 2017 20:43:50 -0700 Mark Millard wrote: > [This largely ignores my questions about > mp_ncpu <= cpuid happening when there are > 4 unused cores (of 8), as there are for > the BPI-M3's A83T support.] > > For head -r324743, by making: > > sys/boot/fdt/dts/arm/a83t.dtsi > > slightly more modern (reg-names, phy_ctrl, > pmu0, and pmu1) and putting in my guesses > for A83T in: > > /usr/src/sys/arm/allwinner/aw_usbphy.c > > I've gotten -r324743 to boot with a root > file system on an external USB drive in > ECHI mode. I've tried both USB ports and > both have worked as ECHI for this. > > The changes: > > # svnlite diff /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi > Index: /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi > =================================================================== > --- /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi (revision 324743) > +++ /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi (working copy) > @@ -179,6 +179,9 @@ > reg = <0x01c19400 0x2c>, > <0x01c1a800 0x4>, > <0x01c1b800 0x4>; > + reg-names = "phy_ctrl", > + "pmu0", > + "pmu1"; > clocks = <&usb_clk 8>, > <&usb_clk 9>, > <&usb_clk 10>, > > Other than some include file usage, the BPI-M3 is > not and has not been using sys/gnu/dts/ files. The > above makes the .dtb that FreeBSD produces be > something that the modern kernel will not reject > parts of. > > # svnlite diff /usr/src*/sys/arm/allwinner/aw_usbphy.c > Index: /usr/src/sys/arm/allwinner/aw_usbphy.c > =================================================================== > --- /usr/src/sys/arm/allwinner/aw_usbphy.c (revision 324743) > +++ /usr/src/sys/arm/allwinner/aw_usbphy.c (working copy) > @@ -58,6 +58,7 @@ > AWUSBPHY_TYPE_A13, > AWUSBPHY_TYPE_A20, > AWUSBPHY_TYPE_A31, > + AWUSBPHY_TYPE_A83T, > AWUSBPHY_TYPE_H3, > AWUSBPHY_TYPE_A64 > }; > @@ -90,6 +91,13 @@ > .phy0_route = false, > }; > > +static const struct aw_usbphy_conf a83t_usbphy_conf = { > + .num_phys = 3, // SATA via USB bridge as well > + .phy_type = AWUSBPHY_TYPE_A83T, > + .pmu_unk1 = false, // ???? > + .phy0_route = true, // ???? > +}; > + > static const struct aw_usbphy_conf a31_usbphy_conf = { > .num_phys = 3, > .phy_type = AWUSBPHY_TYPE_A31, > @@ -116,6 +124,7 @@ > { "allwinner,sun5i-a13-usb-phy", (uintptr_t)&a13_usbphy_conf }, > { "allwinner,sun6i-a31-usb-phy", (uintptr_t)&a31_usbphy_conf }, > { "allwinner,sun7i-a20-usb-phy", (uintptr_t)&a20_usbphy_conf }, > + { "allwinner,sun8i-a83t-usb-phy", (uintptr_t)&a83t_usbphy_conf }, > { "allwinner,sun8i-h3-usb-phy", (uintptr_t)&h3_usbphy_conf }, > { "allwinner,sun50i-a64-usb-phy", (uintptr_t)&a64_usbphy_conf }, > { NULL, 0 } > > The SATA is why there are 3 USB phys for the BPI-M3 > instead of 2. > > The root filesystem is on: > > da0: Fixed Direct Access SPC-4 SCSI device > da0: Serial Number > da0: 40.000MB/s transfers > da0: 228936MB (468862128 512 byte sectors) > da0: quirks=0x2 > > > One new thing is: > > module_register: cannot register simplebus/ahci from kernel; already loaded from kernel > Module simplebus/ahci failed to register: 17 > module_register: cannot register simplebus/ehci from kernel; already loaded from kernel > Module simplebus/ehci failed to register: 17 > module_register: cannot register simplebus/pcib from kernel; already loaded from kernel > Module simplebus/pcib failed to register: 17 > module_register: cannot register simplebus/ehci from kernel; already loaded from kernel > Module simplebus/ehci failed to register: 17 > > I've not figured out what those messages are > about yet. > > There is also: > > real memory = 2147483648 (2048 MB) > avail memory = 2089332736 (1992 MB) > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > > vs. > > cpulist0: on ofwbus0 > cpu0: on cpulist0 > cpufreq_dt0: on cpu0 > cpu1: on cpulist0 > cpu2: on cpulist0 > cpu3: on cpulist0 > cpu4: on cpulist0 > cpufreq_dt1: on cpu4 > cpufreq_dt1: no regulator for cpu@100 > device_attach: cpufreq_dt1 attach returned 6 > cpu5: on cpulist0 > cpu6: on cpulist0 > cpu7: on cpulist0 > > My understanding is: only the first cluster > of 4 cores is supposed to be active/used > and the 2nd cluster is supposed to not > be in active use. I'm not sure that the > 2nd cluster is being handled as intended, > or what the intended details are. But > top does show only 4. > > An old thing is still true: > > a10_mmc1: error rint: 0x00000100 > a10_mmc1: error rint: 0x00000100 > a10_mmc1: error rint: 0x00000100 > a10_mmc1: error rint: 0x00000100 > a10_mmc1: error rint: 0x00000100 > a10_mmc1: error rint: 0x00000100 > a10_mmc1: error rint: 0x00000100 > a10_mmc1: error rint: 0x00000100 > a10_mmc1: error rint: 0x00008018 > a10_mmc1: error rint: 0x00000100 > a10_mmc1: error rint: 0x00000100 > a10_mmc1: error rint: 0x00000100 > a10_mmc1: error rint: 0x00000100 > mmcsd1: 8GB at mmc1 52.0MHz/8bit/65535-block > mmcsd1boot0: 4MB partion 1 at mmcsd1 > mmcsd1boot1: 4MB partion 2 at mmcsd1 > mmcsd1rpmb: 524kB partion 3 at mmcsd1 > > > FYI: > > # uname -apKU > FreeBSD bpim3 12.0-CURRENT FreeBSD 12.0-CURRENT r324743M arm armv7 1200051 1200051 > > > > === > Mark Millard > markmi at dsl-only.net > > > _______________________________________________ > 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" -- Emmanuel Vadot From owner-freebsd-hackers@freebsd.org Tue Oct 24 09:16:44 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1F52DE45F37; Tue, 24 Oct 2017 09:16:44 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from cu01176b.smtpx.saremail.com (cu01176b.smtpx.saremail.com [195.16.151.151]) (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 D858676FA1; Tue, 24 Oct 2017 09:16:43 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from [172.16.8.41] (unknown [192.148.167.11]) by proxypop01.sare.net (Postfix) with ESMTPA id 79D5D9DDD5E; Tue, 24 Oct 2017 11:07:32 +0200 (CEST) From: Borja Marcos Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) Subject: Periodic jobs lockf timeout Message-Id: Date: Tue, 24 Oct 2017 11:07:31 +0200 Cc: freebsd-security@freebsd.org To: freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3445.1.7) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 09:16:44 -0000 Hi, I=E2=80=99ve come across a problem with the =E2=80=9Cdaily=E2=80=9D = security job. On an overloaded system with lots of ZFS datasets, lots of files, heavy system load and, to add insult to injury, a ZFS = crub going on the find=E2=80=99s issued by the periodic checks can take forever. They can take so long, I have found = several lockf=E2=80=99s waiting. Is it sane to have an unlimited timeout for lockf? Probably it would be = better to have at least a configurable timeout for each cathegory. It=E2=80=99s really unlikely to see an = overlap for a weekly or monthly job, but for daily jobs it would be good to have a sane default, say, an hour or two. There=E2=80=99s even a parameter on /etc/defaults/periodic.conf but it = seems it=E2=80=99s not used right now. # Max time to sleep to avoid causing congestion on download servers anticongestion_sleeptime=3D3600 The alternative would be to have defaults for a sane timeout for each = cathegory, like daily_lockf_timeout weekly_lockf_timeout monthly_lockf_timeout Thoughts? It=E2=80=99s pretty simple to do and overlapping periodic jobs = are really useless. Borja. From owner-freebsd-hackers@freebsd.org Tue Oct 24 10:03:29 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 667E2E47A33 for ; Tue, 24 Oct 2017 10:03:29 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-164.reflexion.net [208.70.211.164]) (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 2619F7D01C for ; Tue, 24 Oct 2017 10:03:28 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 11200 invoked from network); 24 Oct 2017 10:03:27 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 24 Oct 2017 10:03:27 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Tue, 24 Oct 2017 06:03:27 -0400 (EDT) Received: (qmail 9082 invoked from network); 24 Oct 2017 10:03:27 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 24 Oct 2017 10:03:27 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 998DAEC91A3; Tue, 24 Oct 2017 03:03:26 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: BPI-M3 booted via a variant of head -r324743 with an external ECHI USB root file system: what I changed to have it happen From: Mark Millard In-Reply-To: <20171024105014.cd2012898a602408ee605183@bidouilliste.com> Date: Tue, 24 Oct 2017 03:03:25 -0700 Cc: freebsd-arm , freebsd-hackers Content-Transfer-Encoding: quoted-printable Message-Id: References: <3AD6B1F8-512C-43BB-AC76-7721454AD02F@dsl-only.net> <20171021195812.5bdb902401b8e756b6abfe40@bidouilliste.com> <20171021204356.47e3cd6066144bcd07f46699@bidouilliste.com> <50728566-11C2-45EB-8367-00CAF38D4548@dsl-only.net> <8696CCFA-AE7D-4324-90A8-BB73402FA124@dsl-only.net> <06B9A4AD-EA28-41A8-91B9-FE368EF622FE@dsl-only.net> <68CB464E-6FC6-4CB9-963B-9E7A683041EB@dsl-only.net> <17D6B79E-F7AF-4395-B8A2-2CE9A5157ABF@dsl-only.net> <20171024105014.cd2012898a602408ee605183@bidouilliste.com> To: Emmanuel Vadot X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 10:03:29 -0000 [Top post.] Thanks for the notes. I'm gradually figuring a little bit out. Looking in: https://svnweb.freebsd.org/base/head/sys/gnu/dts/arm/?dir_pagestart=3D1000= (the linux 4.13 update) I see: sun6i-a31s-sinovoip-bpi-m2.dts but no .dts directly for the bpi-m3. So, it appears that the outer layer (.dts) does not have a Linux 4.13 or earlier version to be based on. There is an include file: sun8i-a83t.dtsi Unlike, say, sun6i-a31.dtsi, sun8i-a83t.dtsi does not seem to have, for example, usb material. There are A83T examples: sun8i-a83t-allwinner-h8homlet-v2.dts sun8i-a83t-cubietruck-plus.dts (But, also no usb material.) It looks to me like somewhat more than the ccu driver is needed to in order for the bpi-m3 to meet your criteria for staying in FreeBSD, and possibly even more to support things such as usb. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2017-Oct-24, at 1:50 AM, Emmanuel Vadot = wrote: > Top posting as there is too much stuff in that mail. >=20 > I find it really hard to understand you mail as there is too much data > in it. >=20 > But, to clarify the A83T situation (And general info on Allwinner > clocks) : >=20 > - Old Linux DTS (~4.8 iirc) for Allwinner SoCs had the clock directly > defined in them under a /clock nodes, with jmcneill@ we added support > for most (if not all) of them and this supported every Allwinner SoCs. > - With the H3 DTS added things started to change, they removed > the /clock node and simply add a ccu node (Clock Control Unit) as it's > commonly done in ARM DTS. > - This move a lot of information from the DTS to the kernel driver for > the CCU. > - Around that time the first H3 dts that was written (but not added in > the Linux repository) was from the model, with the /clock node. And we > added those file in FreeBSD under sys/boot/fdt/dts > - I finally wrote a driver for the new clock ccu driver and currently > it support H3, A64 and A31. > - Linux started to convert old SoCs from /clock to ccu (A13 is done, > A83T too and for A10 and A20 it will be available in 4.15 iirc) > - I don't want us (us =3D FreeBSD) to derive from the Linux DTS as = it's > a pain to maintain, every change should be sent to Linux directly = (it's > really not that hard). >=20 > So, that being said, what needs to be done for A83T support to stay in > FreeBSD is adding a ccu driver for it. With the clkng stuff I did (see > sys/arm/allwinner/clkng) it's not that hard, it's just a matter of > reading the user manual clock section and translate table to > macros/struct. You can have a look at H3 (or any other ccu driver) to > see how it's done. > As of today support for A83T and A13 don't work anymore if you use > the current DTS, I've started working on A13 and should commit the > driver soon. Someone with A83T should do the same.=20 >=20 > Cheers, >=20 > On Mon, 23 Oct 2017 20:43:50 -0700 > Mark Millard wrote: >=20 >> [This largely ignores my questions about >> mp_ncpu <=3D cpuid happening when there are >> 4 unused cores (of 8), as there are for >> the BPI-M3's A83T support.] >>=20 >> For head -r324743, by making: >>=20 >> sys/boot/fdt/dts/arm/a83t.dtsi >>=20 >> slightly more modern (reg-names, phy_ctrl, >> pmu0, and pmu1) and putting in my guesses >> for A83T in: >>=20 >> /usr/src/sys/arm/allwinner/aw_usbphy.c >>=20 >> I've gotten -r324743 to boot with a root >> file system on an external USB drive in >> ECHI mode. I've tried both USB ports and >> both have worked as ECHI for this. >>=20 >> The changes: >>=20 >> # svnlite diff /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi >> Index: /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi (revision 324743) >> +++ /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi (working copy) >> @@ -179,6 +179,9 @@ >> reg =3D <0x01c19400 0x2c>, >> <0x01c1a800 0x4>, >> <0x01c1b800 0x4>; >> + reg-names =3D "phy_ctrl", >> + "pmu0", >> + "pmu1"; >> clocks =3D <&usb_clk 8>, >> <&usb_clk 9>, >> <&usb_clk 10>, >>=20 >> Other than some include file usage, the BPI-M3 is >> not and has not been using sys/gnu/dts/ files. The >> above makes the .dtb that FreeBSD produces be >> something that the modern kernel will not reject >> parts of. >>=20 >> # svnlite diff /usr/src*/sys/arm/allwinner/aw_usbphy.c >> Index: /usr/src/sys/arm/allwinner/aw_usbphy.c >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- /usr/src/sys/arm/allwinner/aw_usbphy.c (revision 324743) >> +++ /usr/src/sys/arm/allwinner/aw_usbphy.c (working copy) >> @@ -58,6 +58,7 @@ >> AWUSBPHY_TYPE_A13, >> AWUSBPHY_TYPE_A20, >> AWUSBPHY_TYPE_A31, >> + AWUSBPHY_TYPE_A83T, >> AWUSBPHY_TYPE_H3, >> AWUSBPHY_TYPE_A64 >> }; >> @@ -90,6 +91,13 @@ >> .phy0_route =3D false, >> }; >>=20 >> +static const struct aw_usbphy_conf a83t_usbphy_conf =3D { >> + .num_phys =3D 3, // SATA via USB bridge as well >> + .phy_type =3D AWUSBPHY_TYPE_A83T, >> + .pmu_unk1 =3D false, // ???? >> + .phy0_route =3D true, // ???? >> +}; >> + >> static const struct aw_usbphy_conf a31_usbphy_conf =3D { >> .num_phys =3D 3, >> .phy_type =3D AWUSBPHY_TYPE_A31, >> @@ -116,6 +124,7 @@ >> { "allwinner,sun5i-a13-usb-phy", = (uintptr_t)&a13_usbphy_conf }, >> { "allwinner,sun6i-a31-usb-phy", = (uintptr_t)&a31_usbphy_conf }, >> { "allwinner,sun7i-a20-usb-phy", = (uintptr_t)&a20_usbphy_conf }, >> + { "allwinner,sun8i-a83t-usb-phy", = (uintptr_t)&a83t_usbphy_conf }, >> { "allwinner,sun8i-h3-usb-phy", = (uintptr_t)&h3_usbphy_conf }, >> { "allwinner,sun50i-a64-usb-phy", = (uintptr_t)&a64_usbphy_conf }, >> { NULL, 0 } >>=20 >> The SATA is why there are 3 USB phys for the BPI-M3 >> instead of 2. >>=20 >> The root filesystem is on: >>=20 >> da0: Fixed Direct Access SPC-4 SCSI device >> da0: Serial Number >> da0: 40.000MB/s transfers >> da0: 228936MB (468862128 512 byte sectors) >> da0: quirks=3D0x2 >>=20 >>=20 >> One new thing is: >>=20 >> module_register: cannot register simplebus/ahci from kernel; already = loaded from kernel >> Module simplebus/ahci failed to register: 17 >> module_register: cannot register simplebus/ehci from kernel; already = loaded from kernel >> Module simplebus/ehci failed to register: 17 >> module_register: cannot register simplebus/pcib from kernel; already = loaded from kernel >> Module simplebus/pcib failed to register: 17 >> module_register: cannot register simplebus/ehci from kernel; already = loaded from kernel >> Module simplebus/ehci failed to register: 17 >>=20 >> I've not figured out what those messages are >> about yet. >>=20 >> There is also: >>=20 >> real memory =3D 2147483648 (2048 MB) >> avail memory =3D 2089332736 (1992 MB) >> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs >>=20 >> vs. >>=20 >> cpulist0: on ofwbus0 >> cpu0: on cpulist0 >> cpufreq_dt0: on cpu0 >> cpu1: on cpulist0 >> cpu2: on cpulist0 >> cpu3: on cpulist0 >> cpu4: on cpulist0 >> cpufreq_dt1: on cpu4 >> cpufreq_dt1: no regulator for cpu@100 >> device_attach: cpufreq_dt1 attach returned 6 >> cpu5: on cpulist0 >> cpu6: on cpulist0 >> cpu7: on cpulist0 >>=20 >> My understanding is: only the first cluster >> of 4 cores is supposed to be active/used >> and the 2nd cluster is supposed to not >> be in active use. I'm not sure that the >> 2nd cluster is being handled as intended, >> or what the intended details are. But >> top does show only 4. >>=20 >> An old thing is still true: >>=20 >> a10_mmc1: error rint: 0x00000100 >> a10_mmc1: error rint: 0x00000100 >> a10_mmc1: error rint: 0x00000100 >> a10_mmc1: error rint: 0x00000100 >> a10_mmc1: error rint: 0x00000100 >> a10_mmc1: error rint: 0x00000100 >> a10_mmc1: error rint: 0x00000100 >> a10_mmc1: error rint: 0x00000100 >> a10_mmc1: error rint: 0x00008018 >> a10_mmc1: error rint: 0x00000100 >> a10_mmc1: error rint: 0x00000100 >> a10_mmc1: error rint: 0x00000100 >> a10_mmc1: error rint: 0x00000100 >> mmcsd1: 8GB = at mmc1 52.0MHz/8bit/65535-block >> mmcsd1boot0: 4MB partion 1 at mmcsd1 >> mmcsd1boot1: 4MB partion 2 at mmcsd1 >> mmcsd1rpmb: 524kB partion 3 at mmcsd1 >>=20 >>=20 >> FYI: >>=20 >> # uname -apKU >> FreeBSD bpim3 12.0-CURRENT FreeBSD 12.0-CURRENT r324743M arm armv7 = 1200051 1200051 >>=20 >>=20 >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >>=20 >>=20 >> _______________________________________________ >> 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" >=20 >=20 > --=20 > Emmanuel Vadot From owner-freebsd-hackers@freebsd.org Tue Oct 24 05:36:17 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4D0A2E406B8; Tue, 24 Oct 2017 05:36:17 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0099.outbound.protection.outlook.com [104.47.32.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DB8AD70EB9; Tue, 24 Oct 2017 05:36:16 +0000 (UTC) (envelope-from sjg@juniper.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=n9QGnuj06Hd8EG54hzk1d4fKF58K1Lmhu1c6djbxGpw=; b=HZT0am190B0YUaq8u8VWNr2SzMICpX9qawX8DHeaucvM0jfKBoHcrk8JRRHd0PbqBLrusyqfJf5vDnkhBwJK2SEFDU4kzHH6Yo1gU0XD4q9EtHyvlP2hmU3SRp7dfXWYy1sgI/mnuZY9l+zyH3US1gC4GdfSL9tUCTph6gUqIdE= Received: from CO2PR05CA0061.namprd05.prod.outlook.com (10.166.88.157) by DM5PR05MB3611.namprd05.prod.outlook.com (10.174.243.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.3; Tue, 24 Oct 2017 05:36:15 +0000 Received: from DM3NAM05FT038.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e51::205) by CO2PR05CA0061.outlook.office365.com (2603:10b6:102:2::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.178.3 via Frontend Transport; Tue, 24 Oct 2017 05:36:14 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by DM3NAM05FT038.mail.protection.outlook.com (10.152.98.151) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256) id 15.20.156.4 via Frontend Transport; Tue, 24 Oct 2017 05:36:14 +0000 Received: from p-mailhub01.juniper.net (10.47.226.20) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 23 Oct 2017 22:36:13 -0700 Received: from kaos.jnpr.net (kaos.jnpr.net [172.21.30.60]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v9O5aCo1011296; Mon, 23 Oct 2017 22:36:12 -0700 (envelope-from sjg@juniper.net) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id D504A385567; Mon, 23 Oct 2017 22:36:12 -0700 (PDT) To: Rozhuk Ivan CC: Eric McCorkle , "freebsd-hackers@freebsd.org" , , Subject: Re: Trust system write-up In-Reply-To: <20171024040925.1918f3cb@rimwks> References: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.net> <20171023071120.GA72383@blogreen.org> <67125.1508777074@kaos.jnpr.net> <20171024040925.1918f3cb@rimwks> Comments: In-reply-to: Rozhuk Ivan message dated "Tue, 24 Oct 2017 04:09:25 +0300." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 25.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <78907.1508823372.1@kaos.jnpr.net> Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Oct 2017 22:36:12 -0700 Message-ID: <78908.1508823372@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(39860400002)(2980300002)(189002)(199003)(24454002)(53936002)(478600001)(2906002)(105596002)(316002)(2810700001)(106466001)(93886005)(68736007)(77096006)(54906003)(69596002)(53416004)(229853002)(107886003)(6246003)(46406003)(97736004)(6266002)(76506005)(4326008)(39060400002)(7696004)(81166006)(8936002)(81156014)(8746002)(9686003)(50986999)(305945005)(356003)(76176999)(97756001)(5660300001)(7126002)(6916009)(2950100002)(117636001)(50466002)(97876018)(86362001)(189998001)(23726003)(47776003)(8676002)(50226002)(55016002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3611; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM05FT038; 1:a5WSeGAiCO1091HKG423vyan7LI1rI7quAjO/mDJ4bB+Esq8bdGO2BQhzxChlJZGWXhWjjcOgeuZkVy1ORFujVr0WOXOSiKQsyKg9V/ypeCKslksky1abMerdxGJofSy X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8578b3da-6ddc-4d7d-c163-08d51aa12460 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:DM5PR05MB3611; X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB3611; 3:+vlqRFdr3FlR2ep+8J/TkWSzLeHh2kM6hm4Q51Y3+vECqdhcasb6IWRkWPxbnbH2G062JZHS0coWLXNde6//06gwvDywoJEH8ou1ZYLyY1cljOQZLa1F2mwzs5wKzpLbotQxCRt4y+L0fPSGnBh+PLP++O75UedSefb6wZ+3hBZtbmUezU1ZtY9ybG/7/PlWP20+zI9gV/fbRu5jQvZrUCUvG1olI3uHEdXEyK0V0d2/yox0VXCOa0zctqM9ZFSde9hA9oZgyexIGDKxOxlJe/0kV3+fzsU/Bg+LK3mn8gJnwzCjxyWLMxquUEJwWzdYxLMxoOWMPvGp0kxEJE6Mlsui5pjFIQNcIP8x67mtXlw=; 25:pAYFITFQJEW2iGKDXn2G39rzYHr9DtSm0/70PQe4wsknbsrHLisy+TDIspH9Qob7pHhA4OaEO2PzTaYFVL+65BysmoCdS0YDVJoN/vZybK1Dvew1OlVq+kBfPvfF7KVbnRV+uLP8SkzeYAFDMCIfZ56oP4IBvj2oKVl4xOo5Dxp9TEzCLvj4i+k+xfbx//Thke1XN0ndkGBMiLgYxRoojh57Nz0h41q4+Q6LZX7ZAwgH127NC9hNlrBpacGU/iY34Td1JnjBY9hU469ERL9UKXBeOY1iG19UpKS8Ni5qbDCb45IDZf4vEyGRqlo7R4cKnkVHp/hQmCy9EnhCKe+7rw== X-MS-TrafficTypeDiagnostic: DM5PR05MB3611: X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB3611; 31:lYyVxan4FEY7dws6r5zahNwzmY5v+bwel5YUcIBDppIueRcecTalYwejKDuTe2gcqeN8Zk5vEPpMNJqi+qCDAg+Xv0hSLsrVx526Nv24Gm9z9NxW+uvr8PnAeaRzCAWJi2c+9Mno+IhXmoxTSzGS0oYdduWriJ0oBbcK78z5uV42CxdZ/sSC10+ofgXXbilLfDvtnAYRO7GMENR+zkIadE8u281RKP2sI3QWNdWkOPo=; 20:9vV2PuzwtztyHwdI3RmVsCRJZ6Bw07cNnILl8WHIC1JS8cxa9RCEZDh2tftrEZVNC7mU7KrmxZWUlDMxKN7OUMe4hbfZAXI1pEF8tKs4dtP6ETg2HMk/omjChj0g4w8qX0RAbv/v3RaErnY8ktZZ1Hk2oNtqKoqocqGBB0ObFArvCQSNsU3LdKs0JI2X+UCailH7gqA2k6fqV/XlwKROqlQQcIYcXpmJRM8AJz2nsRFEDN738S1CobcNSOwv2FHmSWoi8z9hM4LEdc0hkVwrLBSa9CkRdmuesAGH2J3t4AZLAY2zg6Ur1pmqZZwge1I7pudeS73kNO9B4QwB584+m0FMwdJuw+/jXmRMhBOdol89dtSuvmgpCtp5wk5DN/zHUtqgy1FIoY3qD3bIVNjLa1qL/P4hnxx27dWFqd80/4WAlb7rVSN5p4yLeCvxi+irpOx8JCPutFSO5D/1YoALr046EyfzYm/3xjCqFxrraKsqGMHwKRjpVjTuUQW8pNdv X-Exchange-Antispam-Report-Test: UriScan:(138986009662008)(17755550239193); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(3002001)(3231020)(100000703101)(100105400095)(93006095)(93003095)(6055026)(6041248)(20161123560025)(20161123558100)(20161123555025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR05MB3611; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR05MB3611; X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB3611; 4:gPOtEK2mSJFiDlCl1KHFIkbJPDfZpLbukkrWx7FWl8hSr8xrdV/eAcEi51i3zbJ5z1jfb8BIl7UEMPDXQHSItnDIkSUbbCzj4INpR+L2ihaIJLaT8EmxjtwBkboY6bQUFRXlFvkCcyry6+i/HFPdvewzgIiCwxuH7xEDPXepRUaX1FWkuidLG13oCTNSQdjuOxDyNjC4rEauMWtGJr2TxDjYFpikcm7wcF1l3KojMfidjbkEybiYdUMoFQdvwcUiR3qYQMau4OOaMyA5rbXNcxyeFerol652pt+gc2Yx7xug6hNKvogOd0jcAMvdiahQj9BYEvg6auxR3HCCM+17CbHKC44S2RjUG0m5bMXM39A= X-Forefront-PRVS: 047001DADA X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM5PR05MB3611; 23:db3/GBvjFV/GtOjNeWU0IG7mLCkGUjtL0QLnXHvwp?= =?us-ascii?Q?fU/xTg/LDtfF4uA2bH8mFjmiS8cwVyNhL+Kf5+bbF4nL/C1Widu+2bNgcWi6?= =?us-ascii?Q?VVr59uGXIAKlyqKzSs/7We+ip/osr8jbIyYRnBDTu+AtHkLNqmrqboRedI25?= =?us-ascii?Q?hX9yshxH+PEcE74I6TKp/3Rec3Hrlnr5CbBx4/umMpGjUgbpX29CdPPxF1YG?= =?us-ascii?Q?7x103+G0rbrD+iO+TF1nClI9bHfGSOHBeDa+YxyMmgAvOGxWocg7LsFK6thy?= =?us-ascii?Q?Vei5tvTbD5/RgBffE2OzFaZHdwLOXe0Y7J6q5q5J+CY5Az6bZ772mwfbc0p7?= =?us-ascii?Q?9xRPWduDhr6S2UeQpS/gZI7fWxl9cRHtm6DBT+3mH57gFcctvaMj3FH4hCQX?= =?us-ascii?Q?PrDHU2SN8ybGGT6Fev1HJnARaB/i1uVmq/B6QLci1QJn1Uc7jWGFw3enPkXT?= =?us-ascii?Q?cA2G2WHogTfKCOZG4aSxOzH9LCUEcx5+rx/+jZRBhRR2FHywmIeZ/hTwsa3x?= =?us-ascii?Q?DqdaRc6s2sonof+JBMDVdc0tfPHA0aP3in9jVB+1wPjdC8TpsFVc9/8+k9ra?= =?us-ascii?Q?LNAv2ACzxBHMBSL4XU7WRZQQHIMXYB8W8DQgQDLrKpujyBHxBpUIzNxqXmzr?= =?us-ascii?Q?Euua2g7sDVENhO0tWC11xpx+hYqxsDd8mUB3TJ+321IasZuixsk7wq99TZOv?= =?us-ascii?Q?1dLKzlCs4Hd35Cq5GDoMVDh3Ep4llrUo+kvzQZKH8zZdxOJZrzl1FCeqz6yt?= =?us-ascii?Q?eEzFDGzToAcMwWRWJlMqQ/XBv48Wc+JFDi4dfDDj2S0IieaqT1Ijn0Hlzd2r?= =?us-ascii?Q?17Fzqwqa3D7FHhXAvdH0bsdupt9IxizSzXDYml8YTbMiMrQ5Viky8/ch1qSH?= =?us-ascii?Q?yMAAzILnwarM70rsGNf1vAZw1h7aSZ71LBnyCQKNFu55HzF87BJCPR8mOpYJ?= =?us-ascii?Q?as1CoEIlrjiwFwVUvMPO7Hguvh+ApdwRgeyeuSpudeQfe/K0NapW9RoSD/bS?= =?us-ascii?Q?qFR1fkKjp2ehjqSkhKNx8BPZ0L/lJ4YtmbcTIxoYE7v8XAKZopQ1TQavSG6O?= =?us-ascii?Q?KlaA6RbO8xungz7tYhYBqHlUFFBSoVP43lioszygYO2zbPt6zDxjN2m40uz9?= =?us-ascii?Q?Q2aMvD1XkNqdeuAEOi4/Y27aW4UKhtc3A8Ds567W8vEBHGiNM8TrZD3s7nsR?= =?us-ascii?Q?DXuCSvAGb/xw52iEKEVwptF0RlvJD9s4ON53FaVIhxfG8EfKX0pqrc9/JMDo?= =?us-ascii?Q?lXRhW//rh08g0IvK7hLXfniA0sL5hAWpQrRPZQOCY+iezIG/WKBs6Gef97uK?= =?us-ascii?Q?+w6/ivc8PJao78QlP9viNA=3D?= X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB3611; 6:tEK9QLRGR7jpA44f6IIPsc+CdeHxEQWHxGM6uZmRtQotzfOqQ5OJwv9O3OVzTpmfZUxaedgRj8QMqbnyJQ44fD3KjiPw3W6FyogddeJ/imxCogMoi03kq5q+5kAgF0DXWDJG7mA8H3Jqk/jAP/s1Q1zMhUL0euhJ6fvRwIhcHzdwhUnsCYRXC0WNipowKdxAQRj34PX0il7P8ggPZpWVY9wgDS/polIvPm+FRFZVvDhPaZ7MHpEqbYKWO0USyK8VXICNT+M4iYPX9xaay24HPu+sU6PTvo70EXFbrA8cp/RsgIrE4cUZrvWI+jygZh/dDgLXFwTEPymglbWx4yIyoVfDE8NnhDknFLaFmmGU6RI=; 5:SAQ6+XN+16MhtWwnbNGKsa3veB1syjsmcCJJavr3wcEnAhsDLraDPgcIBgbxeveSLl0KcThBN40gFw9xAQhRiv3JI4SXIndmXmVP5n+E3hn3RZ9Kq1X3EFFdkJryUMRpgGBAX/jEBrKMGG/FjFNe/fSM0ICZUVkU3FftHT7bf6I=; 24:klQ/txdLF123I9IHDAvqxfDIbReNNUCrTu+OSBeXXvU5YHwsBnk7+VMoknnbjR6BeqwCZrVapq7JJtmAVlODCrvy4Wa2inQa7b3dCyQJB4I=; 7:bobh1t4seV7b3UkhjGpmPUXLMcwVNNqT96pGcJ+0lZEl6iqGIBtOtrxDjoeJQ5kD4Ij2/IU//Aq7buMkJppCCBcD25hpUK3/rkK3FRg4NfHpTclTdvcY7pDyvAqCvPeKRFEvSDqK5eKBWI2WSXN5yFbp+cYXBtq+G4Un1Rgc/dTm8jSkMmB3cMST7wTtwp3eAD0MnY08FpmygI8bSYlcD6kFi0VoptorW6W5crDk9mtOIJvgAMqIVi78BKzI1Tls SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Oct 2017 05:36:14.2045 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8578b3da-6ddc-4d7d-c163-08d51aa12460 X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3611 X-Mailman-Approved-At: Tue, 24 Oct 2017 10:08:08 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 05:36:17 -0000 Rozhuk Ivan wrote: > On Mon, 23 Oct 2017 09:44:34 -0700 > "Simon J. Gerraty" wrote: > = > > With the advent of secure boot and TPM's, there is potentially scope > > to allow for mixed control. > = > TPM is closed hardware and software: you dont know what inside and how i= t works. I'm talking about the TPMs we put on our boards - we know what is in them. From owner-freebsd-hackers@freebsd.org Tue Oct 24 10:44:18 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B6B6CE48AD6; Tue, 24 Oct 2017 10:44:18 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 7E74A7E4A4; Tue, 24 Oct 2017 10:44:18 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 830983147; Tue, 24 Oct 2017 10:44:12 +0000 (UTC) Subject: Re: Trust system write-up To: Rozhuk Ivan , "Simon J. Gerraty" Cc: "freebsd-hackers@freebsd.org" , freebsd-arch@freebsd.org References: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.net> <20171023071120.GA72383@blogreen.org> <67125.1508777074@kaos.jnpr.net> <20171024040925.1918f3cb@rimwks> From: Eric McCorkle Message-ID: Date: Tue, 24 Oct 2017 06:44:12 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171024040925.1918f3cb@rimwks> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 10:44:18 -0000 On 10/23/2017 21:09, Rozhuk Ivan wrote: > On Mon, 23 Oct 2017 09:44:34 -0700 > "Simon J. Gerraty" wrote: > >> With the advent of secure boot and TPM's, there is potentially scope >> to allow for mixed control. > > TPM is closed hardware and software: you dont know what inside and how it works. > Secure boot same crap: closed source with many known security holes. > I think it's necessary to support secure boot for commercial vendors and such. I personally have no interest in Microsoft being able to certify random programs to boot on my machines, and am much more interested in things like coreboot. There are, however, secure boot mechanisms such as the Power architecture boot that maintain user control, and I'm hoping with the rise of RISC-V that we'll see trustworthy hardware crypto and TPM-like devices. From owner-freebsd-hackers@freebsd.org Tue Oct 24 11:12:36 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0B59EE49685; Tue, 24 Oct 2017 11:12:36 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 138387F3FF; Tue, 24 Oct 2017 11:12:34 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 0f421562; Tue, 24 Oct 2017 13:12:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=z3azyNuEt3AnCGShhatUFJriAH8=; b=PcvmG9WTJ7owrOW5lJyIZJ9t95Jt Zaa/8lqL28SjdEq5nIGkVxQxpGGrVGPFLPY2ggMzy91JTlbToay82e6qFNyfQPzG GEQRBxtcaBqT/2ik1gvZdB7uYdVi9RDEk83iZBAELhn96AUGcCJXNChF0HjBh2m/ nkrcNWdby9B6oJE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=jO7vfd7cgjtiAVk6RRvoPmQ5D7Q+X4+1XZttPE20Bk+ZznU71m36ldye DhB1S3xPQNloH72Hdp4sObNddDO4vatiWRpPmXpqtipVTh58tiydBK26kiFcSqVB bqyj/NRnILU+Z7MSlP0v6K7vj7F3T2AHGIq6ffkPVs6NV9+aU1g= Received: from arcadia (evadot.gandi.net [217.70.181.36]) by mail.blih.net (OpenSMTPD) with ESMTPSA id ce7e97ab TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Tue, 24 Oct 2017 13:12:31 +0200 (CEST) Date: Tue, 24 Oct 2017 13:12:30 +0200 From: Emmanuel Vadot To: Mark Millard Cc: freebsd-hackers , freebsd-arm Subject: Re: BPI-M3 booted via a variant of head -r324743 with an external ECHI USB root file system: what I changed to have it happen Message-Id: <20171024131230.f9ec9141d9ec8917229ad54f@bidouilliste.com> In-Reply-To: References: <3AD6B1F8-512C-43BB-AC76-7721454AD02F@dsl-only.net> <20171021195812.5bdb902401b8e756b6abfe40@bidouilliste.com> <20171021204356.47e3cd6066144bcd07f46699@bidouilliste.com> <50728566-11C2-45EB-8367-00CAF38D4548@dsl-only.net> <8696CCFA-AE7D-4324-90A8-BB73402FA124@dsl-only.net> <06B9A4AD-EA28-41A8-91B9-FE368EF622FE@dsl-only.net> <68CB464E-6FC6-4CB9-963B-9E7A683041EB@dsl-only.net> <17D6B79E-F7AF-4395-B8A2-2CE9A5157ABF@dsl-only.net> <20171024105014.cd2012898a602408ee605183@bidouilliste.com> X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 11:12:36 -0000 On Tue, 24 Oct 2017 03:03:25 -0700 Mark Millard wrote: > [Top post.] > > Thanks for the notes. I'm gradually figuring a > little bit out. > > Looking in: > > https://svnweb.freebsd.org/base/head/sys/gnu/dts/arm/?dir_pagestart=1000 > > (the linux 4.13 update) I see: > > sun6i-a31s-sinovoip-bpi-m2.dts > > but no .dts directly for the bpi-m3. It will be in 4.14 iirc. > So, it appears that the outer layer (.dts) > does not have a Linux 4.13 or earlier > version to be based on. > > There is an include file: > > sun8i-a83t.dtsi > > Unlike, say, sun6i-a31.dtsi, sun8i-a83t.dtsi > does not seem to have, for example, usb > material. A83T support is pretty recent in mainline Linux. > There are A83T examples: > > sun8i-a83t-allwinner-h8homlet-v2.dts > sun8i-a83t-cubietruck-plus.dts > > (But, also no usb material.) > > It looks to me like somewhat more than > the ccu driver is needed to in order > for the bpi-m3 to meet your criteria > for staying in FreeBSD, and possibly > even more to support things such as > usb. Yes but a working ccu driver is the first logical step. > > === > Mark Millard > markmi at dsl-only.net > > On 2017-Oct-24, at 1:50 AM, Emmanuel Vadot wrote: > > > > Top posting as there is too much stuff in that mail. > > > > I find it really hard to understand you mail as there is too much data > > in it. > > > > But, to clarify the A83T situation (And general info on Allwinner > > clocks) : > > > > - Old Linux DTS (~4.8 iirc) for Allwinner SoCs had the clock directly > > defined in them under a /clock nodes, with jmcneill@ we added support > > for most (if not all) of them and this supported every Allwinner SoCs. > > - With the H3 DTS added things started to change, they removed > > the /clock node and simply add a ccu node (Clock Control Unit) as it's > > commonly done in ARM DTS. > > - This move a lot of information from the DTS to the kernel driver for > > the CCU. > > - Around that time the first H3 dts that was written (but not added in > > the Linux repository) was from the model, with the /clock node. And we > > added those file in FreeBSD under sys/boot/fdt/dts > > - I finally wrote a driver for the new clock ccu driver and currently > > it support H3, A64 and A31. > > - Linux started to convert old SoCs from /clock to ccu (A13 is done, > > A83T too and for A10 and A20 it will be available in 4.15 iirc) > > - I don't want us (us = FreeBSD) to derive from the Linux DTS as it's > > a pain to maintain, every change should be sent to Linux directly (it's > > really not that hard). > > > > So, that being said, what needs to be done for A83T support to stay in > > FreeBSD is adding a ccu driver for it. With the clkng stuff I did (see > > sys/arm/allwinner/clkng) it's not that hard, it's just a matter of > > reading the user manual clock section and translate table to > > macros/struct. You can have a look at H3 (or any other ccu driver) to > > see how it's done. > > As of today support for A83T and A13 don't work anymore if you use > > the current DTS, I've started working on A13 and should commit the > > driver soon. Someone with A83T should do the same. > > > > Cheers, > > > > On Mon, 23 Oct 2017 20:43:50 -0700 > > Mark Millard wrote: > > > >> [This largely ignores my questions about > >> mp_ncpu <= cpuid happening when there are > >> 4 unused cores (of 8), as there are for > >> the BPI-M3's A83T support.] > >> > >> For head -r324743, by making: > >> > >> sys/boot/fdt/dts/arm/a83t.dtsi > >> > >> slightly more modern (reg-names, phy_ctrl, > >> pmu0, and pmu1) and putting in my guesses > >> for A83T in: > >> > >> /usr/src/sys/arm/allwinner/aw_usbphy.c > >> > >> I've gotten -r324743 to boot with a root > >> file system on an external USB drive in > >> ECHI mode. I've tried both USB ports and > >> both have worked as ECHI for this. > >> > >> The changes: > >> > >> # svnlite diff /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi > >> Index: /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi > >> =================================================================== > >> --- /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi (revision 324743) > >> +++ /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi (working copy) > >> @@ -179,6 +179,9 @@ > >> reg = <0x01c19400 0x2c>, > >> <0x01c1a800 0x4>, > >> <0x01c1b800 0x4>; > >> + reg-names = "phy_ctrl", > >> + "pmu0", > >> + "pmu1"; > >> clocks = <&usb_clk 8>, > >> <&usb_clk 9>, > >> <&usb_clk 10>, > >> > >> Other than some include file usage, the BPI-M3 is > >> not and has not been using sys/gnu/dts/ files. The > >> above makes the .dtb that FreeBSD produces be > >> something that the modern kernel will not reject > >> parts of. > >> > >> # svnlite diff /usr/src*/sys/arm/allwinner/aw_usbphy.c > >> Index: /usr/src/sys/arm/allwinner/aw_usbphy.c > >> =================================================================== > >> --- /usr/src/sys/arm/allwinner/aw_usbphy.c (revision 324743) > >> +++ /usr/src/sys/arm/allwinner/aw_usbphy.c (working copy) > >> @@ -58,6 +58,7 @@ > >> AWUSBPHY_TYPE_A13, > >> AWUSBPHY_TYPE_A20, > >> AWUSBPHY_TYPE_A31, > >> + AWUSBPHY_TYPE_A83T, > >> AWUSBPHY_TYPE_H3, > >> AWUSBPHY_TYPE_A64 > >> }; > >> @@ -90,6 +91,13 @@ > >> .phy0_route = false, > >> }; > >> > >> +static const struct aw_usbphy_conf a83t_usbphy_conf = { > >> + .num_phys = 3, // SATA via USB bridge as well > >> + .phy_type = AWUSBPHY_TYPE_A83T, > >> + .pmu_unk1 = false, // ???? > >> + .phy0_route = true, // ???? > >> +}; > >> + > >> static const struct aw_usbphy_conf a31_usbphy_conf = { > >> .num_phys = 3, > >> .phy_type = AWUSBPHY_TYPE_A31, > >> @@ -116,6 +124,7 @@ > >> { "allwinner,sun5i-a13-usb-phy", (uintptr_t)&a13_usbphy_conf }, > >> { "allwinner,sun6i-a31-usb-phy", (uintptr_t)&a31_usbphy_conf }, > >> { "allwinner,sun7i-a20-usb-phy", (uintptr_t)&a20_usbphy_conf }, > >> + { "allwinner,sun8i-a83t-usb-phy", (uintptr_t)&a83t_usbphy_conf }, > >> { "allwinner,sun8i-h3-usb-phy", (uintptr_t)&h3_usbphy_conf }, > >> { "allwinner,sun50i-a64-usb-phy", (uintptr_t)&a64_usbphy_conf }, > >> { NULL, 0 } > >> > >> The SATA is why there are 3 USB phys for the BPI-M3 > >> instead of 2. > >> > >> The root filesystem is on: > >> > >> da0: Fixed Direct Access SPC-4 SCSI device > >> da0: Serial Number > >> da0: 40.000MB/s transfers > >> da0: 228936MB (468862128 512 byte sectors) > >> da0: quirks=0x2 > >> > >> > >> One new thing is: > >> > >> module_register: cannot register simplebus/ahci from kernel; already loaded from kernel > >> Module simplebus/ahci failed to register: 17 > >> module_register: cannot register simplebus/ehci from kernel; already loaded from kernel > >> Module simplebus/ehci failed to register: 17 > >> module_register: cannot register simplebus/pcib from kernel; already loaded from kernel > >> Module simplebus/pcib failed to register: 17 > >> module_register: cannot register simplebus/ehci from kernel; already loaded from kernel > >> Module simplebus/ehci failed to register: 17 > >> > >> I've not figured out what those messages are > >> about yet. > >> > >> There is also: > >> > >> real memory = 2147483648 (2048 MB) > >> avail memory = 2089332736 (1992 MB) > >> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > >> > >> vs. > >> > >> cpulist0: on ofwbus0 > >> cpu0: on cpulist0 > >> cpufreq_dt0: on cpu0 > >> cpu1: on cpulist0 > >> cpu2: on cpulist0 > >> cpu3: on cpulist0 > >> cpu4: on cpulist0 > >> cpufreq_dt1: on cpu4 > >> cpufreq_dt1: no regulator for cpu@100 > >> device_attach: cpufreq_dt1 attach returned 6 > >> cpu5: on cpulist0 > >> cpu6: on cpulist0 > >> cpu7: on cpulist0 > >> > >> My understanding is: only the first cluster > >> of 4 cores is supposed to be active/used > >> and the 2nd cluster is supposed to not > >> be in active use. I'm not sure that the > >> 2nd cluster is being handled as intended, > >> or what the intended details are. But > >> top does show only 4. > >> > >> An old thing is still true: > >> > >> a10_mmc1: error rint: 0x00000100 > >> a10_mmc1: error rint: 0x00000100 > >> a10_mmc1: error rint: 0x00000100 > >> a10_mmc1: error rint: 0x00000100 > >> a10_mmc1: error rint: 0x00000100 > >> a10_mmc1: error rint: 0x00000100 > >> a10_mmc1: error rint: 0x00000100 > >> a10_mmc1: error rint: 0x00000100 > >> a10_mmc1: error rint: 0x00008018 > >> a10_mmc1: error rint: 0x00000100 > >> a10_mmc1: error rint: 0x00000100 > >> a10_mmc1: error rint: 0x00000100 > >> a10_mmc1: error rint: 0x00000100 > >> mmcsd1: 8GB at mmc1 52.0MHz/8bit/65535-block > >> mmcsd1boot0: 4MB partion 1 at mmcsd1 > >> mmcsd1boot1: 4MB partion 2 at mmcsd1 > >> mmcsd1rpmb: 524kB partion 3 at mmcsd1 > >> > >> > >> FYI: > >> > >> # uname -apKU > >> FreeBSD bpim3 12.0-CURRENT FreeBSD 12.0-CURRENT r324743M arm armv7 1200051 1200051 > >> > >> > >> > >> === > >> Mark Millard > >> markmi at dsl-only.net > >> > >> > >> _______________________________________________ > >> 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" > > > > > > -- > > Emmanuel Vadot > > _______________________________________________ > 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" -- Emmanuel Vadot From owner-freebsd-hackers@freebsd.org Tue Oct 24 14:41:38 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 84BEBE4F99C; Tue, 24 Oct 2017 14:41:38 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::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 093F4307A; Tue, 24 Oct 2017 14:41:38 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf0-x230.google.com with SMTP id a16so24281098lfk.0; Tue, 24 Oct 2017 07:41:37 -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=BbNVDhf5LnwKiqD7ODMzM+u2vvAdu2vY9b897WxS6Uk=; b=IQXAT5om+/zRHP+DRogUPy1dPK5juWJBqBamokzJXPpatfuGkfifKgHtO8MHXk/OX1 3bxXyvxBNfKw948qPFkNHk0ty6EtNWtxMNnEdBTwdmnPFl0CawzpqMlFxe4znUhqoD62 mNnWMzOQqbObJrp6IVfJve41BxjocZ5ycJ4NbjTfCzy5zZuunLqvNF3rRJK5CKLMx77v bYoL2e1Y8dOHpMC4vHO/IJge12pr2AoRETq3nQAUHkoQFA8w2ATECKTzk3hWZ4pw2LsJ Hr1UnMWVFYoIh6dLQkfkha9voZtWf92sqJ/LqwkmiYOi5crzT99z0HI8XqO8qHvaOyCw NqDg== 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=BbNVDhf5LnwKiqD7ODMzM+u2vvAdu2vY9b897WxS6Uk=; b=mOiYPRLSCsYHzQySvCx3t3sS+rYK6nz8vOlIcxg/0d6hM3+fN8b4OwYI5giOwuG1TW OLGFXdP2CwlmJHRf6P8TCgEyjD0u+PH7LcDmMaYA1cIQJJ6qjqI7EOVdakZKWOPPfZJI y2dRWAWG9nT4fWFPXj1twfFi0bnTJsRKJ9cWUPxRCISUrYtuNAL568jJK8KdYrnSHlTF /uChKTbKkUzt0BxNizSAmX4wZWxm8mKLCY6mnvI+w4qy78RAMYI+zpxaUc53rzv4fBuC ZPMyOvhg9fyOiKJAAFSKiN64mmkNrPFix+6jnrCih0zHiVEbR9DigPwPvQa1FFUf5gQg 2mIg== X-Gm-Message-State: AMCzsaVuPPrpcOjYI7IrqSmQB9KwF82BjpLoiyqgmNDrfRiTHd0T2dGj jGcvpHSWuVwNrGPUTCRuy6WX1/Kjhvfp2mqNGeY= X-Google-Smtp-Source: ABhQp+T2jw96XXtsJkw6l2VDgdHlRdPwLvIbsmXzKxLImq/z2aI55uni8bQGogqIjM0+Bdf5YWYc9VZTiGx9Bf7PAbo= X-Received: by 10.46.20.11 with SMTP id u11mr7092183ljd.38.1508856095941; Tue, 24 Oct 2017 07:41:35 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.179.93.24 with HTTP; Tue, 24 Oct 2017 07:41:35 -0700 (PDT) In-Reply-To: References: From: Alan Somers Date: Tue, 24 Oct 2017 08:41:35 -0600 X-Google-Sender-Auth: pShcwbTzR9lrwE_EmYzWXwTvQz8 Message-ID: Subject: Re: Periodic jobs lockf timeout To: Borja Marcos Cc: "freebsd-hackers@freebsd.org" , freebsd-security@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.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 14:41:38 -0000 On Tue, Oct 24, 2017 at 3:07 AM, Borja Marcos wrote: > > Hi, > > I=E2=80=99ve come across a problem with the =E2=80=9Cdaily=E2=80=9D secur= ity job. On an overloaded system with lots of ZFS datasets, > lots of files, heavy system load and, to add insult to injury, a ZFS crub= going on the find=E2=80=99s issued by the > periodic checks can take forever. They can take so long, I have found sev= eral lockf=E2=80=99s waiting. > > Is it sane to have an unlimited timeout for lockf? Probably it would be b= etter to have at least a configurable > timeout for each cathegory. It=E2=80=99s really unlikely to see an overla= p for a weekly or monthly job, but for daily > jobs it would be good to have a sane default, say, an hour or two. > > There=E2=80=99s even a parameter on /etc/defaults/periodic.conf but it se= ems it=E2=80=99s not used right now. > > # Max time to sleep to avoid causing congestion on download servers > anticongestion_sleeptime=3D3600 > > > The alternative would be to have defaults for a sane timeout for each cat= hegory, like > > daily_lockf_timeout > weekly_lockf_timeout > monthly_lockf_timeout > > Thoughts? It=E2=80=99s pretty simple to do and overlapping periodic jobs = are really useless. Are you talking about the lockf in /usr/sbin/periodic? It already has a timeout of 0, which should prevent overlapping periodic jobs. Or is there some other lockf involved? Without knowing which lockf you're talking about, I can't understand your problem. The anticongestion_sleeptime variable is unrelated to lockf. -Alan From owner-freebsd-hackers@freebsd.org Tue Oct 24 15:06:09 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BE007E50165; Tue, 24 Oct 2017 15:06:09 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from cu01176b.smtpx.saremail.com (cu01176b.smtpx.saremail.com [195.16.151.151]) (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 80F7A632AD; Tue, 24 Oct 2017 15:06:08 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from [172.16.8.41] (unknown [192.148.167.11]) by proxypop01.sare.net (Postfix) with ESMTPA id DCD459DCDBF; Tue, 24 Oct 2017 17:06:04 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) Subject: Re: Periodic jobs lockf timeout From: Borja Marcos In-Reply-To: Date: Tue, 24 Oct 2017 17:06:04 +0200 Cc: "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Alan Somers X-Mailer: Apple Mail (2.3445.1.7) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 15:06:09 -0000 > On 24 Oct 2017, at 16:41, Alan Somers wrote: >=20 > On Tue, Oct 24, 2017 at 3:07 AM, Borja Marcos = wrote: > Are you talking about the lockf in /usr/sbin/periodic? It already has > a timeout of 0, which should prevent overlapping periodic jobs. Or is > there some other lockf involved? Without knowing which lockf you're > talking about, I can't understand your problem. Sorry, my explanation was awful now that I read it again. Yes, I mean = the lockf in /usr/sbin/periodic. And no, I didn=E2=80=99t mean that jobs overlap (certainly they don=E2=80=99t = thanks to the lockf) but they can pile up. Today I had a machine with three daily jobs waiting to start because the first one = had been running for four days (a combination of lots of files and datasets, heavy system load, ZFS pool almost = full=E2=80=A6)=20 The problem with a timeout of 0 is that it=E2=80=99s unlimited. In case = something is wrong you can end up with a growing queue of daily periodic jobs waiting to run. Imagine you have a very high system = load for several days and for some reason the daily job won=E2=80=99t complete. Next day a new daily job will try to start but = it will have to wait for the first one to finish. And so on. The proposal is to replace the =E2=80=9C0=E2=80=9D timeout for lockf = with a sane timeout so that it will attempt to run it, but give up in case it can=E2=80=99t be done in a reasonable time. The timeout = shouldn=E2=80=99t be long actually. If periodic must wait in order to start a job it means that you have a serious performance problem and = it=E2=80=99s pointless to keep your machine doing =E2=80=9Cfind=E2=80=9D 24/7. Given the nature of the periodic jobs I don=E2=80=99t think it should be = a problem to attempt to run them in a best effort basis rather than guaranteing that they will eventually even if awfully late. I would add a configurable timeout for /usr/sbin/periodic. I think = it=E2=80=99s better done with a different variable for each=20 class and their default values can be 0 so that nothing changes. daily_start_timeout weekly_start_timeout monthly_start_timeout > The anticongestion_sleeptime variable is unrelated to lockf. Understood, I stand corrected. I assumed it was.=20 Hope it=E2=80=99s better now. It=E2=80=99s pretty easy to do but I=E2=80=99= m interested on the opinions on this matter :) Thank you! Borja.= From owner-freebsd-hackers@freebsd.org Tue Oct 24 15:08:00 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 39C7FE5036A for ; Tue, 24 Oct 2017 15:08:00 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::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 C144663564 for ; Tue, 24 Oct 2017 15:07:59 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: by mail-wr0-x22a.google.com with SMTP id g90so21012457wrd.6 for ; Tue, 24 Oct 2017 08:07:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=7BnVgLUys+BPi8HEQviVHQa6aA+AQHSx4LZH0li/RwU=; b=eGbjGsnIM0BLwXXnHJri8/02RnuL5z26Z9fhdyDCMrtDBi8fxi+c0HECeSFoJ0x6oD iZ/OG1Bk+QcN/Hm0QYCj7jNcpzobb6JRTigOrTDcrDSxDCgki6lyD3rXPbJ8GVpBE7BO e8NdOl1+nnrKcY+tLLuNIfmuTPLv4ObFyIkQwUpf+8JO3mIvwk1+aXoldvkhz5b/gHKK VL0JJRjO0tO1Tmx3eJoDcJ8fasrzk2ngyZQGqZdoorI8hm7QJCJsgbOznIYIRswPoZqw 4po7tv0b0+3PhsisNWzMTZtOGbUceOIS+1y4H6xOf83JdFn8pN3NHC2Cv6hykv56u+q1 FZlQ== X-Gm-Message-State: AMCzsaVD8BGT3VTgr7by1prY1eGOrDd7Hnb/z0HU3zIDRzdpeI2D9WG7 dFadZvMZuHujJ/iSbdNaaUYQhw== X-Google-Smtp-Source: ABhQp+Tp/Z9gkSDOU1nvantOaSw4oI6YhQBwWWXCsAPJXKH7fLbbMLU8qorBNb5oyGdIcDSi6JY1lQ== X-Received: by 10.223.176.214 with SMTP id j22mr2791941wra.24.1508857677811; Tue, 24 Oct 2017 08:07:57 -0700 (PDT) Received: from gumby.homeunix.com ([81.17.24.158]) by smtp.gmail.com with ESMTPSA id p7sm484560wmg.44.2017.10.24.08.07.56 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 24 Oct 2017 08:07:57 -0700 (PDT) Date: Tue, 24 Oct 2017 16:07:54 +0100 From: RW To: freebsd-hackers@freebsd.org Subject: Re: Periodic jobs lockf timeout Message-ID: <20171024160754.36f00c0a@gumby.homeunix.com> In-Reply-To: References: X-Mailer: Claws Mail 3.15.1 (GTK+ 2.24.31; amd64-portbld-freebsd11.1) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 15:08:00 -0000 On Tue, 24 Oct 2017 11:07:31 +0200 Borja Marcos wrote: > Hi, >=20 > I=E2=80=99ve come across a problem with the =E2=80=9Cdaily=E2=80=9D secur= ity job. On an > overloaded system with lots of ZFS datasets, lots of files, heavy > system load and, to add insult to injury, a ZFS crub going on the > find=E2=80=99s issued by the periodic checks can take forever. They can t= ake > so long, I have found several lockf=E2=80=99s waiting. >=20 > Is it sane to have an unlimited timeout for lockf? Probably it would > be better to have at least a configurable timeout=20 What problem does this solve? >=20 > There=E2=80=99s even a parameter on /etc/defaults/periodic.conf but it se= ems > it=E2=80=99s not used right now. >=20 > # Max time to sleep to avoid causing congestion on download servers > anticongestion_sleeptime=3D3600 In 11.1 it's used in the file it's defined in: sleep `jot -r 1 0 ${anticongestion_sleeptime}` From owner-freebsd-hackers@freebsd.org Tue Oct 24 15:25:38 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D1068E508A2 for ; Tue, 24 Oct 2017 15:25:38 +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 6670763E81 for ; Tue, 24 Oct 2017 15:25:37 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 940d5056-b8cf-11e7-a893-25625093991c X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 940d5056-b8cf-11e7-a893-25625093991c; Tue, 24 Oct 2017 15:25:35 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v9OFPTfG001285; Tue, 24 Oct 2017 09:25:29 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1508858729.34364.32.camel@freebsd.org> Subject: Re: Periodic jobs lockf timeout From: Ian Lepore To: Borja Marcos , Alan Somers Cc: "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org Date: Tue, 24 Oct 2017 09:25:29 -0600 In-Reply-To: References: Content-Type: text/plain; charset="windows-1251" 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.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 15:25:38 -0000 On Tue, 2017-10-24 at 17:06 +0200, Borja Marcos wrote: > > > > > On 24 Oct 2017, at 16:41, Alan Somers wrote: > > > > On Tue, Oct 24, 2017 at 3:07 AM, Borja Marcos wrote: > > Are you talking about the lockf in /usr/sbin/periodic?  It already has > > a timeout of 0, which should prevent overlapping periodic jobs.  Or is > > there some other lockf involved?  Without knowing which lockf you're > > talking about, I can't understand your problem. > Sorry, my explanation was awful now that I read it again. Yes, I mean the lockf in /usr/sbin/periodic. And > no, I didn’t mean that jobs overlap (certainly they don’t thanks to the lockf) but they can pile up. Today I had > a machine with three daily jobs waiting to start because the first one had been running for four days (a combination > of lots of files and datasets, heavy system load, ZFS pool almost full…)  > > The problem with a timeout of 0 is that it’s unlimited. No, lockf -t 0 means to exit without waiting, with status EX_TEMPFAIL, if the lock cannot be acquired immediately.  In light of that, the rest of your report/request doesn't make sense.  Jobs won't stack up, they'll fail if the prior one is still running. -- Ian > In case something is wrong you can end up with a growing queue of > daily periodic jobs waiting to run. Imagine you have a very high system load for several days and for some reason the daily job > won’t complete. Next day a new daily job will try to start but it will have to wait for the first one to finish. And so on. > > The proposal is to replace the “0” timeout for lockf with a sane timeout so that it will attempt to run it, but give up in > case it can’t be done in a reasonable time. The timeout shouldn’t be long actually. If periodic must wait in order to > start a job it means that you have a serious performance problem and it’s pointless to keep your machine doing “find” > 24/7. > > Given the nature of the periodic jobs I don’t think it should be a problem to attempt to run them in a best effort basis > rather than guaranteing that they will eventually even if awfully late. > > I would add a configurable timeout for /usr/sbin/periodic. I think it’s better done with a different variable for each  > class and their default values can be 0 so that nothing changes. > > daily_start_timeout > weekly_start_timeout > monthly_start_timeout > > > > > > > The anticongestion_sleeptime variable is unrelated to lockf. > Understood, I stand corrected. I assumed it was.  > > Hope it’s better now. It’s pretty easy to do but I’m interested on the opinions on this matter :) > > > Thank you! > > > > > > Borja. From owner-freebsd-hackers@freebsd.org Tue Oct 24 15:31:53 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 572D8E50C83; Tue, 24 Oct 2017 15:31:53 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from cu01176b.smtpx.saremail.com (cu01176b.smtpx.saremail.com [195.16.151.151]) (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 1BAB1643D2; Tue, 24 Oct 2017 15:31:52 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from [172.16.8.41] (unknown [192.148.167.11]) by proxypop01.sare.net (Postfix) with ESMTPA id 777009DCA56; Tue, 24 Oct 2017 17:31:49 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) Subject: Re: Periodic jobs lockf timeout From: Borja Marcos In-Reply-To: <1508858729.34364.32.camel@freebsd.org> Date: Tue, 24 Oct 2017 17:31:48 +0200 Cc: Alan Somers , "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <1508858729.34364.32.camel@freebsd.org> To: Ian Lepore X-Mailer: Apple Mail (2.3445.1.7) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 15:31:53 -0000 > On 24 Oct 2017, at 17:25, Ian Lepore wrote: >=20 > No, lockf -t 0 means to exit without waiting, with status EX_TEMPFAIL, > if the lock cannot be acquired immediately. In light of that, the = rest > of your report/request doesn't make sense. Jobs won't stack up, > they'll fail if the prior one is still running. True! Then I don=E2=80=99t understand what happened. When I saw several = processes waiting I assumed it was an unlimited wait.=20 My apologies, I need to look into it more closely. Borja. From owner-freebsd-hackers@freebsd.org Tue Oct 24 21:04:26 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8634EE2B784 for ; Tue, 24 Oct 2017 21:04:26 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-wm0-x22a.google.com (unknown [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 1794770BCA for ; Tue, 24 Oct 2017 21:04:26 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: by mail-wm0-x22a.google.com with SMTP id r68so18868366wmr.3 for ; Tue, 24 Oct 2017 14:04:26 -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=IUSdjon2HH6ktZVwjfETx9G8gbrDCIwx7tPRZGVkvgE=; b=PyfbvQteyCkomGwOtgcjWOk0fpjnDsVXB0cys3gIKvFLKDPyBiYc3/w2Yz/xoZAsmS gf7ISb2xNGvDnpNKu53rTzH6nWUdwb4bT1Yh3L/SrEPbwpdYXc74zdUykJ+80PyPnil/ Y5j/edPHqaQaz3MftWKsv+o46AbqxdlmhX0g8CwsMetWRu2bHAHl8kspqOvry9orsLba 1uEzCzpiRLhcL3s7VddosHaqRI3YvJSYnPwIfLsUoXJZeW4jqmcdbKp3t6UFma5jHKCv BSqtTLM4XTCv0TNUXHmI/jNZ9ML+5lC00sjdipHj4u78np2HDwMWtEgPItmPJj0PlYxW +50g== 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=IUSdjon2HH6ktZVwjfETx9G8gbrDCIwx7tPRZGVkvgE=; b=fdngkD+HArj0TlwX1AxLEPXgTbItOwF8oj780OvmGP27K2fIs4boJxVXfSKKQIkXiO 6UeXpRDLxkL6jIxcmOFGyngpaS2k2XrRhfcwsRICbFv2xR+1GNHfFNJ52WkDmC4FhREU gMwT7LGWE361oT+t3ROKlTvjHvagtmsnKimWJ3frXT9WqTKRGzR4lt7KLWTjADvOTm72 ORrOBa8DTcrgzvTkQgcRSt+TR28SOzSASbHzqSWPlOUJ7uphWmlsgPr7nsyYjHvBuE2m hqGAQaYhux2b+kuCgeMB1oT6BuialMRTj0u7vlcR8LVzYd6uWLC99jLuZZNCEWiZBN+q RCdg== X-Gm-Message-State: AMCzsaV98gJlws4Vvk9KlEAmDnxy1GZIcKFohgSCAzt0BqeLCMe4Xvyq LEmnjiqnrIlrfFcJKVPgqvYNfN42COakuMW7w0AZMox8 X-Google-Smtp-Source: ABhQp+RbpQ4MilIQKe4SqSGCRi21pWWp9V3C/Apk8C67Xs6zGb876i4iwgsbxQD7W+fGej0AB0TCP4WuYG2oPt+FMwE= X-Received: by 10.80.231.145 with SMTP id b17mr21921888edn.94.1508879063987; Tue, 24 Oct 2017 14:04:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.178.6 with HTTP; Tue, 24 Oct 2017 14:04:23 -0700 (PDT) X-Originating-IP: [67.82.41.73] In-Reply-To: <7951e7d5-b5e6-033d-0b51-1d4a10946937@oktetlabs.ru> References: <333473BB-43C3-4E3E-B62F-03DE5650E403@freebsd.org> <7951e7d5-b5e6-033d-0b51-1d4a10946937@oktetlabs.ru> From: Mark Saad Date: Tue, 24 Oct 2017 17:04:23 -0400 Message-ID: Subject: Re: Anyone using Solarflare on FreeBSD 10-STABLE ? To: Andrew Rybchenko Cc: Philip Paeps , Allan Jude , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 21:04:26 -0000 On Tue, Oct 17, 2017 at 3:44 PM, Andrew Rybchenko wrote: > On 10/17/2017 08:54 PM, Philip Paeps wrote: >> >> On 2017-10-17 19:36:20 (+0200), Allan Jude wrote: >>> >>> On 10/17/2017 12:32, Mark Saad wrote: >>>> >>>> Speificly I wanted to know if anyone knew what this sysctl refers to >>>> >>>> dev.sfxge.NN.stats.rxdp_di_dropped_pkts >>> >>> >>> I have two 11.1 boxes with a dual ported sfxge each, but I have no idea >>> what that counter is trying to describe. >>> >>> The man page says this is Philip's fault. >> >> >> This code is not my fault! ;-) I believe arybchik added it. >> >> Looking at the code, it's packets that have been dropped in the data path >> by the dispatcher cpu. Probably related to virtual functions? > > > Philip, thanks. I don't think in this particular case it is related to > virtual functions. > > Basically the counter means that ingress packet does not match any installed > filter. E.g. promiscuous mode is disabled and: > - destination MAC is unicast and not the interface MAC address, OR > - destination MAC is multicast and there is no matching multicast address > added. > > There is a race condition as well on interface bring up when packet is > received but default filters are not installed yet. > > SFN8522 and SFN8542 have other cases for encapsulated traffic depending on > driver version (right now I don't remember the state in 10-STABLE). > > Mark, let me know if I can help more. > > Andrew. Could you clarify what was meant by Virtual Functions ? Vlans , laggs etc or srv-io ? Also I do have IGMP snoop enabled and routing is done locally on each router -, the freebsd box with the sfxge cards. -- mark saad | nonesuch@longcount.org From owner-freebsd-hackers@freebsd.org Wed Oct 25 16:34:31 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EE301E4EE4F for ; Wed, 25 Oct 2017 16:34:31 +0000 (UTC) (envelope-from zbeeble@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 822F3748C3 for ; Wed, 25 Oct 2017 16:34:31 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: by mail-wm0-x229.google.com with SMTP id b189so2985834wmd.4 for ; Wed, 25 Oct 2017 09:34:31 -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=jKm+m3/ve+wetkD3irITFA/KNl0Oaj6B1MQVIGqlhKw=; b=D/9Lczdf4KctjYtJQExJuiF2Zr7b9LDoNwE971g71y9Onz1TPalLgnnMxxy7MVSzDa gHY+9rWljCeoUQ+U78P2l9IPZgv9rgDMSglzELzHL4fduu8HtbgMb14JfgPYyIOlG2W1 fanEkt9+d8o697HeSN8ir5Run/RpVs/JnRA4v+UylNv9SDURyj9mav7TvnplLfyjQmiZ Waeb8Dham3ePWTVh5ZsJ6i0GvH0HhVVUp/BscU41+VsOgZkZTYlerXWcT94fxB5jGFXK qYjCGDoRwmVjyhsRJXn6gKJ86iLAUGUG3IqUurqfXeQyaH5XcviSNp74qSxiDhhLUmG8 9v9g== 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=jKm+m3/ve+wetkD3irITFA/KNl0Oaj6B1MQVIGqlhKw=; b=gpWaBPaKz6LI/6jR8xPNcE/kZBb1KGwocWdki5Uf8VDpwLZMvvu3LQ5lf2ECV3v/Vz qmaW4J+H6PcoMASLTG3IEHu3cQbBGibAjhcnASH0BlaUjnkPFLB8GroqwjVKEW1GwYTE iZkZIJ8S+K2lyqdKmpSl8NwPmAHMcR9PHuGfcut6WkdD9OVpg4eAlT0vltOOz0gI64gj G1Z2REBDvz7gPV0ywSX8vVvHLY1kbFgPfADzcCb1dMYyzYfn+KDjYlrTFhe2PxS48wmC CViAmrcue0sakyLc1IWlbgoBP14kO9aA845FMMOAD+ll91za34Z5wGeH6WeJojOxcZPz tiXA== X-Gm-Message-State: AMCzsaWgtDoHN4/60Y8iRCW9EblpCyavwLVFcMN1TgrjQsY3lCH/1wJi exM2uJcOOEh209WWKatlgRHD1N06SlqPcq7cjw== X-Google-Smtp-Source: ABhQp+S+TyU2S0ievd2ZJAMn4bpRwW3E9N3yL/c8/a0Acdt3R/BcNltert/cXcg3vaVCeV4vWjy+m8h/D09yy+fus1E= X-Received: by 10.80.208.222 with SMTP id g30mr24067501edf.246.1508949269937; Wed, 25 Oct 2017 09:34:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.189.139 with HTTP; Wed, 25 Oct 2017 09:34:29 -0700 (PDT) In-Reply-To: References: From: Zaphod Beeblebrox Date: Wed, 25 Oct 2017 12:34:29 -0400 Message-ID: Subject: Re: We do serial differently. To: Kyle Evans Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 16:34:32 -0000 On Mon, Oct 23, 2017 at 9:45 AM, Kyle Evans wrote: > Hi, > > Are you able to connect to it otherwise (w/ cu or friends) and issue, say, > an M105 manually? > yes. With CU I can connect, it resets, then I can issue an "M105" and it parrots back some status. Also, which version of Arduino IDE are you using that *does* work? (for the > sake of digging into why it might work while nothing else does) > /usr/ports/devel/arduino AFAICT, this is 1.0.6. From owner-freebsd-hackers@freebsd.org Wed Oct 25 16:43:50 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0CCE8E4F34C for ; Wed, 25 Oct 2017 16:43:50 +0000 (UTC) (envelope-from kevans91@ksu.edu) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0057.outbound.protection.outlook.com [104.47.42.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A3840750E5 for ; Wed, 25 Oct 2017 16:43:49 +0000 (UTC) (envelope-from kevans91@ksu.edu) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ksu.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Gw4Z9dyar8lFRkIRWKTiX0PmDdMSsUPr1zleJRi4Fyc=; b=PmZ85HAqSRlTDiwF2YagdiXMx3xnrLAapQUmYo8kDlXmKuqQBTWJPYXJHcOvHJmqIwqjS5FcuJpjR3eogtRMLazYIyS8cAiaDX+h8ds/TUTPhK8nG1A/UyZ4480n7nWCDBT7PLqCEViYXsk5Wxe+BqUuvi1bvM/XY43K7Xma0Uk= Received: from BY2PR05CA029.namprd05.prod.outlook.com (10.141.250.19) by MWHPR05MB2989.namprd05.prod.outlook.com (10.168.246.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.3; Wed, 25 Oct 2017 16:43:48 +0000 Received: from BL2NAM02FT004.eop-nam02.prod.protection.outlook.com (2a01:111:f400:7e46::200) by BY2PR05CA029.outlook.office365.com (2a01:111:e400:2c5f::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.197.4 via Frontend Transport; Wed, 25 Oct 2017 16:43:47 +0000 Authentication-Results: spf=pass (sender IP is 129.130.18.151) smtp.mailfrom=ksu.edu; freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=bestguesspass action=none header.from=ksu.edu; Received-SPF: Pass (protection.outlook.com: domain of ksu.edu designates 129.130.18.151 as permitted sender) receiver=protection.outlook.com; client-ip=129.130.18.151; helo=ome-vm-smtp1.campus.ksu.edu; Received: from ome-vm-smtp1.campus.ksu.edu (129.130.18.151) by BL2NAM02FT004.mail.protection.outlook.com (10.152.76.168) with Microsoft SMTP Server id 15.20.156.4 via Frontend Transport; Wed, 25 Oct 2017 16:43:47 +0000 Received: from calypso.engg.ksu.edu (calypso.engg.ksu.edu [129.130.43.181]) by ome-vm-smtp1.campus.ksu.edu (8.14.4/8.14.4/Debian-2ubuntu2.1) with ESMTP id v9PGhfHt031255 for ; Wed, 25 Oct 2017 11:43:45 -0500 Received: by calypso.engg.ksu.edu (Postfix, from userid 110) id CA341248007; Wed, 25 Oct 2017 11:43:41 -0500 (CDT) Received: from mail-io0-f178.google.com (mail-io0-f178.google.com [209.85.223.178]) by calypso.engg.ksu.edu (Postfix) with ESMTPA id A449F248345 for ; Wed, 25 Oct 2017 11:43:39 -0500 (CDT) Received: by mail-io0-f178.google.com with SMTP id h70so1684490ioi.4 for ; Wed, 25 Oct 2017 09:43:39 -0700 (PDT) X-Gm-Message-State: AMCzsaWNvdhlLFXuzrxqfzp6osv0t1HPRNnI5s9y7B6sIQRno9XQ+TMQ 3h/h7yB8C6zg/IqPGCb5/RZ+VOfDJlp081w8GsE= X-Google-Smtp-Source: ABhQp+R7nE/h5wWLwRNR+7QexzzoBpMZ8+Winh7zQHVN57URMB4FEjP8WamUHXuQ7FzGm3FplIaJZBZNRGqLdkMZRkc= X-Received: by 10.107.174.94 with SMTP id x91mr25520375ioe.224.1508949818701; Wed, 25 Oct 2017 09:43:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.23.129 with HTTP; Wed, 25 Oct 2017 09:43:18 -0700 (PDT) In-Reply-To: References: From: Kyle Evans Date: Wed, 25 Oct 2017 11:43:18 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: We do serial differently. To: Zaphod Beeblebrox CC: FreeBSD Hackers X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:129.130.18.151; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(346002)(376002)(39860400002)(2980300002)(438002)(189002)(24454002)(199003)(61266001)(95326003)(9896002)(246002)(86362001)(8936002)(42186006)(316002)(9686003)(786003)(236005)(59536001)(498394004)(16586007)(229853002)(98316002)(189998001)(8576002)(8676002)(46386002)(93516999)(356003)(45336002)(2950100002)(53546010)(54356999)(76176999)(50986999)(5660300001)(478600001)(1411001)(4326008)(305945005)(6862004)(2906002)(88552002)(84326002)(106002)(512874002)(3480700004)(55446002)(61726006)(6246003)(75432002)(106466001)(90966002)(55456009); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR05MB2989; H:ome-vm-smtp1.campus.ksu.edu; FPR:; SPF:Pass; PTR:ip-18-151.net.ksu.edu; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BL2NAM02FT004; 1:k1yTtpy7ToB06Tn6Jy+OxCcCnyh7EM4d5g3E30SNx92XeNj8x654sA4DZm4KJ7g8xE+/D6nfj1NiSxuOVu+d/ZGfJdxk54zZyvv0yqeOLkFwXMb+vGbr2YeKG0UIYmL6 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 4c4fdb5f-f2f4-4c0a-b2e3-08d51bc79011 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(8251501002)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:MWHPR05MB2989; X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB2989; 3:/SiE0fd98x++dFUmo62bGCfBm3ZmB779+n3h78qmnyyJ1hjrI5w0PzDwHLaIkTCNGIvF8DlHvCLY6PeVslbEKFb7pCh/KYEnVhuhGkpHaCia2X8/E2RmuGQtXckdRMz+IqM8/LdkUQB8RgzD4X1h2xucKvte+20W+hrmlnLEmSwwE52rOO+iS3v0K+QC70V7OiEhUwX4LZ2wSTmeAbqcKh45VhFXeZtROb+KfzbkFztObBLq48GFJcFmfjZA1aolcgbZr9Anf4BJt1/gTW4ZdwIbh4LGgxhGeO25G7/uaJKPK2CqpOtcwzI18gJOfNG9emUIkNm6sP3hR2d7Ij3E2jGRkOtDjSl3ANFqRYB9gQA=; 25:FX6JQ3vBy6NIzL64RuBkjincgbt4XaiG1s/LA31YyXGj5lYsLvy5GQrdF0eb+FdC7sMIA48yOenAItGUTFEOXcmWgGhvrc4MkkZivkXaNZmqRlsXC96BzDFt8PxC5hX7sf7JKE0v8XmyZtsEUzkvyT9YX/prSwl4WGJ5x+fC8fjo58fO3J9WJiKHJajCzyzE+wEt3rjoO9ov4JRvRB9OTCqGkcxwm5hxtnrCF0JS5bIyrvigHbNKiSn5UhXxQWeGD4JfsvBZSWzpuoqvtmR8erCiKAoD6TEOqRzXtBLGKzLvOy7i5plqu1YVYTf0Ykf+zg6xRGEGj1C0dxcSPDVyEg== X-MS-TrafficTypeDiagnostic: MWHPR05MB2989: X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB2989; 31:KPs0tsZrcltC+1xrsaCimLM/KC/o3dCGNHYAoJ/GYNO5M+ZnO7fp/Dknw7UL+zSD651SLPa3xXWfDpUtw4HBLeYA1j98X7bXkjxiF/QjDFxzmHX+TKn+zWpUotbWZj/xn/dkUtGf8oFUIhRAlBuk/eFu6dHcPbHxCEjJuKR0nkKi0qPLHKM7IG/0zPHtXgh0Qb49kZn3EzTfGPwkHE9HXgrHnAxRF2oIPRhjsUXAeKE=; 20:UCtPXo/ilqMK1QusPt2tceSmRzIp+yWDEc1gnXpuQqiwiWxVfrIV/+FpwTEF81RU/mpsEhJTp+ayRqGuDVuBRd1XMYcIvH4emwoTJVY2Q8ckjRBVKhO6r4Cm1YieE7arvEHdQADR6ZBNlmyn5B0PzWJWz2qyNP0rRvaW9eSORkyFUMGZC3ace+B71dRPC0+9/fGMmHCyvxJrMBKOhLfkqYi21lB4dYT+6qG/2xURYbfLvUOPnAtwvAyqJDvFwq6wE16su40vYxWLwyTGhDCBiQJE1CrcFCDTRzjpgtcyCFI3wPPoUKWo2jko+yoHimjzuhnbdT5JyfI67S1tDXOjZlkiwQYH09ChJ0OY6/L7UC19Qi7MJ7OSFyaJnzBb9mYvmpJK+xi4e2aCMEykv1YCZ/wpl6OJqzcBn0Tx31oSjSqaE4J3zBQcCwS3KxtpDxOLhDx9A0t8PLBTD01nLW5joUg3bDYRvUWv/xpcss59NzKjgM3aIQRL9ivbKLUUDaDk X-Exchange-Antispam-Report-Test: UriScan:(112903893386949)(21532816269658); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3231020)(100000703101)(100105400095)(93006095)(93004095)(3002001)(10201501046)(6041248)(20161123562025)(20161123555025)(20161123560025)(20161123564025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR05MB2989; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR05MB2989; X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB2989; 4:MzB3WLM3Qpr6zVb6lPQ0YqNS9Ox8dqA5OA0w7z/4NM4JrSNldBuC14Sl8jyKQWM4MF3ez4Bg507z4/UJqFPaOq/HAtywC8e2dFYenECXMZQdKFcAfJF4ToJdEf2Fq6RrXnPXpuQqGMS36cQhOHqFG/0w4GHqmPIKvmZ2mmQsVZUzU6er+d9+X0NE7ilGoIlb0E/4rQ+3Vez8CWVl1+k59L7cuZhv1BW7wC1bzHRxTmYNVbB117l87AjWcDLcSM1EYy7TR+Mdz6WBmqMxJ70kFMb+16MqHMOAOjL43JC0ZDp7Rwwyvup1M0KwpF+u78ClOso3iIwqGVPrST8hq3g7hEFS9gFcWbjBEYh5k+7iEJM= X-Forefront-PRVS: 0471B73328 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; MWHPR05MB2989; 23:RYg55UMNVL4RQsNj4BBo8G2leMEjXAJKhOTOKQC8B?= =?us-ascii?Q?rAY67PUfpzJFelbZ86fHpBN0WSd5Uw0rrbTpQKyMfm2PPowSJzxDfyyhmlzt?= =?us-ascii?Q?afdTWpWBSEMI47avtVxFKuoQSdaN/y6fbYpRxJv4oOo2b8elDU495DVTBaCj?= =?us-ascii?Q?hfaHvvZZGpKDx3uuGRP6sbEPmNcqy2+iQXhpmmHl9qusyOFklfXfp5AZR4Mz?= =?us-ascii?Q?fxsOK/cdhTzBSakF3RqFiB6vTWRKolGc20IYFAW3iRY1s89ib1iJtqRaNb+T?= =?us-ascii?Q?BCWS97lm1E1LbLDBIDG/6LkyQlIPpNS8o+CvNqcHvyl/pTyG9MubQVlyOLyQ?= =?us-ascii?Q?cIhU70tUPsoERspWR1ih24b6LTw0M7jNbSvRo3i1zKKlPwxRPD9tBHm2wUbS?= =?us-ascii?Q?OZHGFw/qotsNw1815qjIzaYaYoBPd7Dm0rB1WPIqqEskrs1eECuUvP7G7zUd?= =?us-ascii?Q?qeU6ytE3IKggGqxc1SFONwPGJYNA6RCmX9kIOK2W3GiPTZ2iXKsj6Ng7QWiX?= =?us-ascii?Q?imTfqutZfx1OdUpRJQNRs81I0duhnVKnfKsXrzoWdvMAOWYZs/L9bTxCSD/w?= =?us-ascii?Q?ZZlVdY+J1bvEUdLHjabFhLZCQPaFLBVB6A5vjcXopzJ7c74yNqEazy8U6zGU?= =?us-ascii?Q?BcZJPPbpLeE3yXaGq1GuiIWpkrj5ckWatix1D/anxGWDf65gurirJVUdZxPv?= =?us-ascii?Q?VeVx6SQdRGz/NRyz3/hxmk87WVufd8lu4uWN6HZ3ZinQZVMsEgr4GM8o5ETN?= =?us-ascii?Q?ID85hLNGwjClNfSG1DCa5NPlSoOtGn6FYr/IB/mlPxoVaM0yFFXwSzdAix9D?= =?us-ascii?Q?suU+w1bLVPL93sSvOrVCZA0C4QVIEcgyRS9NPvv/TfKBHDPKHyqPWwrQMRHK?= =?us-ascii?Q?fWCVy+aVMFeAbFzaCRmngzi0VOI3c48IfeZ7gKWFxKKFl+zUawDKTxWLRIa3?= =?us-ascii?Q?Q4A89jrLxbrqg2uUzv6b3YBa9HcHrQL8UGwbvyH00/uYqfCl3BR6UpEv28n1?= =?us-ascii?Q?qnmt9sRLCcfx8qRSlQvJ8ppW1MK8jscqA6qWkpthXgcMwLH7JKEXkZFnEQeN?= =?us-ascii?Q?QuDsvaWQ8VmQxM1yNnSHoSAO6NcsXyGH/EVkA11ySWgjFGGEF85P4DNw9BPW?= =?us-ascii?Q?Bp47LU07wo+sL8tZ4JEkiycRrbBB5xdzJ5IahIDCzCWtRq1x1eXEQW/+UWAR?= =?us-ascii?Q?vZhpXLUGW3ao8JxcnZqRJZvG3w22N8blh8BIvg3jP9B9P6V+wFB0mfDPXEG0?= =?us-ascii?Q?RVRH5Mf+qRAI5z+mgyWkln9odrI5OLlVC9g8aqV?= X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB2989; 6:F36pRwRlAlvddOJiq8ixK8DS5rH+XLBZwIsaf5EZp1F9BguP4wFrAzvBd/jVQ5ImsgSLyqBssni0N1ylWgsZBLAmWdgSJFYUknqxWKLniEgYxd1Eux6fn2dydjU2UiU7TFver5UN17fIRtSMLlcdY5AhHJoVWr8+/UVecdq6APnd1ucmBw9kPObbyeKqJpdBBfMqegcEKcNPUSlj6fVESb008OeBoXPrHaGG5bvOkM8AsBmBQFC9PiXZAepr1zxrpA44MpqbHXMECdiAa/PehVoI/4gooZrsq9GvB53JFlVjZXcenlJycE+81xZX3JuAPMsMswlJNi2/Oma9ftOwtqKqMKsSnOmCGkmc5ghGlwk=; 5:WfUP7K0AB+7XMT4vKrP9/RNdAtrCNZSRDnpmhhVc4IcogEKxd/2EhfPH0FrDYNZp8QJbfn+x9ZJnzghC7vsOx2dhNpcVcuF63RN1mUTOyPrQxlUl5WeMtTgQ+fYZITmd6G/rrjSIGRV8ZiZGd3ZWcsAOqb7NS5R9Bok/1syL1cM=; 24:mM+jrkfohAwqnaWYp1KFOWgVf+eoIQ8yyIOdW4yW/jn751N4CX2pBQXpQVp4N8QClVivVHUNOm2OVkhskDuj9ZHUKKrTPYBsHVdyE+skv2Y=; 7:fvumToz6ev6fYeKLFxHMMcCduP9dGLKmAye+B32xr6id5ClHOwCkByIfT+S9B7Mlzr2gSUjBtRFX0LDFn0UVEGPNzdpmQqW1vSMqrZNUFos3zYgCZ0JsJHbPwh/1BpbiLBKiSXeu4becEGqZJNuzMIZxv+zesJYhYJ1FT3xtXec8ZUOb6V8iak+IU5S+V85MEHyV/MquzzLKGy80MW9YttggEIQRmjvo26WcyCuyW4Kon2qQMxJM6c0NLK17OtFt SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB2989; 20:fYkIMAfTBbKs/hdIuCTa0fyHjWx7uPheGIiL4QZJIk5U5U3Ua6BPWCtryg/DGGobEBC0byTuX7C+14rBuiqNKqT6satljD+Lpus0P3R4nBZkD7JBsKaiS7AdAtGFEV2CZh1AoB/6Vfs8n7pXVXWruyd4xMiFTZqidPoqitg0A/0= X-OriginatorOrg: ksu.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Oct 2017 16:43:47.0439 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4c4fdb5f-f2f4-4c0a-b2e3-08d51bc79011 X-MS-Exchange-CrossTenant-Id: d9a2fa71-d67d-4cb6-b541-06ccaa8013fb X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=d9a2fa71-d67d-4cb6-b541-06ccaa8013fb; Ip=[129.130.18.151]; Helo=[ome-vm-smtp1.campus.ksu.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR05MB2989 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 16:43:50 -0000 On Wed, Oct 25, 2017 at 11:34 AM, Zaphod Beeblebrox wrote: > On Mon, Oct 23, 2017 at 9:45 AM, Kyle Evans wrote: > >> Hi, >> >> Are you able to connect to it otherwise (w/ cu or friends) and issue, >> say, an M105 manually? >> > > yes. With CU I can connect, it resets, then I can issue an "M105" and > it parrots back some status. > Ok, cool, that's expected and sounds like Pronterface is doing something it shouldn't be. I'll poke at it a little bit more- last I checked, it didn't look like it was doing anything too crazy with pyserial and I've got a working OctoPrint (w/ pyserial) setup, so I know that works to some extent. From owner-freebsd-hackers@freebsd.org Wed Oct 25 16:57:44 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 96596E4F5EC for ; Wed, 25 Oct 2017 16:57:44 +0000 (UTC) (envelope-from mike@reifenberger.com) Received: from mail.eeeit.de (mail.eeeit.de [37.120.160.187]) (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 5280B755D6 for ; Wed, 25 Oct 2017 16:57:44 +0000 (UTC) (envelope-from mike@reifenberger.com) Received: from localhost (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: mike@reifenberger.com) by mail.eeeit.de (Postfix) with ESMTPSA id 6A29A7F5C for ; Wed, 25 Oct 2017 18:57:36 +0200 (CEST) Received: from ppp-88-217-121-19.dynamic.mnet-online.de (ppp-88-217-121-19.dynamic.mnet-online.de [88.217.121.19]) by mail.eeeit.de (Horde Framework) with HTTPS; Wed, 25 Oct 2017 18:57:36 +0200 Date: Wed, 25 Oct 2017 18:57:35 +0200 Message-ID: <20171025185736.Horde.fD8dlUh60kLaxAfok91iHKU@mail.eeeit.de> From: Michael Reifenberger To: FreeBSD Hackers Subject: getting run_interrupt_driven_hooks: ... xpt_config in 11.1 (but working in 11.0) User-Agent: Horde Application Framework 5 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 16:57:44 -0000 Hi, on a VPS (virtual private server) (https://www.netcup.de/) I could install and use FreeBSD 11.0. After upgrading to 11.1 or latest 11-STABLE kernel I get every minutes at the end of the boot (before mountroot): run_interrupt_driven_hooks: still waiting after ... seconds for xpt_config. The host system seems to be using Linux kvm. Has anyone else seen this before? Unfortunately the debugging facilities on the VCS are quite limited... I have opened a PR 222548 for this. Thanks in advance! Greetings --- mike Gruß --- Michael Reifenberger From owner-freebsd-hackers@freebsd.org Wed Oct 25 17:12:23 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6699DE4FAB3 for ; Wed, 25 Oct 2017 17:12:23 +0000 (UTC) (envelope-from kevans91@ksu.edu) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0062.outbound.protection.outlook.com [104.47.32.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E0F7B76079 for ; Wed, 25 Oct 2017 17:12:22 +0000 (UTC) (envelope-from kevans91@ksu.edu) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ksu.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=w3KFZEvmQI2sEs2cQF9ARzB2ZnnEe3MQ+bgdOtfALhs=; b=UdjJvWzKfbQrjCemXHp7/iewdZRL4yMYY3FF18oqVwBNG3p428GXelX1qeED0ZF42j8dgZejssRASZzkg+99HoE1ZAiqbtsi/iPcovD69bV4MRgL4DddvNzRQY8yvoxcMYhK4hT5JVJPLmNAdYLoOwj1z/J9l84YuswVHaV0WJI= Received: from DM5PR05CA0020.namprd05.prod.outlook.com (10.173.226.30) by MWHPR05MB2991.namprd05.prod.outlook.com (10.168.246.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.3; Wed, 25 Oct 2017 17:12:20 +0000 Received: from BL2NAM02FT014.eop-nam02.prod.protection.outlook.com (2a01:111:f400:7e46::202) by DM5PR05CA0020.outlook.office365.com (2603:10b6:3:d4::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.156.4 via Frontend Transport; Wed, 25 Oct 2017 17:12:20 +0000 Received-SPF: Pass (protection.outlook.com: domain of ksu.edu designates 129.130.18.151 as permitted sender) receiver=protection.outlook.com; client-ip=129.130.18.151; helo=ome-vm-smtp2.campus.ksu.edu; Received: from ome-vm-smtp2.campus.ksu.edu (129.130.18.151) by BL2NAM02FT014.mail.protection.outlook.com (10.152.76.154) with Microsoft SMTP Server id 15.20.156.4 via Frontend Transport; Wed, 25 Oct 2017 17:12:19 +0000 Received: from calypso.engg.ksu.edu (calypso.engg.ksu.edu [129.130.43.181]) by ome-vm-smtp2.campus.ksu.edu (8.14.4/8.14.4/Debian-2ubuntu2.1) with ESMTP id v9PHCJQ5030387 for ; Wed, 25 Oct 2017 12:12:19 -0500 Received: by calypso.engg.ksu.edu (Postfix, from userid 110) id 7999F248007; Wed, 25 Oct 2017 12:12:19 -0500 (CDT) Received: from mail-io0-f175.google.com (mail-io0-f175.google.com [209.85.223.175]) by calypso.engg.ksu.edu (Postfix) with ESMTPA id 513A0248348 for ; Wed, 25 Oct 2017 12:12:17 -0500 (CDT) Received: by mail-io0-f175.google.com with SMTP id m81so1746728ioi.13 for ; Wed, 25 Oct 2017 10:12:17 -0700 (PDT) X-Gm-Message-State: AMCzsaWBNycoQk7dIxQJTNRfxpR7K2i6grEqpd85HRY/iUodOj+de5Tz K7IrtkjREskw4iR9AtoAaHjOY0sgC6sLTObnphM= X-Google-Smtp-Source: ABhQp+RcocAN6fnUFAwNpuBdZcZRH7DKnnDx21FXYILXNbelrxX0+Rw4Zfk85A3xSPqptDBNDrFI+JFIKEgqTz53P2Q= X-Received: by 10.107.20.203 with SMTP id 194mr25205604iou.6.1508951537011; Wed, 25 Oct 2017 10:12:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.23.129 with HTTP; Wed, 25 Oct 2017 10:11:56 -0700 (PDT) In-Reply-To: References: From: Kyle Evans Date: Wed, 25 Oct 2017 12:11:56 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: We do serial differently. To: Zaphod Beeblebrox CC: FreeBSD Hackers X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:129.130.18.151; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(376002)(39860400002)(346002)(2980300002)(438002)(189002)(199003)(24454002)(88552002)(106002)(478600001)(106466001)(498394004)(93516999)(93886005)(5660300001)(55446002)(189998001)(4326008)(95326003)(6246003)(2906002)(84326002)(9686003)(236005)(6862004)(98316002)(512874002)(46386002)(16586007)(8936002)(61266001)(786003)(316002)(1411001)(59536001)(75432002)(86362001)(61726006)(42186006)(2950100002)(45336002)(229853002)(8576002)(50986999)(356003)(54356999)(90966002)(76176999)(246002)(8676002)(3480700004)(53546010)(305945005)(9896002)(55456009); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR05MB2991; H:ome-vm-smtp2.campus.ksu.edu; FPR:; SPF:Pass; PTR:ip-18-151.net.ksu.edu; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BL2NAM02FT014; 1:yJRqMawl/htfpsghsYZxw8NDshmbIe0Fuaqgp68gKcDfFRe5NYKEBw7OL2UyCj3GEyEAYDF0boWxQqJzH8FoDuTbNAJ/911eiZTJ4hiraMUpU4wnILza/HKEvx7ml9fl X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 6d491daf-3d06-43ee-5e6f-08d51bcb8ccf X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(8251501002)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603238); SRVR:MWHPR05MB2991; X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB2991; 3:DvFEXL8pimTdnGpLTqJA3UXsOGWltUY8xxpjxXuXJ2SEE0E72/yDEjnAehghln5yUjRRvARiTESRJpx+QR4xFHrLwWnIm322jFVAu+YU64hs3BjThfkTWLb0aC6Df5Zr6WBZ2NxTL0Z16Lqa+1APQ5HlUI/BphEmRPvGsthEaC1PGeL+2xhkepOZyvpIeNG2b+Y+XeNWlwD1z8XPRuMkif+Oi+Z3y8cBTqrprTTIcc+AldngdtG46djR+aNRYAu85bqLz8+b+WSjB5K3vErQawlLi5yxrW4vpFbvQtZ9ATQpmzyt5Ab64crKKPDJAwcv+QfxEPqOMbvnmUGt4ptjhoh3/1FjdhGiE3INqVshMlc=; 25:ARQzDyV3IqakYg3TO2fe/t258BCIl8jfiNmfANNkEULghxcmLZsYE10ULlZPMqdA/nEs90O4rYOvHvmJGG47kah6uqmrA1BX2MD43jpXAm3mhOXSiugs3dUihPHENbio93rv2Pb7878Hi5ytpKRQDmpItj9bT9rL24Sr+oyk+CZmEhj4qk6+ufnGFx7uQkaqx2cGwgzTjQ6IK6DZr1JcEXKq0Cs+yLuM4lG5+2izNHhDShaZlqvItic11BuiRgD4wXEK8LNmNLItgATXzNLTASptKDuwFIOeBv5BgRUCwuQDijfcvjXpYtNdPA2aB2zA4eP2YV1ZlJ33moBGxUCHgA== X-MS-TrafficTypeDiagnostic: MWHPR05MB2991: X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB2991; 31:ZaIMNGl6/IE6+Zn9ZyXol+L2B+oRh/+IyIadMamP0me/U82xKlqEYb/O3SQDdkiZ6hX/FHHmMo0028Y8hppz6le6Zk8J92viw18O3DfXesi6srV4GRB1B9MDgy4midj0CQsx7Il/Q9sYaDJmQYQej3s3nXcWdwBo0na2aGJ+/n3pTiCbGawwwxkA8A0gnjG3oe3SJpfblsVud43ngS9qvukcrftJqvmo67a4MRRu2Wk=; 20:h80K7/AByiBvVhgHk/+B1VICm3wELP/TBz2EjuaFP/CEq/Vvrtb4kvnepBnpgTqI0hCuG/CNdPIhlpteL0kL1yUKqrYEkEMk7QWGgPtc2+9Meg0oEIFSFoJ2gsW55ZQnEO7fO+q086hr8zfNIu8694LUzN5znt2vEOMsJiYShyr6T0tnMfEZXd+d/yZy9XJ6Zn/Geb18USY3HBGsxdkjFaoiB1w5Zf34K/WoFRPBcz42UHnu6elorsGraNOVW3muc6iSfCUMO0gN5CWWwQs25ReIf813cuKnfno5NaynJN9+cqMLUrldDEeLTmLLZh4w0CKJOCWQqN33LApzxz0shLiLY7EuljjWiYBYkf+m7GMKEZ7xkdsH4l2KuGPxYqr6WEOM9OjP7wTK4hwTqDNxwfHWORXUgJhCo0hLGED4jhJCT2aenMM35GrEJt0pzz2a8CdzjyrPqzx12FVoC/Z915TmiddK3EYq2fwc78wTXlyn4wf90Q2SiOZVhWUPy6uC X-Exchange-Antispam-Report-Test: UriScan:(112903893386949)(21532816269658); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3231020)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93004095)(6041248)(20161123560025)(20161123558100)(20161123555025)(20161123562025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR05MB2991; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR05MB2991; X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB2991; 4:cl/BKKY8iD5AoLtadiIKd1RN3XmAQFE1TOHSI+NPm5V9D/jbMOrpPye8VJYiFswWEwvKn3NdUJzBRnC2LBNJ+ndfKWeCW/09jI1IfhwFnt00vyHwS2sN8IwmdSXddJHRMRYVg0DLOPyAf2sirlF3D5dkYQWIq34h1R9jBpfdm4bR0+NhbTFC11ptSyiGR7rB45RqKvQvcr6Fhc1aEJOrRQseNIjb9swWC+g97NLcRg8EWSnIUoqLRHRDL9cX31e0U9LfLuMfKTS8RY4ljXPC5xJmmdVwZflNg7MMiNtIBjniyUf8I+0aas9NwUH/bkARNywt+pFJwyG0k4S6kKhvTkPmtm5DI1jXCWUbsmCuR0Y= X-Forefront-PRVS: 0471B73328 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; MWHPR05MB2991; 23:zdwjHV99e/Womy9Cwbz9/N6D9DMb6Z/RZNsfrU/KH?= =?us-ascii?Q?8E26wzvRVDeJ0zE7Ope5THtJOfQJ2TdDYc3FhlO/Yv/xrUwZGHvGD942LERv?= =?us-ascii?Q?DgbmZAUxP8Psu/qXKk9z/Y4491iioTqVAOaQLyeq8Tg9U0IbwxeeizuVOgEv?= =?us-ascii?Q?pe1tqRTi8tiXqxofhHVSPUfh5p7VmXy7DSBpBqfZXx7hjfJBKTq/ZYPeSthi?= =?us-ascii?Q?op2JPGS/5GpbWcGYBBwAzOR8ysfMH7v6K2znz+5S2MGZy5aRp3TDPWdbptfV?= =?us-ascii?Q?f1LgMQhpBG6Hocd4K+aHUADwKrV9wx8SmSNGn9oTxLWipdQuCrA8MgGZ+hJU?= =?us-ascii?Q?IsrGWqpaW+NgXCJRG/9uXQUCHGuyiZRYJrDzRvqvBfCkwLHohUMIVXXfGFyN?= =?us-ascii?Q?nEGtPkKttpxAQ+IsaEdKchMIQGsJ+xu3Bci6i9klisI/GMhO28COBP08dw0b?= =?us-ascii?Q?sgmbrEpnxx4SrpckUPzRr35vwEEHA2yRNH6yiG5aYG8OAzuDE4p/4if/mHYH?= =?us-ascii?Q?Jr7MKaWYARNo4ey8sIByIBldTwMMC2njCsllkDfI7nSIGFHtO9baLrityhLC?= =?us-ascii?Q?orqDhsGbnxlzbVaiPc6xiPA6o9vw8oZW1xUy5t/XU5Dx67/71388KeqR/9a8?= =?us-ascii?Q?c3Lulu17aW864u22pAISDb/nlTgjM7VLmpQtevnbpQgu2Refg0pJOFrapJA1?= =?us-ascii?Q?Zl7j4zt3rgDlHhF1ltkGNE7frRDHD9nF31JhR1PbFvE69H8YnYuKp4IDqkJb?= =?us-ascii?Q?M39SMsgWaaBEEQgNvYSQm77EpjMtxTJBCWq6kA8C6D0huxve1XWv9MTfoIeO?= =?us-ascii?Q?KfRuTKQ5oqkEQ6ZtD+RwbmQhI1u/QhUq81v7AcUdRGr1MVJKJFg15favCGqN?= =?us-ascii?Q?O16Z5MFBUFFiEBuibYUx8lCG2ZiTPYpMwqwVzl2nYGjak4fTUq7drx1wWuhx?= =?us-ascii?Q?D+0FhdmBcqdbpM3n/Pzp7tbbCn0+kE6Bv8mHdJzXnC2dGevAXDt4T2Uvutfn?= =?us-ascii?Q?35kwRh7ifeRMMhCUdkIM9hGSkhGyDKcpLGgReBLpzQywhyd2ZZc9sARgZfCm?= =?us-ascii?Q?0fa2VdeZbZrvERxc2MyOKlHCEauW2UksvGUpwcw6fQ3lbmNjCuOw96u/QZh9?= =?us-ascii?Q?61JYPLh2Q3xVy/lDVgfjBj5l3o0aUmy6YPtdNc939ivuyg5LnzQPY33oiSiQ?= =?us-ascii?Q?1L12FKwp96aTbWwJH9zZnIeqyF792wAtPMhTrfdtmE6qAlj29JzgHFK6TzkE?= =?us-ascii?Q?ieZBFE9jmRXFae3eNCin4qbMXMx9JFWSasBCn2jqeZuKXpXpY6Xcl0lfyoX5?= =?us-ascii?B?Zz09?= X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB2991; 6:Z8nr8o/4hnJ1eyQDQpBVZECXCVDXB6wzKOasRQvNrTtCD59/AiIxpqqnnbmxmnZc6Cd2132Cz51OD/Q7a3PIlcbAmdu2Pql8nO2mn8i3UhEH9JPfoFHntY+8Rzfy447VnUjZZP7Jau4Wa6HcAhpck4Qe9kB92khuKVu7TLk+ew6e4uZqeXOTPQ5KwM4bJnK9NM+dfsomXsBFSVCtySkQos4fdI8YeuAm8S4ou7+s3CbniM4JaEiSw4YQ7qkgHfYS8vxxOUiFj7UGE1HD7h1fEb1XFDilBZK66UnOg7JT5U+rpco+QdNgiEgjpgybGFbHk7zrYHxL5wJFyIGw60YiyMtB1FAH+8SZm82ZxQuc4Gk=; 5:vCoVTaPSJSYhe5BCTTwW6d8gqJox+3VUAQgkYIQixAFgma5UWofQW3zaXczYbDq7F8IFEXgTGP85hW3nEiraEkO01Rw+T5t7kkSSOUM2Og9nR0g6oIKTZwdsZhCKO+2sDA01GxG3vdl/ctGzcVn1iAtYOSjmxViklxzJpIYgl9g=; 24:SacVZTIFShASsHxl5ZD03zjbgKFZuKEeXGt4MVgUIMspPn0/66zmAWkJ9QqCExaVjFKlIkIYmNGstGe3qFvCQ9uFfJFD7o5a8QzM2igZzP4=; 7:jAQpnKi7CZdHV+Nxw8uny+UTBJd4+/Nl/wnP2ZYBJEKqECubQAR/O/0jhAiGa4E8rwHaVAa4FptMbLGnLrpRtL/YfnfKWtJu+e9EfHaU/c+iRyXGMIfb1tDa/q2Iu4E4Ad6wtp+h/2QzQAraItwRo1lDbjDt4mREXEVPkzqjOBf/NLITvS4qOywvJ5bqAg/2gJf0XoSmvkaEnrMMc6oaML5ruHae9RlHlFThGxoVpCNTi0yj8V2iF/dc4wG3LQTI SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB2991; 20:rOb7sJTL1E0uilEKYrEHGmzjLMGaCIsEJheAlQTa01XCXDCLuKic2GnAcJVEvAI7lYdXhbXA2m/2exzRJ3+oq/Ccxgvpmf6aTpeNuIgxQqxNRFdin0V9Mwlle9kbUGMKZbgawNkZx0MGSj//i2sA4rXJHYXR/RKmqQdCQ/NgOpI= X-OriginatorOrg: ksu.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Oct 2017 17:12:19.5629 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6d491daf-3d06-43ee-5e6f-08d51bcb8ccf X-MS-Exchange-CrossTenant-Id: d9a2fa71-d67d-4cb6-b541-06ccaa8013fb X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=d9a2fa71-d67d-4cb6-b541-06ccaa8013fb; Ip=[129.130.18.151]; Helo=[ome-vm-smtp2.campus.ksu.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR05MB2991 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 17:12:23 -0000 On Wed, Oct 25, 2017 at 11:43 AM, Kyle Evans wrote: > On Wed, Oct 25, 2017 at 11:34 AM, Zaphod Beeblebrox > wrote: > >> On Mon, Oct 23, 2017 at 9:45 AM, Kyle Evans wrote: >> >>> Hi, >>> >>> Are you able to connect to it otherwise (w/ cu or friends) and issue, >>> say, an M105 manually? >>> >> >> yes. With CU I can connect, it resets, then I can issue an "M105" >> and it parrots back some status. >> > > Ok, cool, that's expected and sounds like Pronterface is doing something > it shouldn't be. > > I'll poke at it a little bit more- last I checked, it didn't look like it > was doing anything too crazy with pyserial and I've got a working OctoPrint > (w/ pyserial) setup, so I know that works to some extent. > > For the sake of argument, can you try applying the following patch [1] to printrun? I don't see a need to be toggling DTR here, and that might narrow things down a little bit. [1] diff --git a/printrun/printcore.py b/printrun/printcore.py index b54e750..fd531c3 100644 --- a/printrun/printcore.py +++ b/printrun/printcore.py @@ -218,11 +218,6 @@ class printcore(): parity = PARITY_ODD) self.printer.close() self.printer.parity = PARITY_NONE - try: #this appears not to work on many platforms, so we're going to call it but not care if it fails - self.printer.setDTR(dtr); - except: - #self.logError(_("Could not set DTR on this platform")) #not sure whether to output an error message - pass self.printer.open() except SerialException as e: self.logError(_("Could not connect to %s at baudrate %s:") % (self.port, self.baud) + From owner-freebsd-hackers@freebsd.org Wed Oct 25 17:34:09 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 10E91E50251 for ; Wed, 25 Oct 2017 17:34:09 +0000 (UTC) (envelope-from mpp302@gmail.com) Received: from mail-lf0-f42.google.com (mail-lf0-f42.google.com [209.85.215.42]) (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 9586476EA2 for ; Wed, 25 Oct 2017 17:34:08 +0000 (UTC) (envelope-from mpp302@gmail.com) Received: by mail-lf0-f42.google.com with SMTP id n69so856456lfn.2 for ; Wed, 25 Oct 2017 10:34:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=LiPyertOv8TIz8FPVpX4VfCkWXprun9nWQgTsD0yM7k=; b=WWtzsAzDFPyyI38DtHbKvnokNIELwQmt34krTwEGgEgbu2nqNXO7Moy5FWRflUnvC6 Q8y+fBYKmLlP/rI7fSj1y3JxR4XQ3MeKhOQrGbyH37JF5WGtYkyou0TOelvRN0PWPDP0 SemGZHuxSa8YRmyXxKWjxgmibiYSAx4oWlQT4Ee/gSG/hMXcv0DE41Ra543kR7RYmnHa GK6Rl/9W3CcHTjWPJLdg/uiQz71BFPE7XFrOt+Mi4YkOQYQWUNWuJT3362SgsKANZwBU 6f3mKePT9RWy6ykSJV9Jy+g3RNNd6UUjAWVhrNiRzt3IyOakMqMz6rMcdw997r3uF4cX REtw== X-Gm-Message-State: AMCzsaVzY9Q1Ps4BlA2D7dBRZem6225bXdDVa8f2MmEioQ/lcKlTdsyM EZqt5x+r/3ndi15F3ZBj/XQBPT2R X-Google-Smtp-Source: ABhQp+TgcAa5W0OvK7/wHPqN+2dK7U43xQQRDWfW6kyFu+94P9Ta8QCypvtTDNScL7LeckIXDxdlcA== X-Received: by 10.25.28.77 with SMTP id c74mr3856742lfc.6.1508952458431; Wed, 25 Oct 2017 10:27:38 -0700 (PDT) Received: from [192.168.1.105] (89-76-8-18.dynamic.chello.pl. [89.76.8.18]) by smtp.gmail.com with ESMTPSA id x124sm690438lfd.58.2017.10.25.10.27.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Oct 2017 10:27:37 -0700 (PDT) Subject: Re: getting run_interrupt_driven_hooks: ... xpt_config in 11.1 (but working in 11.0) To: Michael Reifenberger , FreeBSD Hackers References: <20171025185736.Horde.fD8dlUh60kLaxAfok91iHKU@mail.eeeit.de> From: Mateusz Piotrowski <0mp@FreeBSD.org> Message-ID: <717e40fa-8b90-f7c3-c401-ce3dc63f2d4c@FreeBSD.org> Date: Wed, 25 Oct 2017 19:27:37 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171025185736.Horde.fD8dlUh60kLaxAfok91iHKU@mail.eeeit.de> 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.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 17:34:09 -0000 On 25/10/2017 18:57, Michael Reifenberger wrote: > After upgrading to 11.1 or latest 11-STABLE kernel I get every minutes > at the end of the boot (before mountroot): > > run_interrupt_driven_hooks: still waiting after ... seconds for > xpt_config. I had a similar problem on a laptop with FreeBSD 10.2 RELEASE, but in my case the system just hung on that message for ever during boot. I was able to solve it by tweaking /boot/device.hint. I posted the details on SuperUser: https://superuser.com/q/1055316/442991. Cheers, Mateusz From owner-freebsd-hackers@freebsd.org Wed Oct 25 19:19:54 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EC33DE52337 for ; Wed, 25 Oct 2017 19:19:54 +0000 (UTC) (envelope-from zbeeble@gmail.com) 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 7F6487EF10 for ; Wed, 25 Oct 2017 19:19:54 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: by mail-wm0-x235.google.com with SMTP id z3so3932791wme.5 for ; Wed, 25 Oct 2017 12:19:54 -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=La4StO1j3EyBC7upYPHpwbpaAM0xPcgFItzQvULmodk=; b=avvHN28syNVaPERjq0MYTrBWK2AH3cs9f7qIXe7yeaPrzHMbY5w8YYacE7WImgit6v kJVUoK8+uqrUMHoROkWJUwpcoAzVGXdpi/Za4BjZ1x7IxujZX7tPyNsoXcG8TO/kZzwI zeapCf+3DOSXYsfpfgvkN73HKWx9Ned57owCDA7TgZuVJBvZcru2rfgz0QZPgAD72ElY 2ryCD5utimn3j7q1durXEeUyGqWMK800gX4bIn+cd+zZahDLteCIFCSNiESDHR4Y9UEZ 2rHu+ug+uNk8guw9sssMeVcgwxp6zesHcv0KHgp+oe/q14uVMdqRXs6AZo0Iyr4XNeiA wXSg== 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=La4StO1j3EyBC7upYPHpwbpaAM0xPcgFItzQvULmodk=; b=l2IdEbpWKSzeyVLyO+mriRLBrtOf3SWo69zy00D6bmm8drLxoxAmAF11VOKp/Cat4P 6EMZjGjUJXFrHtYbzpi33R3DSFRIOCYncm5pROs7wy5fMLL9x8PgrGyjE0i6oWMJZsZS pC9N8tdvX+arVIXCvGtuQmKrXmg/mRjX6XGKT11alfyhv4DVLvu5TshO8sfoCaSgjAj0 PlPLSJdGOZwXrmU/6l8bAdd+AYZKK5CZXDL55+pEdWDbzxC29UGEJqWXi3z4d7Qs9B23 AuDaTMkAmfH+ENAmlofSbftyRcM5MaXMC0qbs1yIetzR29AbruN//oHtmCBgJE7oWcLz Ir9w== X-Gm-Message-State: AMCzsaUSjZae/uq6n0gbplpNwS0fAUEAZIgQROcO0OxYtSbt7vDWZ5Gh 87XnrkPFY7c5XxaZqImZ4GGAWpbr6PIjbB1WtA== X-Google-Smtp-Source: ABhQp+SoFVj63RpqRfNlrpNgwTfTySopUIS9+9CzYyktfmMSgEgW83H0+3l8IXTSXwaj+jaaNAeGvVzGLSOXpkfry2E= X-Received: by 10.80.139.65 with SMTP id l59mr25302823edl.187.1508959193037; Wed, 25 Oct 2017 12:19:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.189.139 with HTTP; Wed, 25 Oct 2017 12:19:52 -0700 (PDT) In-Reply-To: References: From: Zaphod Beeblebrox Date: Wed, 25 Oct 2017 15:19:52 -0400 Message-ID: Subject: Re: We do serial differently. To: Kyle Evans Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 19:19:55 -0000 I made the change below. The system still cycles sending M105. From the serial debug window, I don't think it receives anything. It may be that the reset has started with DTR and not finished? On Wed, Oct 25, 2017 at 1:11 PM, Kyle Evans wrote: > On Wed, Oct 25, 2017 at 11:43 AM, Kyle Evans wrote: > >> On Wed, Oct 25, 2017 at 11:34 AM, Zaphod Beeblebrox >> wrote: >> >>> On Mon, Oct 23, 2017 at 9:45 AM, Kyle Evans wrote: >>> >>>> Hi, >>>> >>>> Are you able to connect to it otherwise (w/ cu or friends) and issue, >>>> say, an M105 manually? >>>> >>> >>> yes. With CU I can connect, it resets, then I can issue an "M105" >>> and it parrots back some status. >>> >> >> Ok, cool, that's expected and sounds like Pronterface is doing something >> it shouldn't be. >> >> I'll poke at it a little bit more- last I checked, it didn't look like it >> was doing anything too crazy with pyserial and I've got a working OctoPrint >> (w/ pyserial) setup, so I know that works to some extent. >> >> > For the sake of argument, can you try applying the following patch [1] to > printrun? I don't see a need to be toggling DTR here, and that might narrow > things down a little bit. > > [1] > diff --git a/printrun/printcore.py b/printrun/printcore.py > index b54e750..fd531c3 100644 > --- a/printrun/printcore.py > +++ b/printrun/printcore.py > @@ -218,11 +218,6 @@ class printcore(): > parity = PARITY_ODD) > self.printer.close() > self.printer.parity = PARITY_NONE > - try: #this appears not to work on many platforms, so > we're going to call it but not care if it fails > - self.printer.setDTR(dtr); > - except: > - #self.logError(_("Could not set DTR on this > platform")) #not sure whether to output an error message > - pass > self.printer.open() > except SerialException as e: > self.logError(_("Could not connect to %s at baudrate > %s:") % (self.port, self.baud) + > > > From owner-freebsd-hackers@freebsd.org Wed Oct 25 19:28:20 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9DBBAE526D9 for ; Wed, 25 Oct 2017 19:28:20 +0000 (UTC) (envelope-from mike@reifenberger.com) Received: from mail.eeeit.de (mail.eeeit.de [37.120.160.187]) (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 62A077F62E; Wed, 25 Oct 2017 19:28:20 +0000 (UTC) (envelope-from mike@reifenberger.com) Received: from [10.0.4.113] (ppp-88-217-121-19.dynamic.mnet-online.de [88.217.121.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: mike@reifenberger.com) by mail.eeeit.de (Postfix) with ESMTPSA id 6E2247024; Wed, 25 Oct 2017 21:28:17 +0200 (CEST) Date: Wed, 25 Oct 2017 21:28:15 +0200 User-Agent: K-9 Mail for Android In-Reply-To: <717e40fa-8b90-f7c3-c401-ce3dc63f2d4c@FreeBSD.org> References: <20171025185736.Horde.fD8dlUh60kLaxAfok91iHKU@mail.eeeit.de> <717e40fa-8b90-f7c3-c401-ce3dc63f2d4c@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: getting run_interrupt_driven_hooks: ... xpt_config in 11.1 (but working in 11.0) To: Mateusz Piotrowski <0mp@FreeBSD.org>, FreeBSD Hackers From: mike Message-ID: <247EEE13-D58D-478E-B3EB-B21F2BB1C42A@reifenberger.com> X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 19:28:20 -0000 On October 25, 2017 7:27:37 PM GMT+02:00, Mateusz Piotrowski <0mp@FreeBSD= =2Eorg> wrote: >On 25/10/2017 18:57, Michael Reifenberger wrote: >> After upgrading to 11=2E1 or latest 11-STABLE kernel I get every >minutes=20 >> at the end of the boot (before mountroot): >> >> run_interrupt_driven_hooks: still waiting after =2E=2E=2E seconds for= =20 >> xpt_config=2E=20 >I had a similar problem on a laptop with FreeBSD 10=2E2 RELEASE, but in >my=20 >case the system just hung on that message for ever during boot=2E > >I was able to solve it by tweaking /boot/device=2Ehint=2E I posted the=20 >details on SuperUser: https://superuser=2Ecom/q/1055316/442991=2E > Thanks for your hint=2E This tweak was the first one I found and tried=2E But without success=2E Also a difference here is that the VPS only has virtual hardware=2E --=20 mike From owner-freebsd-hackers@freebsd.org Thu Oct 26 01:46:11 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 00487E59F6D; Thu, 26 Oct 2017 01:46:11 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id D134F64E3C; Thu, 26 Oct 2017 01:46:10 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 6AA8F34F4; Thu, 26 Oct 2017 01:46:03 +0000 (UTC) To: freebsd-arch@freebsd.org, "freebsd-hackers@freebsd.org" Cc: Warner Losh From: Eric McCorkle Subject: New behaviors for loader.efi Message-ID: Date: Wed, 25 Oct 2017 21:46:02 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 01:46:11 -0000 Following the earlier discussion on the fate of loader.efi, and in light of my GELI work, I've begun working on modifications to loader.efi to allow it to be installed to the ESP, while maintaining back-compatibility with the legacy system. There's a couple of points that probably warrant discussion before I go any farther. First, we'll need to figure out what to do with boot.conf, which previously contained the arguments that would get passed to loader. Personally, I think the logical place for this is /efi/boot/config or /efi/boot.conf Second, does loader.conf exist on the boot filesystem, or should it also exist on the ESP? I'm inclined to think this should be left on the boot filesystem, as there may be more than one, and it's potentially specific to the kernel installed there. Last, loader has typically relied on the fact that it's installed directly on the boot filesystem, so it can obtain a good initial currdev/loaddev. If it's installed on the ESP, it potentially has to go hunting for the boot device. I'm stealing (back) code from my boot1 refactor for this, which first looks at partitions on the same disk, then looks at all devices. The actual test, I'm thinking, is to look for /boot/loader.conf, /boot/kernel/kernel, and possibly other files. Of course, we also need to retain the legacy behavior so that existing systems don't break. So I'm thinking the overall procedure looks like this: 1) Parse command-line args (this is to maintain back-compatibility) 2) Load /efi/boot.conf or /efi/boot/config if they exist, parse the args inside as if they were extra args 4) If loaddev/currdev are set by command-line arguments, use them as-is and stop 5) Otherwise, try the legacy currdev/loaddev detection scheme (this will fail if we're installed to the ESP) 6) If that fails, check the preferred devices 7) If that fails, check all devices 8) If that fails, continue without a currdev (which will drop us to the loader prompt) What do people think of this procedure? From owner-freebsd-hackers@freebsd.org Thu Oct 26 02:58:12 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1A160E38C9F for ; Thu, 26 Oct 2017 02:58:12 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::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 D06A467A56 for ; Thu, 26 Oct 2017 02:58:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x232.google.com with SMTP id e89so3160561ioi.11 for ; Wed, 25 Oct 2017 19:58:11 -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=wa0ZBOu8RT7PEfVA+GqV76St9FtfslbFu329nq1okYI=; b=TjIwoK4LqsUPu0dtC9hss18afYbgcmWQU6mMvamqfbxF2Mlzk2K6yAjhphkBp7XyzR EK5m5B4i+4QLkmiSjy3UBR1XOJJPGXeCZ/U4EtgbkCj1sM+A9BhDyLAQCGg3phruKekQ JMDCwzhXvBsZpHf/lN+XmeT0ZkWKp8YIYQtzgF4e7TmqVorkxdT4pt7YdrykdNHbNsoC Y8XxM2b/I8LKX3BA7cDQM7wENsSCJvjFcvZO9h7aC/zvXkjv5jb8dd6fzEdM0Liunrsi TeTUW27av1jTCDP9WpNWeXZt6dPcC1Spd9F8XVUhG/l0TBz2JKKMw+SmCm7pTS1L06WB gEAQ== 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=wa0ZBOu8RT7PEfVA+GqV76St9FtfslbFu329nq1okYI=; b=DpBAnk640Av8mSrI1HfxH5oLqNUbHbRy/1wbZfCDNGPBtz2NxQgWK2srxLsHlKUiIG /APthBDgoZnKLrk7FteZWop0VjVgi0dQr3XxN2xBWwFmlVKHTxV3S0rwSLVY2VR0CuPK eQjFbANgKcelR5L0bA3hxBM6rPDANi+JgwzxQyxmY6Rg0aFCDNALgXHAjiRUqMNp+yc2 AX3ICGXTXE9wVUWFESx6HnQpQJz1Wg58twDqoKQ5Gs2NehIrDlC1pkWI48nExFbLX52M 9dZnyOVBXDGstDHviRRtl6szXcvuYJUYZqvUzIfiyZB9E4t+ttoXgrR50omockPv15QA BT4Q== X-Gm-Message-State: AMCzsaWbKuYJX+AbahhnOwCHWXTOF2y5pKoVTnn5gZyBm1C3dBuWxm5b SwKWZJkbdT4jP8y30OScJsbua6sAIqrCG3PXJ6V01A== X-Google-Smtp-Source: ABhQp+T98h7AhPkMXGOLgsQ3EPFMk2pSIaIDArQKACIuwPxAYr8WVv3QnzGKommh7A53cs3F/ts10lrlF8gsM5iIGNs= X-Received: by 10.107.27.7 with SMTP id b7mr16767338iob.136.1508986691127; Wed, 25 Oct 2017 19:58:11 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.57.22 with HTTP; Wed, 25 Oct 2017 19:58:10 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:903c:60f5:8b97:c431] In-Reply-To: References: From: Warner Losh Date: Wed, 25 Oct 2017 20:58:10 -0600 X-Google-Sender-Auth: SD_dFTP5MJXVYaU42pkguMLRMsg Message-ID: Subject: Re: New behaviors for loader.efi To: Eric McCorkle Cc: "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" , Warner Losh Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 02:58:12 -0000 On Wed, Oct 25, 2017 at 7:46 PM, Eric McCorkle wrote: > Following the earlier discussion on the fate of loader.efi, and in light > of my GELI work, I've begun working on modifications to loader.efi to > allow it to be installed to the ESP, while maintaining > back-compatibility with the legacy system. > Cool. I have some concerns, as this doesn't follow the doc I posted a while ago. I've not yet worked through the boot1.efi removal in that document, however. > There's a couple of points that probably warrant discussion before I go > any farther. > > First, we'll need to figure out what to do with boot.conf, which > previously contained the arguments that would get passed to loader. > Personally, I think the logical place for this is /efi/boot/config or > /efi/boot.conf > I would vote neither. If it belongs on the ESP at all, it belongs in \efi\freebsd\boot.conf. We now own \efi\freebsd, so that's where all our boot files need to wind up in our install. But I'm not sure that we need it at all, since boot.conf is only for boot1/boot2 in the current system (though it does set serial by default, which might be helpful to preserve). It would be even better, though, to use the command line that's passed in as part of the UEFI:BootXXXX environment variable. Since we have to move it anyway, we should do things in the EFI way, which is to store all the nonvolatile info in UEFI environment variables (and in this case, the command line / aux info in the BootXXXX variable). We really need to stop polluting \efi\boot with anything, except on removable media. > Second, does loader.conf exist on the boot filesystem, or should it also > exist on the ESP? I'm inclined to think this should be left on the boot > filesystem, as there may be more than one, and it's potentially specific > to the kernel installed there. > I think it should be in /boot/loader.conf on /, not the ESP. We should only have \efi\freebsd\loader.efi in the ESP. > Last, loader has typically relied on the fact that it's installed > directly on the boot filesystem, so it can obtain a good initial > currdev/loaddev. If it's installed on the ESP, it potentially has to go > hunting for the boot device. > I'm not sure that it should look very hard, and it should only look as a last result. UEFI:BootCurrent lists the current boot variable. It points to the UEFI:BootXXXX that contains a LoadOption variable. This variable contains a series of DevicePaths. The first one is what the UEFI BIOS uses to load loader.efi (installed as ESP:\EFI\FREEBSD\LOADER.EFI). The second one in the list will point to the kernel to load. That way we shouldn't have to go looking at all. We assume that the root is the same partition we load the kernel comes from. We should only go looking if we fail to find the second path in the LoadOption. I'm stealing (back) code from my boot1 refactor for this, which first > looks at partitions on the same disk, then looks at all devices. The > actual test, I'm thinking, is to look for /boot/loader.conf, > /boot/kernel/kernel, and possibly other files. Of course, we also need > to retain the legacy behavior so that existing systems don't break. > No, we don't. boot1.efi already does this, and legacy systems will already have this installed. So we don't have to recreate this behavior if we don't want to since updated systems will need to follow the efibootmgr protocol. There's no way the loader.efi will fit on the old ESPs we created anyway... loader.efi needs to cope with being loaded this way, but it doesn't have to recreate boot1.efi's behavior. All we need to do is to find / when we're booting of removable media. This means we can use a super-simplified method to find it. If you want something more complicated, you must use the EFI boot manager protocol. I'm in the final stages, btw, at work of reviewing code we've written to implement a mostly Linux CLI compatable efibootmgr. > So I'm thinking the overall procedure looks like this: > > 1) Parse command-line args (this is to maintain back-compatibility) > UEFI:BootXXXX also provides a way to pass this in. > 2) Load /efi/boot.conf or /efi/boot/config if they exist, parse the args > inside as if they were extra args > > 4) If loaddev/currdev are set by command-line arguments, use them as-is > and stop > I don't want to do this from the command line. We follow the EFI boot manager protocol. There's no need to invent our own here, especially since the loader's devices aren't familiar to people. It adds extra complication for no benefit. > 5) Otherwise, try the legacy currdev/loaddev detection scheme (this will > fail if we're installed to the ESP) > We don't need to do this... > 6) If that fails, check the preferred devices > At most we need to check the same device we were booted from if the EFI variables aren't set. > 7) If that fails, check all devices > I really really want to never do this again. It causes more problems than it solves and is part of the boot1.efi hack we should run away from. None of our other systems do it, and boot1.efi did it only as a kludge because it didn't implement the EFI Boot Manager protocol. I think we should do it as I described above: find things directly from the BootXXXX variable, per the EFI Boot Manager Protocol, and then fallback to the first UFS filesystem with /boot/kernel/kernel on the same device we were loaded from. > 8) If that fails, continue without a currdev (which will drop us to the > loader prompt) > That's fine. > What do people think of this procedure? > I have some issues with it. Warner From owner-freebsd-hackers@freebsd.org Thu Oct 26 04:53:12 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4CC9CE3C1A5; Thu, 26 Oct 2017 04:53:12 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2FCB16B5DC; Thu, 26 Oct 2017 04:53:11 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (106-68-116-116.dyn.iinet.net.au [106.68.116.116]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id v9Q4qwjL065082 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 25 Oct 2017 21:53:02 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: New behaviors for loader.efi To: Warner Losh , Eric McCorkle Cc: "freebsd-hackers@freebsd.org" , Warner Losh , "freebsd-arch@freebsd.org" References: From: Julian Elischer Message-ID: <5780cd7e-d048-51be-b995-53ce4e3f1e55@freebsd.org> Date: Thu, 26 Oct 2017 12:52:53 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: 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.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 04:53:12 -0000 On 26/10/17 10:58 am, Warner Losh wrote: > On Wed, Oct 25, 2017 at 7:46 PM, Eric McCorkle wrote: > >> Following the earlier discussion on the fate of loader.efi, and in light >> of my GELI work, I've begun working on modifications to loader.efi to >> allow it to be installed to the ESP, while maintaining >> back-compatibility with the legacy system. >> > Cool. I have some concerns, as this doesn't follow the doc I posted a while > ago. I've not yet worked through the boot1.efi removal in that document, > however. > > >> There's a couple of points that probably warrant discussion before I go >> any farther. >> >> First, we'll need to figure out what to do with boot.conf, which >> previously contained the arguments that would get passed to loader. >> Personally, I think the logical place for this is /efi/boot/config or >> /efi/boot.conf >> > I would vote neither. If it belongs on the ESP at all, it belongs in > \efi\freebsd\boot.conf. We now own \efi\freebsd, so that's where all our > boot files need to wind up in our install. But I'm not sure that we need it > at all, since boot.conf is only for boot1/boot2 in the current system > (though it does set serial by default, which might be helpful to preserve). > It would be even better, though, to use the command line that's passed in > as part of the UEFI:BootXXXX environment variable. Since we have to move it > anyway, we should do things in the EFI way, which is to store all the > nonvolatile info in UEFI environment variables (and in this case, the > command line / aux info in the BootXXXX variable). We really need to stop > polluting \efi\boot with anything, except on removable media. boot.conf is also used to set kenv values so that they have knows values when entering the kernel. POLA suggests that it should continue to do that. > > >> Second, does loader.conf exist on the boot filesystem, or should it also >> exist on the ESP? I'm inclined to think this should be left on the boot >> filesystem, as there may be more than one, and it's potentially specific >> to the kernel installed there. >> > I think it should be in /boot/loader.conf on /, not the ESP. We should only > have \efi\freebsd\loader.efi in the ESP. why not have both a place to set defaults for all Filesystems (in ESP)  and a filesystem specific one? (on the fs) > >> Last, loader has typically relied on the fact that it's installed >> directly on the boot filesystem, so it can obtain a good initial >> currdev/loaddev. If it's installed on the ESP, it potentially has to go >> hunting for the boot device. >> > I'm not sure that it should look very hard, and it should only look as a > last result. > > UEFI:BootCurrent lists the current boot variable. It points to the > UEFI:BootXXXX that contains a LoadOption variable. This variable contains a > series of DevicePaths. The first one is what the UEFI BIOS uses to load > loader.efi (installed as ESP:\EFI\FREEBSD\LOADER.EFI). The second one in > the list will point to the kernel to load. That way we shouldn't have to go > looking at all. We assume that the root is the same partition we load the > kernel comes from. We should only go looking if we fail to find the second > path in the LoadOption. > > I'm stealing (back) code from my boot1 refactor for this, which first >> looks at partitions on the same disk, then looks at all devices. The >> actual test, I'm thinking, is to look for /boot/loader.conf, >> /boot/kernel/kernel, and possibly other files. Of course, we also need >> to retain the legacy behavior so that existing systems don't break. >> > No, we don't. boot1.efi already does this, and legacy systems will already > have this installed. So we don't have to recreate this behavior if we don't > want to since updated systems will need to follow the efibootmgr protocol. > There's no way the loader.efi will fit on the old ESPs we created anyway... > loader.efi needs to cope with being loaded this way, but it doesn't have to > recreate boot1.efi's behavior. depending on what behaviour you are talking about.. loader.conf setting kenv values is pretty embedded into out product for example.. > > All we need to do is to find / when we're booting of removable media. This > means we can use a super-simplified method to find it. If you want > something more complicated, you must use the EFI boot manager protocol. I'm > in the final stages, btw, at work of reviewing code we've written to > implement a mostly Linux CLI compatable efibootmgr. > > >> So I'm thinking the overall procedure looks like this: >> >> 1) Parse command-line args (this is to maintain back-compatibility) >> > UEFI:BootXXXX also provides a way to pass this in. > > >> 2) Load /efi/boot.conf or /efi/boot/config if they exist, parse the args >> inside as if they were extra args >> >> 4) If loaddev/currdev are set by command-line arguments, use them as-is >> and stop >> > I don't want to do this from the command line. We follow the EFI boot > manager protocol. There's no need to invent our own here, especially since > the loader's devices aren't familiar to people. It adds extra complication > for no benefit. > > >> 5) Otherwise, try the legacy currdev/loaddev detection scheme (this will >> fail if we're installed to the ESP) >> > We don't need to do this... > > >> 6) If that fails, check the preferred devices >> > At most we need to check the same device we were booted from if the EFI > variables aren't set. > > >> 7) If that fails, check all devices >> > I really really want to never do this again. It causes more problems than > it solves and is part of the boot1.efi hack we should run away from. None > of our other systems do it, and boot1.efi did it only as a kludge because > it didn't implement the EFI Boot Manager protocol. > > I think we should do it as I described above: find things directly from the > BootXXXX variable, per the EFI Boot Manager Protocol, and then fallback to > the first UFS filesystem with /boot/kernel/kernel on the same device we > were loaded from. and ZFS? I haven't creates a UFS system for some time > >> 8) If that fails, continue without a currdev (which will drop us to the >> loader prompt) >> > That's fine. > > >> What do people think of this procedure? >> > I have some issues with it. > > Warner > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Thu Oct 26 12:33:02 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9E268E4889B; Thu, 26 Oct 2017 12:33:02 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 7039E7C99B; Thu, 26 Oct 2017 12:33:02 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [192.168.43.57] (mobile-107-107-61-161.mycingular.net [107.107.61.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id AC724114A; Thu, 26 Oct 2017 12:32:59 +0000 (UTC) Subject: Re: New behaviors for loader.efi To: Warner Losh Cc: "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" , Warner Losh References: From: Eric McCorkle Message-ID: <87ceccf2-09fb-1adb-6304-649961cae2d4@metricspace.net> Date: Thu, 26 Oct 2017 08:32:58 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 12:33:02 -0000 On 10/25/2017 22:58, Warner Losh wrote: > I would vote neither. If it belongs on the ESP at all, it belongs in > \efi\freebsd\boot.conf. We now own \efi\freebsd, so that's where all our > boot files need to wind up in our install. But I'm not sure that we need > it at all, since boot.conf is only for boot1/boot2 in the current system > (though it does set serial by default, which might be helpful to > preserve). It would be even better, though, to use the command line > that's passed in as part of the UEFI:BootXXXX environment variable. > Since we have to move it anyway, we should do things in the EFI way, > which is to store all the nonvolatile info in UEFI environment variables > (and in this case, the command line / aux info in the BootXXXX > variable). We really need to stop polluting \efi\boot with anything, > except on removable media. That seems reasonable, however it might be worth having a backup mechanism (boot.conf) in case the EFI vars get clobbered. Also, a file with the args can be more easily signed and verified than EFI vars. > I think it should be in /boot/loader.conf on /, not the ESP. We should > only have \efi\freebsd\loader.efi in the ESP. Also my inclination. > I'm not sure that it should look very hard, and it should only look as a > last result. > > UEFI:BootCurrent lists the current boot variable. It points to the > UEFI:BootXXXX that contains a LoadOption variable. This variable > contains a series of DevicePaths. The first one is what the UEFI BIOS > uses to load loader.efi (installed as ESP:\EFI\FREEBSD\LOADER.EFI). The > second one in the list will point to the kernel to load. That way we > shouldn't have to go looking at all. We assume that the root is the same > partition we load the kernel comes from. We should only go looking if we > fail to find the second path in the LoadOption. Right. The search would be a fallback mechanism, if all else fails. It doesn't even need to succeed; it just needs to make a reasonable guess. > No, we don't. boot1.efi already does this, and legacy systems will > already have this installed. So we don't have to recreate this behavior > if we don't want to since updated systems will need to follow the > efibootmgr protocol. There's no way the loader.efi will fit on the old > ESPs we created anyway... loader.efi needs to cope with being loaded > this way, but it doesn't have to recreate boot1.efi's behavior. OK, I was assuming there'd be an interim period where loader.efi still gets installed to /boot/, in which case the dual-purpose would be necessary. It sounds like you want to quit installing it there altogether. With regard to GELI, it sounds like it can actually be committed in parallel with any of the changes you're planning here. This would give loader the ability to attach and explore EFI partitions, but you wouldn't be able to boot a pure-GELI system until the loader-only setup is viable. From owner-freebsd-hackers@freebsd.org Thu Oct 26 13:20:32 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DBC20E495D7 for ; Thu, 26 Oct 2017 13:20:32 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) (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 6A3BF7DBDB for ; Thu, 26 Oct 2017 13:20:31 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from [194.32.164.27] ([194.32.164.27]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id v9QDKOaZ045359 for ; Thu, 26 Oct 2017 14:20:24 +0100 (BST) (envelope-from rb@gid.co.uk) From: Bob Bishop Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: hw.pci.realloc_bars Message-Id: Date: Thu, 26 Oct 2017 14:20:23 +0100 To: FreeBSD Hackers X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 13:20:33 -0000 Hi, hw.pci.realloc_bars controls a mechanism that repositions a PCI memory = resource if it can=E2=80=99t be successfully allocated at the default = place. It=E2=80=99s disabled by default - anyone know why? Seems to me that because it only comes into play in an error case it = would be harmless to have it enabled by default. That would have avoided = a recent case where installation on the HPE Gen 10 microserver is tricky = because its VGA suffers from this problem. Thoughts? -- Bob Bishop rb@gid.co.uk From owner-freebsd-hackers@freebsd.org Thu Oct 26 15:19:17 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 96E50E4C06D for ; Thu, 26 Oct 2017 15:19:17 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::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 4F812818E9 for ; Thu, 26 Oct 2017 15:19:17 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22a.google.com with SMTP id j17so6148461iod.5 for ; Thu, 26 Oct 2017 08:19:17 -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=/zo1NSMKNua/nxEFyGI8jawsjV+Y7YIfNqhzXgaNDgE=; b=Jyky03Qixvs0qrjk92e01/vp02MwHiRz1EnRTAFae9+2ok4DHTW6MESBN1JfE68p2C Ih7+aJBR0YH9K2aLLu3fkBPndjGp5ZEkbbGqUQ9WAaTcTRyNo/ds/1c/TyxUo6E1S2VG 8Wb+gBPwV+Zss6LvSZlwz5uv0J/jtbRj2b0TYG71IHMuH+ucD51Sn9vD3cYUxcM7DVAr v+m060dd2JNUJpc33f8duom3wEDcZBoEn1SQBrmVEfV7B7vrr9/4MDaVKR/a1EKcZ7pJ 4IhtPFqr1jPMSXIU5drxDHeQIeLyYGuLleV8AX8FKcv7c8Eev4i3aZcDY+9eidHy3VuI wgLA== 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=/zo1NSMKNua/nxEFyGI8jawsjV+Y7YIfNqhzXgaNDgE=; b=hnfScnIQWF0Enqxvty/fAy1FGsdzUa6F0vyY2Md3XvjXpu9WS9SGAxVDPS3byO2dlo Dts8dIvGhbkOfk+ynaW/qOFr+ryDlV11KlAu4DI6p2QU0f4vviXbAxCrHYMJxHfMdI6E 7wbsyQRQCA1bHYa6wqhD+1Ab0qyLZ6oPtYxtWydbIegnUAdoG6QXaBBEViSZ3/cmoJHt Yc9GHXbXc5eOSMM3qR3A4OV50kyKE/UkWJoQBPHQkcqxmHH86OXGRxcTM3qn3qpwAdqP n3P70G6jBssJxy5TcV+pbZm3twVThFT3il/hNWgxN1cTM/JG1ayATf3MVtRHlF+nB47D UUMA== X-Gm-Message-State: AMCzsaUR7CQ99ZAgSJB1j/IcgnJpOlZ9r25Eyy2KbYRtFEqVjgqScY0r HQly6k3rHDUsWk8n8w1a7D0uBJXI7xR5AudSKeV6Jg== X-Google-Smtp-Source: ABhQp+TAozaEDJwbObrVVbToU98ijBXS9sHSFTb5Zdbd8XIL+x+bWhVtn9cdGgB6mNVvT5UasMTLchm0eTjI6n63aPg= X-Received: by 10.36.69.100 with SMTP id y97mr2979555ita.50.1509031156531; Thu, 26 Oct 2017 08:19:16 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.57.22 with HTTP; Thu, 26 Oct 2017 08:19:15 -0700 (PDT) X-Originating-IP: [50.253.109.65] In-Reply-To: <87ceccf2-09fb-1adb-6304-649961cae2d4@metricspace.net> References: <87ceccf2-09fb-1adb-6304-649961cae2d4@metricspace.net> From: Warner Losh Date: Thu, 26 Oct 2017 09:19:15 -0600 X-Google-Sender-Auth: pDi-euoNyPP9XB4E5_inmkJbvi0 Message-ID: Subject: Re: New behaviors for loader.efi To: Eric McCorkle Cc: "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" , Warner Losh Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 15:19:17 -0000 On Thu, Oct 26, 2017 at 6:32 AM, Eric McCorkle wrote: > On 10/25/2017 22:58, Warner Losh wrote: > > > I would vote neither. If it belongs on the ESP at all, it belongs in > > \efi\freebsd\boot.conf. We now own \efi\freebsd, so that's where all our > > boot files need to wind up in our install. But I'm not sure that we need > > it at all, since boot.conf is only for boot1/boot2 in the current system > > (though it does set serial by default, which might be helpful to > > preserve). It would be even better, though, to use the command line > > that's passed in as part of the UEFI:BootXXXX environment variable. > > Since we have to move it anyway, we should do things in the EFI way, > > which is to store all the nonvolatile info in UEFI environment variables > > (and in this case, the command line / aux info in the BootXXXX > > variable). We really need to stop polluting \efi\boot with anything, > > except on removable media. > > That seems reasonable, however it might be worth having a backup > mechanism (boot.conf) in case the EFI vars get clobbered. Also, a file > with the args can be more easily signed and verified than EFI vars. So long as it's a backup method, that's fine. It occurs to me that it might be useful for removable media where you can't count on EFI env vars and you are bootstrapping such that you need the args (serial console is the canonical case). > I think it should be in /boot/loader.conf on /, not the ESP. We should > > only have \efi\freebsd\loader.efi in the ESP. > > Also my inclination. Excellent. If we do have a boot.conf to supply a backup way of specifying command line args, then we should look for it in ESP:\efi\freebsd\boot.conf. > I'm not sure that it should look very hard, and it should only look as a > > last result. > > > > UEFI:BootCurrent lists the current boot variable. It points to the > > UEFI:BootXXXX that contains a LoadOption variable. This variable > > contains a series of DevicePaths. The first one is what the UEFI BIOS > > uses to load loader.efi (installed as ESP:\EFI\FREEBSD\LOADER.EFI). The > > second one in the list will point to the kernel to load. That way we > > shouldn't have to go looking at all. We assume that the root is the same > > partition we load the kernel comes from. We should only go looking if we > > fail to find the second path in the LoadOption. > > Right. The search would be a fallback mechanism, if all else fails. It > doesn't even need to succeed; it just needs to make a reasonable guess. The fallback mechanism should try too hard though. Trying hard gets in the way of many things. The biggest one being when I have multiple disks in a system that have multiple copies of the OS. You want the fallback mechanism to try as limited a number of things as possible then FAIL so we can go to the next BootXXXX in the boot order. So long as the guesses are super limited, and/or only done done when we don't specify something explicit, then that's OK. So the change from the present would be: (1) If a second path is specified in the BootXXXX option, then boot it (might want to look in the list to generalize this, but for the moment that's an enhancement). If we fail to boot an explicit path, fail back to the EFI boot manager. We were told to do something explicitly, and we couldn't do that, so we shouldn't go guessing (this includes ZFS BE, UFS, etc) (2) If no path is specified and if we come from a UFS or ZFS partition (the boot1.efi vector), then try to boot the kernel off of that partition. If that fails, then fail the boot back to EFI boot manager. (3) If no path is specified and there's ZFS BE we can boot from, boot that (fail if we can't) (4) if no path is specified and we can find a UFS partition on the current disk, boot that (fail if we can't) Otherwise fail back to EFI boot manager for the next one on the list. > No, we don't. boot1.efi already does this, and legacy systems will > > already have this installed. So we don't have to recreate this behavior > > if we don't want to since updated systems will need to follow the > > efibootmgr protocol. There's no way the loader.efi will fit on the old > > ESPs we created anyway... loader.efi needs to cope with being loaded > > this way, but it doesn't have to recreate boot1.efi's behavior. > > OK, I was assuming there'd be an interim period where loader.efi still > gets installed to /boot/, in which case the dual-purpose would be > necessary. It sounds like you want to quit installing it there altogether. > Yes. I want to get loader.efi in shape to be the primary loader, but won't get rid of boot1.efi right away until the installer catches up. A small case could be made for having boot1.efi for legacy users that keeps simple UFS / ZFS features we have in 11.x, but removes any features we've added since then. It's still unclear to me if that's useful or not. > With regard to GELI, it sounds like it can actually be committed in > parallel with any of the changes you're planning here. This would give > loader the ability to attach and explore EFI partitions, but you > wouldn't be able to boot a pure-GELI system until the loader-only setup > is viable. > Yes. I agree. I'd like to see it so you could install one by hand in the base prior to the installer supporting that. I'll have to look at the individual changes carefully, but at a high level when I saw them they looked like the right direction. I'll try to find some time today to update the boot document and to try to draw in points you have in your chain of trust documents because that's also important. It might also be worth bringing in the 'self contained load env' work that I know is going on elsewhere (basically, you load a loader with a MD burned into it and boot from that, with the entire loader.efi signed such that the shim-loader that floating around can load and verify it -- a lite version of the stuff you are working on). Warner From owner-freebsd-hackers@freebsd.org Thu Oct 26 15:31:44 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 526F3E4C5C4 for ; Thu, 26 Oct 2017 15:31:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::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 0BC0082229 for ; Thu, 26 Oct 2017 15:31:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x233.google.com with SMTP id i38so6248997iod.2 for ; Thu, 26 Oct 2017 08:31:44 -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=ETt4R0bGXs6DhHkvvbGjeUaQen/XkcafedKEkOs81LM=; b=Fzs1hRqPy+B2Vn3SXx5rLQGgx3Ni5uj2jqzUFG+BCPIPW3vchAwQ+kqF8PbU2gydDP jtSG73KCtnLPNvgdujBhm6ESp4RSin2PgxApmirnzvj9GPGN1UIRrfi2b6FBhY9pNJyr qecFstk+XPe75eTU0m/xS+CYfqCYBf7y1ewjVExdRlPt6LygPQiih7to3mOpOnjVOCi5 7vMM8/OB8JP1jt9OdqHwEd//qyr3A0bbOb3JRRfhKADWVtSUrHcvMJGAnSKJtNvR/DB8 QyCU92N9anO41OpqM54wZV81yTdRa0gfZQNGpRGBmwPvucz2MIguLbLCtzNC6CW/VRfc 4kJw== 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=ETt4R0bGXs6DhHkvvbGjeUaQen/XkcafedKEkOs81LM=; b=OznnYn4bLaP4V5TzEXSc6aEXhsHGJDsBPZz00S/KX5xPf6J8TL4Z4dWMO9I2aY5DJ0 WB6RPSjqKtHvFx6zWsbyV4nJYrqVG56SE+ZO+S2DXEk6IfH9UPl8UmqlC0ZtJPpcoTXC YwFvAXb2SwDJY7/DkpNDMg/1zU2rJapT/p1oSt82syB7iII/4FxafDGC29E4ZDiqttR0 VEgFaJtz9EZCQVMWtb3W57EQzu1ZRGrs+8/bTdDBeigBzyPf3uZoF0Zn9LGWVlZ/3+rX SUqsXxftKIpxTaA1bmKQSzsomaZe3+enrC5n4f6JNpL6v/UuB9VlSwNWCtvJCywvD720 sVmQ== X-Gm-Message-State: AMCzsaVqQrxK+fddx/oOJFsOdpgW2RWYsGqjfrftdtpZq3NVdVWyXQod /4+ElNcLI1D+ryHv+JDFNpMNqhcFlCIt+Yh8NRzLhA== X-Google-Smtp-Source: ABhQp+TswvZWjQ26P8CKRAc+Ks/q1uTc3vpqnIvUQMgiodk3haO/zNc86jptTTIfNsZVD67I2csZxCOeKxRms2jmgF8= X-Received: by 10.107.27.7 with SMTP id b7mr18992640iob.136.1509031903259; Thu, 26 Oct 2017 08:31:43 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.57.22 with HTTP; Thu, 26 Oct 2017 08:31:42 -0700 (PDT) X-Originating-IP: [50.253.109.65] In-Reply-To: <5780cd7e-d048-51be-b995-53ce4e3f1e55@freebsd.org> References: <5780cd7e-d048-51be-b995-53ce4e3f1e55@freebsd.org> From: Warner Losh Date: Thu, 26 Oct 2017 09:31:42 -0600 X-Google-Sender-Auth: uFb7rQCnbTz-WOu61gIs2iVI_M0 Message-ID: Subject: Re: New behaviors for loader.efi To: Julian Elischer Cc: Eric McCorkle , "freebsd-hackers@freebsd.org" , Warner Losh , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 15:31:44 -0000 On Wed, Oct 25, 2017 at 10:52 PM, Julian Elischer wrote: > On 26/10/17 10:58 am, Warner Losh wrote: > >> On Wed, Oct 25, 2017 at 7:46 PM, Eric McCorkle >> wrote: >> >> Following the earlier discussion on the fate of loader.efi, and in light >>> of my GELI work, I've begun working on modifications to loader.efi to >>> allow it to be installed to the ESP, while maintaining >>> back-compatibility with the legacy system. >>> >>> Cool. I have some concerns, as this doesn't follow the doc I posted a >> while >> ago. I've not yet worked through the boot1.efi removal in that document, >> however. >> >> >> There's a couple of points that probably warrant discussion before I go >>> any farther. >>> >>> First, we'll need to figure out what to do with boot.conf, which >>> previously contained the arguments that would get passed to loader. >>> Personally, I think the logical place for this is /efi/boot/config or >>> /efi/boot.conf >>> >>> I would vote neither. If it belongs on the ESP at all, it belongs in >> \efi\freebsd\boot.conf. We now own \efi\freebsd, so that's where all our >> boot files need to wind up in our install. But I'm not sure that we need >> it >> at all, since boot.conf is only for boot1/boot2 in the current system >> (though it does set serial by default, which might be helpful to >> preserve). >> It would be even better, though, to use the command line that's passed in >> as part of the UEFI:BootXXXX environment variable. Since we have to move >> it >> anyway, we should do things in the EFI way, which is to store all the >> nonvolatile info in UEFI environment variables (and in this case, the >> command line / aux info in the BootXXXX variable). We really need to stop >> polluting \efi\boot with anything, except on removable media. >> > > boot.conf is also used to set kenv values so that they have knows values > when entering the kernel. > POLA suggests that it should continue to do that. On some platforms it is, but usually that's done via loader.conf or device.hints. The current boot1.efi doesn't do this, for example, nor do many of the other loaders. Second, does loader.conf exist on the boot filesystem, or should it also >>> exist on the ESP? I'm inclined to think this should be left on the boot >>> filesystem, as there may be more than one, and it's potentially specific >>> to the kernel installed there. >>> >>> I think it should be in /boot/loader.conf on /, not the ESP. We should >> only >> have \efi\freebsd\loader.efi in the ESP. >> > why not have both a place to set defaults for all Filesystems (in ESP) > and a filesystem specific one? (on the fs) I don't understand this comment at all. loader.conf is in the specific / we'll be loading from, period. That's how it has to be, otherwise if you have multiple systems on one disk that need different loader.conf, it fails. There's no benefit to also reading an extra one from here, but extra complexity. > Last, loader has typically relied on the fact that it's installed >>> directly on the boot filesystem, so it can obtain a good initial >>> currdev/loaddev. If it's installed on the ESP, it potentially has to go >>> hunting for the boot device. >>> >>> I'm not sure that it should look very hard, and it should only look as a >> last result. >> >> UEFI:BootCurrent lists the current boot variable. It points to the >> UEFI:BootXXXX that contains a LoadOption variable. This variable contains >> a >> series of DevicePaths. The first one is what the UEFI BIOS uses to load >> loader.efi (installed as ESP:\EFI\FREEBSD\LOADER.EFI). The second one in >> the list will point to the kernel to load. That way we shouldn't have to >> go >> looking at all. We assume that the root is the same partition we load the >> kernel comes from. We should only go looking if we fail to find the second >> path in the LoadOption. >> >> I'm stealing (back) code from my boot1 refactor for this, which first >> >>> looks at partitions on the same disk, then looks at all devices. The >>> actual test, I'm thinking, is to look for /boot/loader.conf, >>> /boot/kernel/kernel, and possibly other files. Of course, we also need >>> to retain the legacy behavior so that existing systems don't break. >>> >>> No, we don't. boot1.efi already does this, and legacy systems will >> already >> have this installed. So we don't have to recreate this behavior if we >> don't >> want to since updated systems will need to follow the efibootmgr protocol. >> There's no way the loader.efi will fit on the old ESPs we created >> anyway... >> loader.efi needs to cope with being loaded this way, but it doesn't have >> to >> recreate boot1.efi's behavior. >> > depending on what behaviour you are talking about.. > loader.conf setting kenv values is pretty embedded into out product for > example.. loader.conf and device.hints isn't an issue, and that behavior won't change. It's only the super-funky boot.conf that people today only put -h or -S115200 into on x86 (though some embedded systems have some hooks here for limited setting of loader env variables). All we need to do is to find / when we're booting of removable media. This >> means we can use a super-simplified method to find it. If you want >> something more complicated, you must use the EFI boot manager protocol. >> I'm >> in the final stages, btw, at work of reviewing code we've written to >> implement a mostly Linux CLI compatable efibootmgr. >> >> >> So I'm thinking the overall procedure looks like this: >>> >>> 1) Parse command-line args (this is to maintain back-compatibility) >>> >>> UEFI:BootXXXX also provides a way to pass this in. >> >> >> 2) Load /efi/boot.conf or /efi/boot/config if they exist, parse the args >>> inside as if they were extra args >>> >>> 4) If loaddev/currdev are set by command-line arguments, use them as-is >>> and stop >>> >>> I don't want to do this from the command line. We follow the EFI boot >> manager protocol. There's no need to invent our own here, especially since >> the loader's devices aren't familiar to people. It adds extra complication >> for no benefit. >> >> >> 5) Otherwise, try the legacy currdev/loaddev detection scheme (this will >>> fail if we're installed to the ESP) >>> >>> We don't need to do this... >> >> >> 6) If that fails, check the preferred devices >>> >>> At most we need to check the same device we were booted from if the EFI >> variables aren't set. >> >> >> 7) If that fails, check all devices >>> >>> I really really want to never do this again. It causes more problems than >> it solves and is part of the boot1.efi hack we should run away from. None >> of our other systems do it, and boot1.efi did it only as a kludge because >> it didn't implement the EFI Boot Manager protocol. >> >> I think we should do it as I described above: find things directly from >> the >> BootXXXX variable, per the EFI Boot Manager Protocol, and then fallback to >> the first UFS filesystem with /boot/kernel/kernel on the same device we >> were loaded from. >> > and ZFS? I haven't creates a UFS system for some time > Fallback does include ZFS too. But I really want to have the fallback be "almost nothing at all" and if that doesn't work for you, you have to set the right EFI env vars. The reason is that the DWIM behavior seems nice, until you want to do something complicated, then it just gets in the way. And most of the time, the 'almost nothing' case covers what you need. Our current 'search for it' approach is fundamentally broken and we must move away from it to a more explicit do this or fail approach. Otherwise, I can't have a system with 4 disks with 2 images each on them, listed in some custom order that I know about that the guessing scheme can't possibly know about. In my case, I'd have 8 BootXXXX variables listing, say, p2 on each disk in order, then p3 on each disk which might change to p3 on each disk then p2 on each disk, or it may even be p3 on this subset of disks only, then p2 if I discover down the road that I can't use one of the disks, but am unable to turn it off or reformat it (flash fails read-only). And yes, that's a real-world example from our next generation of servers. :) Warner 8) If that fails, continue without a currdev (which will drop us to the >>> loader prompt) >>> >>> That's fine. >> >> >> What do people think of this procedure? >>> >>> I have some issues with it. >> >> Warner >> _______________________________________________ >> freebsd-arch@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arch >> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >> >> > From owner-freebsd-hackers@freebsd.org Thu Oct 26 22:43:40 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D0CEEE548C5 for ; Thu, 26 Oct 2017 22:43:40 +0000 (UTC) (envelope-from zbeeble@gmail.com) 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 5617B6C663 for ; Thu, 26 Oct 2017 22:43:40 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: by mail-wm0-x22a.google.com with SMTP id m72so326938wmc.1 for ; Thu, 26 Oct 2017 15:43:40 -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=DbiW1SlmTdmF5l4Gt5cBD21o/j72CLVRZk9TqxTbBMk=; b=PnkII1qyrxBP3ArtVKyUobEFuXLRY/hDW3ff7X/fhymc29TxK1v9qZ0IEbQMRpRYBq GZDSnFDdXx5jRuNqrWCWO2cL7pu7o/YwdsGolWR4K7B5xLPSvgHEpRnhm4OlEYx/9X/r +3FCGRRiMWr2l6lgY0+esW8elouC8qWzEUmaClHWxlZtAVl3vuo0A2k/plPrKEZdQBTB 06NicinlMW1TPP47LegK0udMorqXrXqUe/+Uku91+arz/zt/PmW2xFtSPYYd3JZwew4y A3keEmX2TvxUNNNopTYUFrUBLvLz9s1ZSSCwF3/vJaz3f8R4ov+PfcE0nl894oyV4szK yp9Q== 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=DbiW1SlmTdmF5l4Gt5cBD21o/j72CLVRZk9TqxTbBMk=; b=Vg0MNbYna3q9vsHFQdkVT0j1F5HHsjgaHJlLaCZjjpEuEYPlPPpRZPDuyF4dqhZA5O CmTUpS5xYmPDwFcB6nCuPcVuKdPU+orsWqeEjSBta+RkKWs+M4Y46yMTp5nCEqdszhgs f/N8dWtiIF309kSPkOaaqnaLvukKl4lg3ZOo+J21P9xFsVhxV1KM12AkTbIYyiGou59o h9HYnLt8goJEU9knXgkrpF8SIhJqVgk3dpHrjKnMwVr0xPjVE07/4N4TXFfws30QTEMW TwC8V95hCoVX1CstJTxHUri36UXzwPWnxVaHPAG7gWKEYr2KqCUi2yVwDIYuGzjiMJcz qSlg== X-Gm-Message-State: AMCzsaU4/4sDiaKbkEA1cJZIV61CMJXfLmcHySlrEQa96/uw8oRUUiLd cwyasNYsGcHICwcAU3GQ0bKJhUgy+eC34SIW5w== X-Google-Smtp-Source: ABhQp+Rc+Z/V0Ij/IjFtW4Uis+dsj5+/oHG892rDaW5f5tNidDjxeNT382qe9jqqKYWxVuJ5RQPdYtV5J+H9qeUh3T0= X-Received: by 10.80.137.91 with SMTP id f27mr28835843edf.18.1509057818694; Thu, 26 Oct 2017 15:43:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.189.139 with HTTP; Thu, 26 Oct 2017 15:43:38 -0700 (PDT) In-Reply-To: References: From: Zaphod Beeblebrox Date: Thu, 26 Oct 2017 18:43:38 -0400 Message-ID: Subject: Re: We do serial differently. To: Kyle Evans Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 22:43:40 -0000 Since this didn't work, is the problem maybe (rather) that the application is opening and closing the port too fast (continually resetting the arduino) rather than this? On Wed, Oct 25, 2017 at 1:11 PM, Kyle Evans wrote: > On Wed, Oct 25, 2017 at 11:43 AM, Kyle Evans wrote: > >> On Wed, Oct 25, 2017 at 11:34 AM, Zaphod Beeblebrox >> wrote: >> >>> On Mon, Oct 23, 2017 at 9:45 AM, Kyle Evans wrote: >>> >>>> Hi, >>>> >>>> Are you able to connect to it otherwise (w/ cu or friends) and issue, >>>> say, an M105 manually? >>>> >>> >>> yes. With CU I can connect, it resets, then I can issue an "M105" >>> and it parrots back some status. >>> >> >> Ok, cool, that's expected and sounds like Pronterface is doing something >> it shouldn't be. >> >> I'll poke at it a little bit more- last I checked, it didn't look like it >> was doing anything too crazy with pyserial and I've got a working OctoPrint >> (w/ pyserial) setup, so I know that works to some extent. >> >> > For the sake of argument, can you try applying the following patch [1] to > printrun? I don't see a need to be toggling DTR here, and that might narrow > things down a little bit. > > [1] > diff --git a/printrun/printcore.py b/printrun/printcore.py > index b54e750..fd531c3 100644 > --- a/printrun/printcore.py > +++ b/printrun/printcore.py > @@ -218,11 +218,6 @@ class printcore(): > parity = PARITY_ODD) > self.printer.close() > self.printer.parity = PARITY_NONE > - try: #this appears not to work on many platforms, so > we're going to call it but not care if it fails > - self.printer.setDTR(dtr); > - except: > - #self.logError(_("Could not set DTR on this > platform")) #not sure whether to output an error message > - pass > self.printer.open() > except SerialException as e: > self.logError(_("Could not connect to %s at baudrate > %s:") % (self.port, self.baud) + > > > From owner-freebsd-hackers@freebsd.org Thu Oct 26 23:55:45 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CE9FCE55FAA for ; Thu, 26 Oct 2017 23:55:45 +0000 (UTC) (envelope-from nbari@codigo.io) 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 5354D6EB66 for ; Thu, 26 Oct 2017 23:55:45 +0000 (UTC) (envelope-from nbari@codigo.io) Received: by mail-wm0-x231.google.com with SMTP id m72so900225wmc.0 for ; Thu, 26 Oct 2017 16:55:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codigo.io; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=6/KfNm8sRNneG5Esf6BAjPs1Zax4p066p+1T/l8jsx8=; b=C+191HcHgh8h3nRBUBn2ZK2+EKyd9LBJzhfGhXhx5kFXkiB8n6AEW0hfVsGPc9MjNR AI4hByUU/FbQ59o035zkTnd31neIWoXG9TuWhzONex4qjkxUFlcnp82SziWNSdF8s62i cbx6Mm8e3yPGQCXbS9c8fSwFw7ewvDEQKeaa7v117Z5KEz4HbBtez5hIPNMo28zjSWc8 zvFmXDJ/LzSYj24gdxzcVBVqjq1oOpz+h8usKSX7UQb9CXSK2Elt8aTSMN8CY3514e7F 2VKMYoIGLLj/j7YLSpctsORx9S0wzQWEcQcC+vr7HCP+SAsZL2j7V34J5IlyQ4MMX3GL dKng== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tequila.io; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=6/KfNm8sRNneG5Esf6BAjPs1Zax4p066p+1T/l8jsx8=; b=bcN+jvg6XfBPkH5Yi5zoFjx5/ufRg6Bi6L/rGJsda81ONyuGmGAXnD8b7WQN9vtHh1 ztk0HPIv+irKOsP9MKRza1APFqpdZH6gjfiW38ZP0zEcsEDN0aOHNJ+6swmYLDgrqtO+ fefOx5RMHDfzIcdKHlAMzPkNIry5du2JiH25lGpUMpRgsxv5M34pwKZeva+Y9+IFCLAH scsVvgFPoxQL1RhrwLyVmYJVtn8K+tvQsSH+ypdTjBkaXsRjPGKfHnN+EapLXcRR7dZM HCCYcsHj78YkhBjq/xDchGfTyAN5PopR7mNzHo85vNakaJocezlhIaq4gLB80efQJRCG bTKg== 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=6/KfNm8sRNneG5Esf6BAjPs1Zax4p066p+1T/l8jsx8=; b=VDQX11Ojw9LIdIiMH5vh+AI12382YfxjaEIMo01MIeVa8NsLpR4jweUqYt+cjUir3M snk/jActd1RFTgj7SQP77eSPcx/yhkkAgapwjZW8KDR88vYUpmCQbJrBcYnno4XSNAIK NiE3Foc+7DUN1Ira4pNgOt+XHph7tYRrkPxShSRnOGEqY7mTNp28H8vKJ3RC+YivJdE7 OXkuyD9bXovYRUfLeNxuWqWiiUK210zVeGS2zoCTCCAtEyOPlExZ1MMieCWbOVKxD8Hv kVPJcdwCF8RYf8kdSoHD/2/9DqmBpgZJOZFxacYmIE7idnjHFmXhXXrslQJigaYBD4yF qdig== X-Gm-Message-State: AMCzsaV6vl+4jVZVOISnKw4ib2VV/q6cj1gRUHpEPMm82+/F37AyqqKi mPbqc8cgrRKig8iGhkfz/DBIMPF7+alUQqK1CQ0wMQbJOAg= X-Google-Smtp-Source: ABhQp+QjA8C3GkFOritea6N1yKDz8qxbrthRK160aAt/VF9H0U4rN3yzok6drV1mp1ePH3lcn61Rt7E67ILd4Qkmh8o= X-Received: by 10.28.160.23 with SMTP id j23mr432183wme.125.1509062142935; Thu, 26 Oct 2017 16:55:42 -0700 (PDT) MIME-Version: 1.0 Sender: nbari@codigo.io Received: by 10.223.176.228 with HTTP; Thu, 26 Oct 2017 16:55:42 -0700 (PDT) X-Originating-IP: [91.64.159.225] In-Reply-To: <20171025185736.Horde.fD8dlUh60kLaxAfok91iHKU@mail.eeeit.de> References: <20171025185736.Horde.fD8dlUh60kLaxAfok91iHKU@mail.eeeit.de> From: Nicolas Embriz Date: Fri, 27 Oct 2017 01:55:42 +0200 X-Google-Sender-Auth: 0WyrVMYiPSBfnNpJ5rQ9hj8vVPg Message-ID: Subject: Re: getting run_interrupt_driven_hooks: ... xpt_config in 11.1 (but working in 11.0) To: Michael Reifenberger Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 23:55:45 -0000 Hi, same happened to me: https://nbari.com/post/vps/ (search for netcup) I contact them and they change my VPS to another host with an updated qemu version and that fixed the problem. On Wed, Oct 25, 2017 at 6:57 PM, Michael Reifenberger wrote: > > Hi, > on a VPS (virtual private server) (https://www.netcup.de/) I could > install and use FreeBSD 11.0. > After upgrading to 11.1 or latest 11-STABLE kernel I get every minutes at > the end of the boot (before mountroot): > > run_interrupt_driven_hooks: still waiting after ... seconds for xpt_confi= g. > > > The host system seems to be using Linux kvm. > > Has anyone else seen this before? > > Unfortunately the debugging facilities on the VCS are quite limited... > > I have opened a PR 222548 for this. > > Thanks in advance! > > Greetings > --- > mike > > Gru=C3=9F > --- > Michael Reifenberger > > _______________________________________________ > 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 Fri Oct 27 00:10:02 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E0755E566D3 for ; Fri, 27 Oct 2017 00:10:02 +0000 (UTC) (envelope-from mike@reifenberger.com) Received: from mail.eeeit.de (mail.eeeit.de [37.120.160.187]) (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 6BF7F6F085 for ; Fri, 27 Oct 2017 00:10:02 +0000 (UTC) (envelope-from mike@reifenberger.com) Received: from android-b879ade6a6e3659a.wlan.rm-i.net (ppp-88-217-99-210.dynamic.mnet-online.de [88.217.99.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: mike@reifenberger.com) by mail.eeeit.de (Postfix) with ESMTPSA id 5EEBA7756; Fri, 27 Oct 2017 02:09:53 +0200 (CEST) Date: Fri, 27 Oct 2017 02:09:52 +0200 User-Agent: K-9 Mail for Android In-Reply-To: References: <20171025185736.Horde.fD8dlUh60kLaxAfok91iHKU@mail.eeeit.de> MIME-Version: 1.0 Subject: Re: getting run_interrupt_driven_hooks: ... xpt_config in 11.1 (but working in 11.0) To: Nicolas Embriz CC: FreeBSD Hackers From: mike Message-ID: <14F97184-7AFD-4AEB-9C57-036633C83BAE@reifenberger.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 00:10:03 -0000 On October 27, 2017 1:55:42 AM GMT+02:00, Nicolas Embriz wrote: >Hi, same happened to me: https://nbari=2Ecom/post/vps/ (search for >netcup) I >contact them and they change my VPS to another host with an updated >qemu >version and that fixed the problem=2E > >On Wed, Oct 25, 2017 at 6:57 PM, Michael Reifenberger >> wrote: > >> >> Hi, >> on a VPS (virtual private server) (https://www=2Enetcup=2Ede/) I could >> install and use FreeBSD 11=2E0=2E >> After upgrading to 11=2E1 or latest 11-STABLE kernel I get every >minutes at >> the end of the boot (before mountroot): >> >> run_interrupt_driven_hooks: still waiting after =2E=2E=2E seconds for >xpt_config=2E >> >> >> The host system seems to be using Linux kvm=2E >> >> Has anyone else seen this before? >> >> Unfortunately the debugging facilities on the VCS are quite >limited=2E=2E=2E >> >> I have opened a PR 222548 for this=2E >> >> Thanks in advance! >> >> Greetings >> --- >> mike >> >> Gru=C3=9F >> --- >> Michael Reifenberger >> >> _______________________________________________ >> freebsd-hackers@freebsd=2Eorg mailing list >> https://lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to >"freebsd-hackers-unsubscribe@freebsd=2Eorg" Hi, thanks for the hint! Yes its netcup=2E So I'll contact them for a move=2E=2E=2E Greetings =2E=2E=2E Mike From owner-freebsd-hackers@freebsd.org Fri Oct 27 00:29:10 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B4B41E56CEF; Fri, 27 Oct 2017 00:29:10 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 918E86F945; Fri, 27 Oct 2017 00:29:10 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 7E7A912D3; Fri, 27 Oct 2017 00:29:08 +0000 (UTC) To: "freebsd-arch@freebsd.org" , freebsd-security@freebsd.org, "freebsd-hackers@freebsd.org" From: Eric McCorkle Subject: Crypto overhaul Message-ID: Date: Thu, 26 Oct 2017 20:29:08 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 00:29:10 -0000 I was going to wait a bit to discuss this, but it's very pertinent to the trust infrastructure I described earlier this week. There was a good bit of discussion at vBSDCon about a possible crypto overhaul. This is my understanding of the current situation: * Userland crypto support is provided by OpenSSL, of course. My sense is that there's a general dissatisfaction with OpenSSL, but that there's a nontrivial effort required to liberate userland from it. * The kernel has sort of two crypto APIs: crypto and opencrypto. The design of these APIs seems to be something of older hardware crypto architectures and export restrictions. This is difficult to extract from the kernel (and say, embed into the boot loader). * BIOS geli pulled the AES implementation out of opencrypto. This was due in a large part to the size restrictions on BIOS loaders. * As a bridge measure, I've introduced boot_crypto into the EFI loader, in order to support GELI. At vBSDcon, there seemed to be a consensus that this situation is too fragmented. Moreover, it makes life difficult for anyone (like me) who wants to do crypto-related projects. A couple of options were discussed at vBSDcon. The two that seemed to come to the forefront were BearSSL and LibreSSL. There seem to be some advantages and disadvantages both ways: * LibreSSL is mature software with staff and support from another BSD (OpenBSD), they've done some really good work, and have a definite long-term roadmap. I'm not sure to what extent it could be easily embedded into a kernel and bootloader, though. * BearSSL's design seemingly lends itself to acting as a userland, kernel, and bootloader library. On the other hand, it's new (which means it will need to be reviewed by crypto experts and thoroughly tested), and has one developer at this point. I think it's worth discussing and investigating these options further at this point. From owner-freebsd-hackers@freebsd.org Fri Oct 27 01:22:29 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6E482E580F5; Fri, 27 Oct 2017 01:22:29 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 45B6671252; Fri, 27 Oct 2017 01:22:29 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id B0CE01308; Fri, 27 Oct 2017 01:22:28 +0000 (UTC) Subject: Re: New behaviors for loader.efi To: Warner Losh Cc: "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" , Warner Losh References: <87ceccf2-09fb-1adb-6304-649961cae2d4@metricspace.net> From: Eric McCorkle Message-ID: <74106a34-c82c-d9c5-d1bf-7128236d0378@metricspace.net> Date: Thu, 26 Oct 2017 21:22:28 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 01:22:29 -0000 On 10/26/2017 11:19, Warner Losh wrote: > So long as it's a backup method, that's fine. It occurs to me that it > might be useful for removable media where you can't count on EFI env > vars and you are bootstrapping such that you need the args (serial > console is the canonical case). Worth noting: some implementations (lenovo, for example) do sketchy things with their EFI vars, and others can lose their state from disconnecting the battery, etc. So I think a backup like this is necessary. > The fallback mechanism should try too hard though. Trying hard gets in > the way of many things. The biggest one being when I have multiple disks > in a system that have multiple copies of the OS. You want the fallback > mechanism to try as limited a number of things as possible then FAIL so > we can go to the next BootXXXX in the boot order. So long as the guesses > are super limited, and/or only done done when we don't specify something > explicit, then that's OK. > > So the change from the present would be: > > (1) If a second path is specified in the BootXXXX option, then boot it > (might want to look in the list to generalize this, but for the moment > that's an enhancement). If we fail to boot an explicit path, fail back > to the EFI boot manager. We were told to do something explicitly, and we > couldn't do that, so we shouldn't go guessing (this includes ZFS BE, > UFS, etc) > (2) If no path is specified and if we come from a UFS or ZFS partition > (the boot1.efi vector), then try to boot the kernel off of that > partition. If that fails, then fail the boot back to EFI boot manager. > (3) If no path is specified and there's ZFS BE we can boot from, boot > that (fail if we can't) > (4) if no path is specified and we can find a UFS partition on the > current disk, boot that (fail if we can't) This sounds good (assuming 4 also searches for ZFS) > I'll try to find some time today to update the boot document and to try > to draw in points you have in your chain of trust documents because > that's also important. It might also be worth bringing in the 'self > contained load env' work that I know is going on elsewhere (basically, > you load a loader with a MD burned into it and boot from that, with the > entire loader.efi signed such that the shim-loader that floating around > can load and verify it -- a lite version of the stuff you are working on). I'm going to update the trust infrastructure paper with some of the ideas from the discussion, but the salient points should remain the same. From owner-freebsd-hackers@freebsd.org Fri Oct 27 01:34:07 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 24344E5846F; Fri, 27 Oct 2017 01:34:07 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0119.outbound.protection.outlook.com [104.47.37.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BA29371779; Fri, 27 Oct 2017 01:34:06 +0000 (UTC) (envelope-from sjg@juniper.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=a3iXHARXdmkUNqnkCZOFCSt/nCVDC/ON2liKbDUhM3c=; b=X0lNtI/r3h9XlbrMX24PfXZq5HXzEYZ8+FxxCuaxRAJhWQN1ZifHIe1Yv54cRMie+GGoAFycK0OUcVrkK4db82bcGjlEjxaSvetcSj+428UqD2qz0XOLSWh3rGfo5zzhPdg5SJxbqWRpHLkT4xiUL57SWnr810KaG/qOAuj51ao= Received: from SN1PR05CA0033.namprd05.prod.outlook.com (10.163.68.171) by MWHPR05MB3613.namprd05.prod.outlook.com (10.174.251.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.4; Fri, 27 Oct 2017 01:34:04 +0000 Received: from DM3NAM05FT023.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e51::203) by SN1PR05CA0033.outlook.office365.com (2a01:111:e400:5197::43) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.197.4 via Frontend Transport; Fri, 27 Oct 2017 01:34:04 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by DM3NAM05FT023.mail.protection.outlook.com (10.152.98.133) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256) id 15.20.178.5 via Frontend Transport; Fri, 27 Oct 2017 01:34:04 +0000 Received: from p-mailhub01.juniper.net (10.47.226.20) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 26 Oct 2017 18:33:36 -0700 Received: from kaos.jnpr.net (kaos.jnpr.net [172.21.30.60]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v9R1XZF8009830; Thu, 26 Oct 2017 18:33:35 -0700 (envelope-from sjg@juniper.net) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id 38E34385568; Thu, 26 Oct 2017 18:33:36 -0700 (PDT) To: Eric McCorkle CC: "freebsd-arch@freebsd.org" , , "freebsd-hackers@freebsd.org" , Subject: Re: Crypto overhaul In-Reply-To: References: Comments: In-reply-to: Eric McCorkle message dated "Thu, 26 Oct 2017 20:29:08 -0400." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 25.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11244.1509068016.1@kaos.jnpr.net> Date: Thu, 26 Oct 2017 18:33:36 -0700 Message-ID: <11245.1509068016@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(346002)(39860400002)(376002)(2980300002)(24454002)(189002)(199003)(5660300001)(97736004)(7116003)(47776003)(221733001)(478600001)(6916009)(69596002)(2950100002)(68736007)(23726003)(356003)(46406003)(117636001)(7126002)(54906003)(2906002)(50466002)(16586007)(2810700001)(316002)(7696004)(189998001)(8936002)(86362001)(81166006)(97756001)(50226002)(81156014)(8676002)(97876018)(305945005)(107886003)(3480700004)(50986999)(77096006)(106466001)(6246003)(105596002)(229853002)(53936002)(55016002)(53416004)(76176999)(6266002)(4326008)(76506005)(9686003)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR05MB3613; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM05FT023; 1:tutf51ZBf3DBn0F0xdAT0T/O9bcsviwMU/IwWo/y6qhBYR4P37n4rgyf3/2x6ibpXKk8CSgChHmurVaKY0FSkvj4+KbYWH7Uj3QwU+6jsTBpxQs1OBZY184Mg+oXchZL X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: b4ae7ebb-f6c3-4d14-ba9d-08d51cdacf2d X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:MWHPR05MB3613; X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB3613; 3:SzEQvmnn/fXrpC31dGsjM4bqJkTqH4Jx0RkJmW8IQGfaUNeh8gO2BfcYGOF4osg7x5EBULnG9aj3vyMQIhrfcrMBe9IpmouHL4dE25miyBjAW2Kp86Yn9k9X7edqnXxSmjzkjcPr+xcE/uki5MmNspiiQx9EQi34yvWNMp9mdqy/CShhrbyq/tk1DCsxAJpw6g0jYbaJSkUj8syToe7KhfMMn1cUQgIpXDnQP5Bdss6TovnE+F6qkiR1snb23PxSyzS1CY7txSWlfmKd0V5o9GkqffSU7gjUHbgpZyoocbsMCWLdv9FtGOHItSdKkqyCb/XPHYyq201NMVrAiTve5PQH8uEeMMmifwme2rKS4G8=; 25:lQhz+c/mv32WIvtxxESEVTVTHRmUku9r9D7R/3OWQ+wMM3P+q9nYj0nCBJwsyTl7VAVfFdcQdGd/5GLGhy4zuYCsRuPym+yKXr6VZh275tnQIORecVd3+Tg7ddb3ANzm3xXs79GT9LQ2KgiN3NDddhZWt8gLoXYI+zOIIN27f71WStb1Xm1VQAEr4FCLUqgOY3x52ZCnGnF2AFAV5iSqLTE30qpU6BEOJxjYja3V8zCuSmd97vFR+s9INFQ3e8hryjoHuQgO0mHYiq9NzjX73uYHRenBj7fW7042R+ekWkDMGvWk6XQj65nEfYg9ZzDBWFrd85ArykxkSMdoFAqgVQ== X-MS-TrafficTypeDiagnostic: MWHPR05MB3613: X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB3613; 31:Kn/f9N8byNpr+g9u5pLxswEVJgp4SDSx+GDLICiDnwCQflvco3QZUz41RWObnl6MONd/efr9FbdHciCmX7H8/uLlUN2d5Vx7UMqPP3FlvPUwrDP8yLb60bKf2XqW4I0z5Sv3KPtYl9puKuXQdyRWAlMEHNzrdRdq4F5HpY1WqYE6iKrQa9weQpC0QcdMOWH0p+zGJQGJx/VI/8AXCG5r/mmoR5ZWisc6QuKVbdat3AI=; 20:PUw8E+kC0Iga2m3h4+vTtbyqzTphqpXxP+kxwB13EyKhkzskp8yn7AK05PrVpS5tnwFotMyRo7AVqNoWs6xaSvEH6Ut1wmkJXRzYfqTBl7Y4Ga5AugJoyPdd1DBbK6mVZ2BC3oB8AmPARIjpZny4rCZutK/KTHJUfaGIYwuTNJlnot1h7jOeXvlv1F3yR2ZP1zQivQgLQCKl56VsrbEo8Aq1RJqby2Z/OJj6sHtf5KcjpP9xES3yIaAKBXByBtJ+/uuqxJjSjuT+v5ckr6Bzk8w1eY80Wm07GtF9FDWMlUiHHokr+bvQ7/MM7yibQIIaobhT+cwDkMAOxTm2ZL6XoorClCx2yt4R0+l+rbQojqTh1/idOukNB0dy6EduVvGTkERlB7o2bL82z3NSf4YfgkSR1nB5Dgsv0chVV1EZUn3XO3AAFCcoA5extp+c35JayMJfP8kFrT1lKpT4aLRzQKRNadtcj4SJ5lqGibpUnjpZz5SuYP2Hqv7zwJb01kRs X-Exchange-Antispam-Report-Test: UriScan:(244540007438412); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(3231020)(100000703101)(100105400095)(93006095)(93003095)(10201501046)(6055026)(6041248)(20161123560025)(20161123564025)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR05MB3613; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR05MB3613; X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB3613; 4:z5SzSYLZNbGliA4tOWtpS6H2o/BhYnOzmwAkqMA30ksXrpYkalZ3XQtnZtESvUwiIViPDszqNGEF52rVBtCmySlLnOuMaSYtAnTgYfrOgS4MBnuw/3+zxb9FNofN9/nBZlYlSelkCEOcfJUsBfXmrItvS73DmysE9cwtkNdpj42H31W/ghph0FaOeP65v/2SFxw4GM9NlRNPo16ijLhhIpBcY2UkirBxCeLFmwRN4zBt23bn13tgHT8VRLtt8xF+vNPWTqVQsKNx3ogvzW4AMQzbj+DlrXDOmck694FDa5WNjxJK8kn8Bv6v50OWT6JS X-Forefront-PRVS: 0473A03F3F X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; MWHPR05MB3613; 23:Ko5e/wNIhH8wAt3VzWt+BZHv94qjBfpaUMs45UkA2?= =?us-ascii?Q?zKKgOWUwk0cEq+B07YDsH4vRFbHxFxSe21wr8Pd4OUGw7qwyYQKOykkIC8Ny?= =?us-ascii?Q?MWZjPPAZKR2SoK2vSFHlVYtH9+VTS0+XAxWqDNWVOTpTW8NN8Nifc9Gc4rNR?= =?us-ascii?Q?fraLNGikDRyXJL3xuHnEWL32sEwFbVE2tmPuhH4GFZUZOVXAKxGMfMPkT/LS?= =?us-ascii?Q?x5loI6zuvUQtNPIvpZAp23zGqF0bSV0e7Nns2XNFdXNVpowBJ1Be2W+qNtC9?= =?us-ascii?Q?xKRz3GWQx0E5J4+I5kcY3GzVilKP884aRbjjxQRdoJba9aARgZLf7piRJZCA?= =?us-ascii?Q?fcRioLDwEa512+bomKDHV78kpje00r3XGeMg8OR/7OOtKVjnGzmmzpICUZnQ?= =?us-ascii?Q?SrYQzio0wfeTRdbEbwR7BDZYKmmjft4w0RTV3WRWlLGCU+/mMBTYmHiGhzWg?= =?us-ascii?Q?PmH43+zUKmMbhSdLLUcEIhE6dUC+/ttN78zvz2YkapU1umJG7lfqfuwwCNSN?= =?us-ascii?Q?zxdb1K0nX/zGTOWJ7r7XnpFxB1kSuFpZUnTLhilRSjlmKXZGAMFmP1+0JaXC?= =?us-ascii?Q?7SzGNxrWe9RQZnnmQFNu/lcwv9F4eDy5WriB/QNC8+3f47mrVDsO8cXBWrJA?= =?us-ascii?Q?NgRm1AHhksLYa8J7nGUiLg9zVOi62hFwG9x6FSeeW2Wyafktde5Rr677BmwK?= =?us-ascii?Q?ZsnxHmonrfcNcKSuzhJuOPeXR5uR6rqK0ziUh58V7ch6MYvslD6gJ2rYuyar?= =?us-ascii?Q?HD5iiNCp1SPb2OLT7QfcIUhB67CreRvcdMfzNsvHsfwtrZTaLsHozYrN8uBZ?= =?us-ascii?Q?chIS3J7t0UgjpChX9VkkizrbogFonPCDg+VucDz6+Sk+mHGsSWdFRNhA9j4Y?= =?us-ascii?Q?uYLaIJTIqfwAhU02XkM2fK+P02dcnchKe82yNG2mhNiXBOI2h4UTzwWt9Wrf?= =?us-ascii?Q?QXBZuy4BzVEdCo1OB6qF99MMjTvM3EFbWWtjmzzVcxSnuOKbhr2pF13OX5zk?= =?us-ascii?Q?cCszbZA+06VYnpXrKA8wHyAYSaqCHM6htW0P+HlvYlJ77y8j77M9etlI+Y8T?= =?us-ascii?Q?61sRDOv8HRyg89WKqW9ORp8SgO5YKxnB2Jk2gpH6KtkZkXaU0nSHbh2/3oO9?= =?us-ascii?Q?OP1/x3ze+NY2HUbgFf5DQ5NZsyWjqnvsrANDPRsuq/cM+e8LiZzHdVwXORzO?= =?us-ascii?Q?Dnji5/xeUeYJ5b00CDDMvZwX9xfDCkxHFt1F7B7UhUw97jQKDZ1b0gsagK6f?= =?us-ascii?Q?P7XX+5znwZ2aj8lQQtNe49NHaGb9e8xfjNGcrw7CG8msttbMqs1TatKT1mWD?= =?us-ascii?Q?7cFcSwQK90DVX33APvEgMk=3D?= X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB3613; 6:PpuNmw3FLXvvQTF6B+OBJNII8byauNTCcil+B1EJpKVweZkrSTBdmn1F7dUvAbZKxtkUsjBxmajbBVYMebr2aB0XPHL0cKKCF+qEYE74FatvCYzhWYcuoMeS3vmOPk3KdEjj5eVQXQRQwvLYbMBI3HGDlrajayQ+/97g9SmFjwdeAvLlSe8xquIBYB7MT+KU/PHtulotx8Nf3KG/qmN9fuu/roDRa3jTLfaQ/oDhmHtfP7R1lO+e/z+zSZXzUjYVsPOBDsc8vb/vZ5SZWVEcZ7W+EJNAIZzDy4moyNkPXaFyThngKnqQelvE77LGzRf86USncECv1htPEnl8zIM/nRhH3BANSDKGD800e1o5vA0=; 5:RVssx7qCRizlvs9mTrsy66CVfbWz9Lv3SAlD1Cs41Mq/+7810TmlKAYuAyx21/6roOiu8B2wkr4lOG+Ma98gl18Cq/+oRAmLxNshpT4sXE/wPbdHOCFLHP0O2IncwM8uKAQ2Uiy1NVUVrBIwckNhoQwCZfOJf/HclE0AsqvJ8Ow=; 24:XNXfxkBua9xiLjH5t1qigWXLKyeY92sK+RUCgN4tprD3wHKNykFOaORsyXsJ6osWAHTeqY+RiCCY+1hl/6GmtBJySx6rNferidg9iv0rrpE=; 7:VwCmypqcCq6N/UeW+gGvaVq4LzIGFJh8IHto0+/K7Zrl7yUXERY1u1yIKfn8xQzm/SGgIje829+g6eMXJiAxxt9QewSXupq+k60cGUTzp9DSoMEMDPHuMehcvqsvNa3AL/tp5HOcjNMOqEbpevP7qGJcUlF0VSyatQvKR4TBCh+SMoMn7EtuKEsYYWGEQ9CCxhKMNOVkNds99p/Z+mljby+xtX/WsUNiGexTmCMabMthD2FPiLXiPNIb6000Wbim SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2017 01:34:04.3996 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b4ae7ebb-f6c3-4d14-ba9d-08d51cdacf2d X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR05MB3613 X-Mailman-Approved-At: Fri, 27 Oct 2017 01:44:32 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 01:34:07 -0000 Eric McCorkle wrote: > * BearSSL's design seemingly lends itself to acting as a userland, > kernel, and bootloader library. On the other hand, it's new (which > means it will need to be reviewed by crypto experts and thoroughly > tested), and has one developer at this point. BearSSL is indeed very new, and review by crypto experts would be most welcome. It works very nicely though for verifying signatures, X.509 cert chains etc - everything I needed for the loader to do verification of modules. And it is *tiny* I think all the verification stuff added about 80-90K to the size of the loader. The author, has been extremely responsive and helpful, nice to work with. The API is very different to OpenSSL so I would not contemplate trying to use it as a replacement for userland crypto lib anytime soon. But for the loader (and kernel if needed) it could be a very good option. FWIW I did not need to touch kernel, since I have the loader verify the kernel and the mdimg it uses for /, thus init etc are also verified before we pass control to kernel. From owner-freebsd-hackers@freebsd.org Fri Oct 27 04:46:19 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0D5A5E5BBB6 for ; Fri, 27 Oct 2017 04:46:19 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c: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 92B1676AAE for ; Fri, 27 Oct 2017 04:46:18 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: by mail-wm0-x22d.google.com with SMTP id b9so1221477wmh.0 for ; Thu, 26 Oct 2017 21:46:18 -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=mTMkGSQuNib7eid+uuGzyJEM3CxFeIhx4jfZt8rpxhs=; b=uceELuFojC8IP2oITN9kmj3bnnrSLvC+w0PhhIzoO6rb32h14MJnoBDldZDyJDanLV hzOFEgbgjDZRaWoGh29LkjSqKAGu74AYaU8cx255KUu8Vo3zIJTmL2C2liHzef5ICoxl WSfHI3QR76oJ/EdnDDlDK9Fk+n84Sc6UAXp7Ol/KfOkkI4nchxCNrFODMiyIKlSE5fIx 7MOKQK82HAdwbRDGUvrhZ3U1bhXxf64IsAsZU/MthILkfos70hMH1BdjDWmCKwVxcjkv YSK1uN65+u4W0tCxB3zdWZK+7eeZ4QeEmYCU7v4rTM7/SoH/iTvu/DC8Sgry1PB2gdhZ cfTQ== 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=mTMkGSQuNib7eid+uuGzyJEM3CxFeIhx4jfZt8rpxhs=; b=pTwTFSEIaet1GUWRZzjYqb1BBCxwKF35W6zD2HbFoS/BSKusL5P+jnrvW2kElMqXlB Je65aaRd6wbIbkl6DFTL2q8BpFVgPvftDkGkkBaUPC7aHyXyucmQO0oNN1NfoTXvlEu9 SAN84wMVhMukwVeuFKkgVre+Lx+5gWTych1gLI1uvrhN5BO8WkApCCMU/FlXVXUC+C7u OD+I7tWLLbSWrA19OJHWw5z0YycTVqiKK2Pg7w89cWcB6PEDivcHi8XMcRgqLKWVkUve 8aUiHzSsbNXJ+7kQTVqueeTMhdivX7RYBQShEqptZUI0GTvJ0DkzxVP9tuCAeNQQNzKo tkrA== X-Gm-Message-State: AMCzsaVrqxv0BcQdySmMHZFFEqE5CNuSSBDO75ENq4MQcZU29e7Lmk4v evdgJjCfDzl0aknNpra2a3rIv/Lbtrc8oS6Oqg== X-Google-Smtp-Source: ABhQp+TINKGCqoWXgyxgsBQYBGNlqdK7YVOmuZyUphk8LYD8ChsA4NlDsGRoRrf5v6oI7b89kid6/1AP98Jo70Y1xTc= X-Received: by 10.80.181.90 with SMTP id z26mr31518944edd.76.1509079576978; Thu, 26 Oct 2017 21:46:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.189.139 with HTTP; Thu, 26 Oct 2017 21:46:16 -0700 (PDT) In-Reply-To: References: From: Zaphod Beeblebrox Date: Fri, 27 Oct 2017 00:46:16 -0400 Message-ID: Subject: Re: We do serial differently. To: Kyle Evans Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 04:46:19 -0000 OK. I played with this all again ... a bit. Firstly, when I run "arduino" (the IDE) ... the arduino board resets immediately (I can tell this because it has an LCD screen attached). But when I run pronterface, it doesn't reset until 5 seconds (roughly) after pronterface exits. I tried adding a hardcoded setDTR(0) or setDTR(1) near this code ... but it doesn't seem to make any palpable difference. On Wed, Oct 25, 2017 at 1:11 PM, Kyle Evans wrote: > On Wed, Oct 25, 2017 at 11:43 AM, Kyle Evans wrote: > >> On Wed, Oct 25, 2017 at 11:34 AM, Zaphod Beeblebrox >> wrote: >> >>> On Mon, Oct 23, 2017 at 9:45 AM, Kyle Evans wrote: >>> >>>> Hi, >>>> >>>> Are you able to connect to it otherwise (w/ cu or friends) and issue, >>>> say, an M105 manually? >>>> >>> >>> yes. With CU I can connect, it resets, then I can issue an "M105" >>> and it parrots back some status. >>> >> >> Ok, cool, that's expected and sounds like Pronterface is doing something >> it shouldn't be. >> >> I'll poke at it a little bit more- last I checked, it didn't look like it >> was doing anything too crazy with pyserial and I've got a working OctoPrint >> (w/ pyserial) setup, so I know that works to some extent. >> >> > For the sake of argument, can you try applying the following patch [1] to > printrun? I don't see a need to be toggling DTR here, and that might narrow > things down a little bit. > > [1] > diff --git a/printrun/printcore.py b/printrun/printcore.py > index b54e750..fd531c3 100644 > --- a/printrun/printcore.py > +++ b/printrun/printcore.py > @@ -218,11 +218,6 @@ class printcore(): > parity = PARITY_ODD) > self.printer.close() > self.printer.parity = PARITY_NONE > - try: #this appears not to work on many platforms, so > we're going to call it but not care if it fails > - self.printer.setDTR(dtr); > - except: > - #self.logError(_("Could not set DTR on this > platform")) #not sure whether to output an error message > - pass > self.printer.open() > except SerialException as e: > self.logError(_("Could not connect to %s at baudrate > %s:") % (self.port, self.baud) + > > > From owner-freebsd-hackers@freebsd.org Fri Oct 27 07:05:35 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 42A62E5DDEF for ; Fri, 27 Oct 2017 07:05:35 +0000 (UTC) (envelope-from arybchik@freebsd.org) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [84.52.114.115]) (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 E4A587E8CC; Fri, 27 Oct 2017 07:05:34 +0000 (UTC) (envelope-from arybchik@freebsd.org) Received: from [192.168.38.17] (aros.oktetlabs.ru [192.168.38.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id 8AB6A7F7D4; Fri, 27 Oct 2017 09:55:37 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.9.2 shelob.oktetlabs.ru 8AB6A7F7D4 Authentication-Results: shelob.oktetlabs.ru/8AB6A7F7D4; dkim=none reason="no signature"; dkim-adsp=none (unprotected policy); dkim-atps=neutral Subject: Re: Anyone using Solarflare on FreeBSD 10-STABLE ? To: Mark Saad , Andrew Rybchenko Cc: Philip Paeps , Allan Jude , "freebsd-hackers@freebsd.org" References: <333473BB-43C3-4E3E-B62F-03DE5650E403@freebsd.org> <7951e7d5-b5e6-033d-0b51-1d4a10946937@oktetlabs.ru> From: Andrew Rybchenko Message-ID: <0d126774-3736-4a4c-c01f-07bc9caf82a6@freebsd.org> Date: Fri, 27 Oct 2017 09:55:37 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-GB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 07:05:35 -0000 On 10/25/2017 12:04 AM, Mark Saad wrote: > On Tue, Oct 17, 2017 at 3:44 PM, Andrew Rybchenko wrote: >> On 10/17/2017 08:54 PM, Philip Paeps wrote: >>> On 2017-10-17 19:36:20 (+0200), Allan Jude wrote: >>>> On 10/17/2017 12:32, Mark Saad wrote: >>>>> Speificly I wanted to know if anyone knew what this sysctl refers to >>>>> >>>>> dev.sfxge.NN.stats.rxdp_di_dropped_pkts >>>> >>>> I have two 11.1 boxes with a dual ported sfxge each, but I have no idea >>>> what that counter is trying to describe. >>>> >>>> The man page says this is Philip's fault. >>> >>> This code is not my fault! ;-) I believe arybchik added it. >>> >>> Looking at the code, it's packets that have been dropped in the data path >>> by the dispatcher cpu. Probably related to virtual functions? >> >> Philip, thanks. I don't think in this particular case it is related to >> virtual functions. >> >> Basically the counter means that ingress packet does not match any installed >> filter. E.g. promiscuous mode is disabled and: >> - destination MAC is unicast and not the interface MAC address, OR >> - destination MAC is multicast and there is no matching multicast address >> added. >> >> There is a race condition as well on interface bring up when packet is >> received but default filters are not installed yet. >> >> SFN8522 and SFN8542 have other cases for encapsulated traffic depending on >> driver version (right now I don't remember the state in 10-STABLE). >> >> Mark, let me know if I can help more. >> >> Andrew. > Could you clarify what was meant by Virtual Functions ? Vlans , laggs > etc or srv-io ? > Also I do have IGMP snoop enabled and routing is done locally on each > router -, the freebsd box with the sfxge cards. I meant SR-IOV. Which SF NIC do you use? Andrew. From owner-freebsd-hackers@freebsd.org Fri Oct 27 08:47:06 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3FCE1E3C15A for ; Fri, 27 Oct 2017 08:47:06 +0000 (UTC) (envelope-from nkoch@demig.de) Received: from exch.demig.de (exch.demig.de [87.128.30.225]) (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 EBC9980FC3 for ; Fri, 27 Oct 2017 08:47:05 +0000 (UTC) (envelope-from nkoch@demig.de) Received: from [192.168.148.248] (port=47797 helo=SRV-FS-2.Demig.intra) by exch.demig.de with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1e80Fz-0004kJ-1N for freebsd-hackers@freebsd.org; Fri, 27 Oct 2017 10:44:47 +0200 Received: from [192.168.148.215] (192.168.148.215) by SRV-FS-2 (192.168.148.248) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 27 Oct 2017 10:44:42 +0200 X-CTCH-RefID: str=0001.0A0B0201.59F2F1FF.00A6, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 From: Norbert Koch Subject: crerating coredump of multithreaded process To: Message-ID: Date: Fri, 27 Oct 2017 10:44:41 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-C2ProcessedOrg: e1e98c77-ec17-4cb1-9b24-fe57656077ed X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 08:47:06 -0000 Hello. When trying to create the coredump of a running process (without killing it) under FreeBSD 10.3 I am seeing a somewhat strange behaviour. As I want to see the state of all threads, the q&d way of fork() + SIGABRT does not work for me. So, what I do is having a supervisor program waiting for SIGUSR1. When my application signals the wish to be coredumped it sends SIGSTOP to itself immediately after sending SIGUSR1. The supervisor then forks gcore. From what I can see using top, my application immediately starts again as if SIGCONT has been received while gcore hangs in wait. Gcore calls ptrace(PT_ATTACH) followed by waitpid(). So I assume that the ptrace call restarts my application and waitpid hangs (why?). If I manually send SIGCONT to my stopped application immediately before exec-ing gcore, the coredump is being created, but for obvious reasons not as consistent as I want it to be. I should add that in my application most other signals are blocked. Blocking (or not) SIGCONT seems to have no effect. Am I doing something wrong here? If yes, ist there a different/better/more elegant way of creating a consistent coredump? Thank you. --=20 Dipl.-Ing. Norbert Koch Entwicklung Prozessregler ***************************************** * demig Prozessautomatisierung GmbH * * * * Anschrift: Haardtstrasse 40 * * D-57076 Siegen * * Registergericht: Siegen HRB 2819 * * Geschaeftsfuehrer: Joachim Herbst, * * Winfried Held * * Telefon: +49 271 772020 * * Telefax: +49 271 74704 * * E-Mail: info@demig.de * * http://www.demig.de * ***************************************** From owner-freebsd-hackers@freebsd.org Fri Oct 27 09:33:21 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 62BDDE3E469 for ; Fri, 27 Oct 2017 09:33:21 +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 F412B8266E for ; Fri, 27 Oct 2017 09:33:20 +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 v9R9XBZp036426 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 27 Oct 2017 12:33:11 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v9R9XBZp036426 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v9R9XBMD036425; Fri, 27 Oct 2017 12:33:11 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 27 Oct 2017 12:33:11 +0300 From: Konstantin Belousov To: Norbert Koch Cc: freebsd-hackers@freebsd.org Subject: Re: crerating coredump of multithreaded process Message-ID: <20171027093311.GF2566@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) 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.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 09:33:21 -0000 On Fri, Oct 27, 2017 at 10:44:41AM +0200, Norbert Koch wrote: > Hello. > > When trying to create the coredump of a running > process (without killing it) under FreeBSD 10.3 > I am seeing a somewhat strange behaviour. Try this on HEAD or stable/11. There were a lot of changes and bugfixes in ptrace(2). I do not claim that the behaviour you see has changed, but 10.3 is too diverged from the code where developers would be willing to look at. > > As I want to see the state of all threads, the q&d way > of fork() + SIGABRT does not work for me. > > So, what I do is having a supervisor program waiting for SIGUSR1. > When my application signals the wish to be coredumped > it sends SIGSTOP to itself immediately after sending SIGUSR1. > The supervisor then forks gcore. > > From what I can see using top, my application immediately starts > again as if SIGCONT has been received while gcore hangs in wait. SIGCONT cannot be blocked, otherwise programs could create unkillable processes. > > Gcore calls ptrace(PT_ATTACH) followed by waitpid(). > So I assume that the ptrace call restarts my application > and waitpid hangs (why?). > > If I manually send SIGCONT to my stopped application > immediately before exec-ing gcore, the coredump is being > created, but for obvious reasons not as consistent as > I want it to be. > > I should add that in my application most other signals are > blocked. Blocking (or not) SIGCONT seems to have no effect. > > Am I doing something wrong here? If yes, ist there > a different/better/more elegant way of creating a consistent coredump? What is the purpose of sending SIGSTOP to itself ? Practically, it is no different than the action of ptrace(PT_ATTACH): all threads are parked at some safe place in the kernel, or are forcibly moved into the kernel mode by sending IPI if executing in userspace on other cores. To get into the safe place in kernel, threads often need to execute some more. IPI delivery is also not guaranteed to occur in the deterministic place ("at next instruction boundary"), it happens as hardware reacts to it. As you see, the process is very asynchronous, it cannot guarantee that the final snapshot is consistent with arbitrary thread state at the point of request, but it does represent the valid process state assuming that the thread are executing async. More, ptrace(PT_ATTACH) currently operates not only by a mechanism to similar to SIGSTOP, it really sends SIGSTOP to the debuggee. We do not track nested SIGSTOPs, process is either stopped or runnable. So I am not surprised that attaching to stopped process do not occur until the stopped state established earlier passes away: the debugger waits for the confirmation from all threads that they are parked at safe place, but there is no because the threads are already stopped. If threads are made runnable the acks are sent and the attach completes. I am explaining this to point out that trying to send SIGSTOP and then attaching with ptrace(PT_ATTACH) is just worse than doing ptrace(PT_ATTACH). I think you need to have supervisor either directly execute gcore(1) without SIGSTOP, or execute ptrace(PT_ATTACH) instead of kill(SIGSTOP), and have gcore functionality embedded into the it. The consistency of the generated core is actually same. From owner-freebsd-hackers@freebsd.org Fri Oct 27 10:00:05 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E6067E3ECF3; Fri, 27 Oct 2017 10:00:05 +0000 (UTC) (envelope-from benlaurie@gmail.com) Received: from mail-qk0-x242.google.com (mail-qk0-x242.google.com [IPv6:2607:f8b0:400d:c09::242]) (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 9F9CC8301F; Fri, 27 Oct 2017 10:00:05 +0000 (UTC) (envelope-from benlaurie@gmail.com) Received: by mail-qk0-x242.google.com with SMTP id x82so7643395qkb.12; Fri, 27 Oct 2017 03:00:05 -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=ABB/QRnvrZxvpvJSimeFkXxTRdOwGsYQrgRenYUIXsU=; b=cnn3YlwyP1lqjoSGY8S0FvBqbWOg/d3l+RR4SvMT9VNX/yX6LLVGPSHLa49nutB1Ww Vfyz99hXvIh8qbwh7Pa+6tB1/F4wDAqhN8fefS9xQeyIOKO8W24Ea1ULjMpExlfU8bgg jxLUeE0P8XIXk1niwtN3FhguL8LkNkUSt4F8CkF8CsajN+YTKxLZrFB1cUemSbt8P3H3 DkOju03Yo5EqnEr9qT/Z4YnsTb5VZATRosZdU4cV2nXZ3IQq/C7MNay0WEaYC+9qNu9U Bza8we7Hg66eJTN59ZJ2nsWIiPTD5QTsAeZ/A7/0lptMyGgX10B6zssl/E5hYMA7l06m Yrow== 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=ABB/QRnvrZxvpvJSimeFkXxTRdOwGsYQrgRenYUIXsU=; b=h5EasdhZsncC0txuUuJbZaxqbldVKeTDyOI0GozeWYQwXKm3rUcRakVMwvW9LUfzgU IodZXyRkjizCKVd8m6XJ/MeXRAhKN0NWwSBvj1LTajnjXhLUMKfPJGydsLQ0QFEsuNfM x8gGruq26LlhXhrME0VtTPYlCJNkfbX3+CIgPLCA9ocvfp7+AhZiAlxVsFB2nc4JFK4p C9y/Hl0DyMEssg7efx7vJiGnLZTmQMELobsRW6tPooOhm6WD9+ryNa7Bm0oUXpAkjxwz OjC3iRjtpLJ15QxRpDEntm9CEtdpil2X5vpD3DPgWp0dqbwSnU15yJfObXVGzeJHswj4 P5Pw== X-Gm-Message-State: AMCzsaWb+7Ejor36Hr/Z5fT/R28jwakrUlKIHoKyd2V6S6s0CMMq/hQU imrLDG42JrFcL2YytM0hkx3PM3JS6Q5zHKm4dww= X-Google-Smtp-Source: ABhQp+TFY4158zoi+PFWoy+2+Vye0wZzzgWtZ7ALn8ha6AlCkVnip5h8K5fB01OdXzwOEPJ57u2eMoQVYHGwJXKdx/0= X-Received: by 10.233.216.199 with SMTP id u190mr11795910qkf.203.1509098404774; Fri, 27 Oct 2017 03:00:04 -0700 (PDT) MIME-Version: 1.0 Sender: benlaurie@gmail.com Received: by 10.200.22.174 with HTTP; Fri, 27 Oct 2017 03:00:04 -0700 (PDT) In-Reply-To: References: From: Ben Laurie Date: Fri, 27 Oct 2017 11:00:04 +0100 X-Google-Sender-Auth: q78TFe_MWnegvzwZJvlRaq7Odfc Message-ID: Subject: Re: Crypto overhaul To: Eric McCorkle Cc: "freebsd-arch@freebsd.org" , "freebsd-security@freebsd.org security" , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 10:00:06 -0000 On 27 October 2017 at 01:29, Eric McCorkle wrote: > I was going to wait a bit to discuss this, but it's very pertinent to > the trust infrastructure I described earlier this week. > > There was a good bit of discussion at vBSDCon about a possible crypto > overhaul. This is my understanding of the current situation: > > * Userland crypto support is provided by OpenSSL, of course. My sense > is that there's a general dissatisfaction with OpenSSL, but that there's > a nontrivial effort required to liberate userland from it. > > * The kernel has sort of two crypto APIs: crypto and opencrypto. The > design of these APIs seems to be something of older hardware crypto > architectures and export restrictions. This is difficult to extract > from the kernel (and say, embed into the boot loader). > > * BIOS geli pulled the AES implementation out of opencrypto. This was > due in a large part to the size restrictions on BIOS loaders. > > * As a bridge measure, I've introduced boot_crypto into the EFI loader, > in order to support GELI. > > At vBSDcon, there seemed to be a consensus that this situation is too > fragmented. Moreover, it makes life difficult for anyone (like me) who > wants to do crypto-related projects. > > > A couple of options were discussed at vBSDcon. The two that seemed to > come to the forefront were BearSSL and LibreSSL. There seem to be some > advantages and disadvantages both ways: > > * LibreSSL is mature software with staff and support from another BSD > (OpenBSD), they've done some really good work, and have a definite > long-term roadmap. I'm not sure to what extent it could be easily > embedded into a kernel and bootloader, though. Have you considered BoringSSL? > * BearSSL's design seemingly lends itself to acting as a userland, > kernel, and bootloader library. On the other hand, it's new (which > means it will need to be reviewed by crypto experts and thoroughly > tested), and has one developer at this point. OpenSSL includes (and is used for) lots of crypto that is not used in SSL - since BearSSL targets SSL/TLS only, it can't, presumably, be used to replace all uses of OpenSSL. > > > I think it's worth discussing and investigating these options further at > this point. > _______________________________________________ > freebsd-security@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Fri Oct 27 11:37:44 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 362E0E417BD for ; Fri, 27 Oct 2017 11:37:44 +0000 (UTC) (envelope-from nkoch@demig.de) Received: from exch.demig.de (exch.demig.de [87.128.30.225]) (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 ED405162B for ; Fri, 27 Oct 2017 11:37:43 +0000 (UTC) (envelope-from nkoch@demig.de) Received: from [192.168.148.248] (port=19700 helo=SRV-FS-2.Demig.intra) by exch.demig.de with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1e82xE-000221-15; Fri, 27 Oct 2017 13:37:36 +0200 Received: from [192.168.148.215] (192.168.148.215) by SRV-FS-2 (192.168.148.248) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 27 Oct 2017 13:37:30 +0200 X-CTCH-RefID: str=0001.0A0B0204.59F31A80.00AC, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Subject: Re: crerating coredump of multithreaded process To: References: <20171027093311.GF2566@kib.kiev.ua> CC: From: Norbert Koch Message-ID: <95ad25da-dc53-1c6a-030b-71cf9021a75b@demig.de> Date: Fri, 27 Oct 2017 13:37:29 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20171027093311.GF2566@kib.kiev.ua> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-C2ProcessedOrg: e1e98c77-ec17-4cb1-9b24-fe57656077ed X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 11:37:44 -0000 Ok, thank you for your explanation. ***************************************** * demig Prozessautomatisierung GmbH * * * * Anschrift: Haardtstrasse 40 * * D-57076 Siegen * * Registergericht: Siegen HRB 2819 * * Geschaeftsfuehrer: Joachim Herbst, * * Winfried Held * * Telefon: +49 271 772020 * * Telefax: +49 271 74704 * * E-Mail: info@demig.de * * http://www.demig.de * ***************************************** Am 2017-10-27 um 11:33 schrieb Konstantin Belousov: > On Fri, Oct 27, 2017 at 10:44:41AM +0200, Norbert Koch wrote: >> Hello. >> >> When trying to create the coredump of a running >> process (without killing it) under FreeBSD 10.3 >> I am seeing a somewhat strange behaviour. > Try this on HEAD or stable/11. There were a lot of changes and bugfixes > in ptrace(2). > > I do not claim that the behaviour you see has changed, but 10.3 is too > diverged from the code where developers would be willing to look at. >> As I want to see the state of all threads, the q&d way >> of fork() + SIGABRT does not work for me. >> >> So, what I do is having a supervisor program waiting for SIGUSR1. >> When my application signals the wish to be coredumped >> it sends SIGSTOP to itself immediately after sending SIGUSR1. >> The supervisor then forks gcore. >> >> From what I can see using top, my application immediately starts >> again as if SIGCONT has been received while gcore hangs in wait. > SIGCONT cannot be blocked, otherwise programs could create unkillable > processes. > >> Gcore calls ptrace(PT_ATTACH) followed by waitpid(). >> So I assume that the ptrace call restarts my application >> and waitpid hangs (why?). >> >> If I manually send SIGCONT to my stopped application >> immediately before exec-ing gcore, the coredump is being >> created, but for obvious reasons not as consistent as >> I want it to be. >> >> I should add that in my application most other signals are >> blocked. Blocking (or not) SIGCONT seems to have no effect. >> >> Am I doing something wrong here? If yes, ist there >> a different/better/more elegant way of creating a consistent coredump? > What is the purpose of sending SIGSTOP to itself ? Practically, it is no > different than the action of ptrace(PT_ATTACH): all threads are parked > at some safe place in the kernel, or are forcibly moved into the kernel > mode by sending IPI if executing in userspace on other cores. To get > into the safe place in kernel, threads often need to execute some more. > IPI delivery is also not guaranteed to occur in the deterministic place > ("at next instruction boundary"), it happens as hardware reacts to it. > As you see, the process is very asynchronous, it cannot guarantee that > the final snapshot is consistent with arbitrary thread state at the > point of request, but it does represent the valid process state assuming > that the thread are executing async. > > More, ptrace(PT_ATTACH) currently operates not only by a mechanism to > similar to SIGSTOP, it really sends SIGSTOP to the debuggee. We do not > track nested SIGSTOPs, process is either stopped or runnable. So I am > not surprised that attaching to stopped process do not occur until the > stopped state established earlier passes away: the debugger waits for > the confirmation from all threads that they are parked at safe place, > but there is no because the threads are already stopped. If threads are > made runnable the acks are sent and the attach completes. > > I am explaining this to point out that trying to send SIGSTOP and > then attaching with ptrace(PT_ATTACH) is just worse than doing > ptrace(PT_ATTACH). I think you need to have supervisor either > directly execute gcore(1) without SIGSTOP, or execute ptrace(PT_ATTACH) > instead of kill(SIGSTOP), and have gcore functionality embedded into the > it. The consistency of the generated core is actually same. --=20 Dipl.-Ing. Norbert Koch Entwicklung Prozessregler From owner-freebsd-hackers@freebsd.org Fri Oct 27 11:59:26 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E0263E41D60 for ; Fri, 27 Oct 2017 11:59:26 +0000 (UTC) (envelope-from kevans91@ksu.edu) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0077.outbound.protection.outlook.com [104.47.38.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2963B1FBD for ; Fri, 27 Oct 2017 11:59:24 +0000 (UTC) (envelope-from kevans91@ksu.edu) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ksu.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Kw/mv1ype7P0sdmWnkBjWRFPkU0YmBpMNJ4fqWURGio=; b=TWUugXxvAravqg2m/cBhr1nmuUZpI6bzeY23GwbFcIgpdkstdWFNqOFmBjK1PMfUMyV1VGauaV//MOR4tiqjHr0io36ZWYmxW/QEndAW4Y9jzMYbkZ2MoywA3deKJQGuYU6Wbm358+OhAXqbEoRLsyjT8/os6bfehLqMVUMhEgA= Received: from BN3PR05CA0021.namprd05.prod.outlook.com (10.174.64.31) by SN1PR05MB1965.namprd05.prod.outlook.com (10.162.132.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.3; Fri, 27 Oct 2017 11:59:21 +0000 Received: from BL2NAM02FT025.eop-nam02.prod.protection.outlook.com (2a01:111:f400:7e46::200) by BN3PR05CA0021.outlook.office365.com (2603:10b6:400::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.197.4 via Frontend Transport; Fri, 27 Oct 2017 11:59:21 +0000 Authentication-Results: spf=pass (sender IP is 129.130.18.151) smtp.mailfrom=ksu.edu; freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=bestguesspass action=none header.from=ksu.edu; Received-SPF: Pass (protection.outlook.com: domain of ksu.edu designates 129.130.18.151 as permitted sender) receiver=protection.outlook.com; client-ip=129.130.18.151; helo=ome-vm-smtp2.campus.ksu.edu; Received: from ome-vm-smtp2.campus.ksu.edu (129.130.18.151) by BL2NAM02FT025.mail.protection.outlook.com (10.152.77.151) with Microsoft SMTP Server id 15.20.156.4 via Frontend Transport; Fri, 27 Oct 2017 11:59:21 +0000 Received: from calypso.engg.ksu.edu (calypso.engg.ksu.edu [129.130.43.181]) by ome-vm-smtp2.campus.ksu.edu (8.14.4/8.14.4/Debian-2ubuntu2.1) with ESMTP id v9RBxKYY018674 for ; Fri, 27 Oct 2017 06:59:21 -0500 Received: by calypso.engg.ksu.edu (Postfix, from userid 110) id BD17124834E; Fri, 27 Oct 2017 06:59:20 -0500 (CDT) Received: from mail-io0-f182.google.com (mail-io0-f182.google.com [209.85.223.182]) by calypso.engg.ksu.edu (Postfix) with ESMTPA id 8DDC324834F for ; Fri, 27 Oct 2017 06:59:18 -0500 (CDT) Received: by mail-io0-f182.google.com with SMTP id j17so12147536iod.5 for ; Fri, 27 Oct 2017 04:59:18 -0700 (PDT) X-Gm-Message-State: AMCzsaVaEnrmS7I5s4W5KMHxFtl7pXqK7j0l006//qfKUT6R7HKwKU1J HE6YTz5ARx7YwIdBZVHC2OtA0ifJ6rJ5l5mxyn0= X-Google-Smtp-Source: ABhQp+RDzVgQFRqsULdDaaKNCWSH/QWL2ix/fW9uTlO3mhbFA0fVruPE6zbmVZt1UdTh429aXZE8bd+mgl8yLv1j4B8= X-Received: by 10.107.27.7 with SMTP id b7mr266880iob.136.1509105557209; Fri, 27 Oct 2017 04:59:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.23.129 with HTTP; Fri, 27 Oct 2017 04:59:16 -0700 (PDT) Received: by 10.107.23.129 with HTTP; Fri, 27 Oct 2017 04:59:16 -0700 (PDT) In-Reply-To: References: From: Kyle Evans Date: Fri, 27 Oct 2017 06:59:16 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: We do serial differently. To: Zaphod Beeblebrox CC: FreeBSD Hackers X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:129.130.18.151; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(346002)(376002)(39860400002)(2980300002)(438002)(24454002)(199003)(189002)(93886005)(5660300001)(229853002)(106466001)(786003)(246002)(478600001)(316002)(16586007)(42186006)(8676002)(2950100002)(88552002)(61266001)(2906002)(55446002)(53546010)(45336002)(59536001)(8576002)(305945005)(106002)(46386002)(512874002)(54206008)(356003)(498394004)(95326003)(9686003)(54356999)(50986999)(189998001)(8936002)(76176999)(1411001)(90966002)(61726006)(3480700004)(75432002)(236005)(5890100001)(86362001)(4326008)(84326002)(6246003)(93516999)(6862004)(55456009); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR05MB1965; H:ome-vm-smtp2.campus.ksu.edu; FPR:; SPF:Pass; PTR:ip-18-151.net.ksu.edu; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BL2NAM02FT025; 1:hrwTLvCNQuq7cTNGA0INlcDOL8Gx1FE4JyZdpowWXdVnqWD1+2IX1XKb3cty7/HOkRY9qg7qIM+jow2q9asuMGphTEhJhEP/hR9tOOdHRssEZ1fjwVklhzVDQ/DnkvpT X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: d53c4417-68bc-4bf9-ee24-08d51d3228f9 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(8251501002)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:SN1PR05MB1965; X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB1965; 3:2eF8LVHuI5GYaOG/m04KFJC1kWjlteb/dlBF9zDVMkJZfWfqfAVuAQ00bt81BQWlnZJpD6foyRaLIvIn1D4cNbIj2YgBzj4CUFZr6fKMAbtpT4XK63mb0dx6zrPvEsByOBez6LkNuY5jRbtUMPxjQQnCrYQyXeLFS1UnIt7cnCbIlEwq+Ebg2zhCwo6pPXI+ervbjf2Cu2nvduSqiYMba2B6uXmkaCWTT80RbVfoTBRcoNKjTdJBHNbeVcp83FF4BIOeQ94CXgD809sKK4cY6IMVbONRHJei3VJnHIGHyy5KglHHkC3aRGIe+OfmjvansqfbPoVJzt9iR6YmbltmpSyVsgeUu+sUBY3imqZyy2s=; 25:VGUd7SlXjGBvTsWXUkSfcv0//2q9nibuRpfs/ngINY8fPgdZvZw2iE4Azbh0AWkA0OJZOjkGz2Z6UgoJURD1Kg/djjv8EMOd9GkGCcf7ZOEXW/IMuG/qodyo1CvKeTgQdCa2iPZa+lAklLWakgeyOtZYzEzv9XMdaeHybXYNnzYEABT9q/umnfpjgP9hK4M0HwTJg3hm6R0TUE/D5i7SpHngHuhhATpJdZfWDtW0YEvg2qRKCvupkTgcUzVQ6sZayN/wsydIJLMB8t5zURfZqMR1PJ0KaTonHf1qubSPqW8pdIAwwCPNOsj24C6UEvYgTtxfEfQrJ4GurtQDvM9xEb5nMHx9N/nbx1mQ8bp28Iw= X-MS-TrafficTypeDiagnostic: SN1PR05MB1965: X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB1965; 31:Yu+2CiXod1b+JbRJhFBtVMa6cdCIysc4VUGd7dTOcNIM20RVmyoEE+e93g+Qp0ChlG9+VMFl/JydOFEAIdoVfnx/YNmin7WuHwUZqLgRQeoOlojAHCoenKCGQmnIV6NRsf04SC85I8R4yr1NjABQzKfkbLJP0FxC2q5/hS1245hpbgzZyaQ9BIPVve8KKbVv5nkmnLBxoKxC/LuOCBV4MPhMn28RFhA0JBPdkB/IY2M=; 20:YAljan6WQamy+QGXB2grjjTTnIT9aXCJbAsQ1H9NKX8RDJ7Z9IPTH3WCJgQWbieuPVGe+89oNMPiUU0YVZcLNS4TjUuphLJiE6qv9+WxG8mAIm00Yzoc0191/xyIdBr2nP3pEMNZ4E2M5otx56MJu92FHfvm5AaVAKuFkqzoEHVBYz7Wv/6rJbesv+pbaCPySTzSN+EV58BSLxDPqRlDxR6wUDWPUCg2GnkHhlWW7Jg/gvKTJ/sWqI6RbpklkMMfDlDmzXd4vV6bB2p97RcEqGnkPI0fBQ/HvdZ21kJ1gWl5Dn0pmjtG2m94BmaafhHbTuGd0Mv8CVG3+HCnK4NVfCfUmAPAkE/D3MOfim+c8gfna390rUTKa3XyJWGvAg9yu36V/FPlVNNGwF+4zajBe+OgPmRV8Lk7NwcM/cl9q0mJ2GQU9fqg6BuEpWnAUSHYvbJUdqljpWjno2qnbLgaRuVHJ1R1uD06NLcrIHvwymQhcm/2FeG9sPNNqghM9tR+ X-Exchange-Antispam-Report-Test: UriScan:(112903893386949)(21532816269658); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(3231020)(93006095)(93004095)(3002001)(6041248)(20161123558100)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN1PR05MB1965; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN1PR05MB1965; X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB1965; 4:CwCyqf+CN/rHtlmG+V9v9ZEW2qHzelKbK4nB26SVENb898uMwQ7vmCqBkoRGZLyKN4pcitosx83cHg756wYJgjKtOU3LEzdXi2tex4EmrtoIaIqEA7zZQZMMKXuaWLJYhF/xYgKSJ2k7Rj+Voukwy76KaHGwCNnoWeEJWY1Cmew2DltYj11IULYhgHTDRSi+d8KTMC13AHPCS+ncxc83dwEACTnUTIT1gyF9Oym3Ix5y3673gwYspASD8Gb2hRmOihnQ98QuHsqtWNzzutNYLJRW1nf2A0iISSMs4MJxkoofy2kNz0XZ0XR38QniJTNkYRtM3GU/xK1YwzXeNo/akzKLUEEtuJIQF3ltvscyOfg= X-Forefront-PRVS: 0473A03F3F X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN1PR05MB1965; 23:Eu2n4Q+NgQLLnVZzZKw09uMhllGsdgduRb45CBop8?= =?us-ascii?Q?o3UTW+MIlroYMt9+E1DLsAqqVey4f07+p13n2EHE30n9PVtfUgZL7/8rDuQ0?= =?us-ascii?Q?CHojGLeGRmpFPX+UiU3aqHLA5B6ioLE3+TD3FxIBVNjOJhqALHI1fvJkY2ZD?= =?us-ascii?Q?wdiFcO+2BtdZdINEufUOz0y4Gxl5YYiuZSIeWRBrsRtA9vq16VNEcBUVL+79?= =?us-ascii?Q?fAQeS8PWeFx/mGLmZ7VuLUnzc9G8Gcr3J4RXgWNhuOaylh8PMZKcbvroEiH1?= =?us-ascii?Q?Fh0u+o0mGqFZt+9SJu5VpME7xNnSLVhVp7j2SxYKpKFjyuSgqWliU2gv7s3N?= =?us-ascii?Q?V/6OYQY4LADNJw8OfHHVsRZm5UhmxlAIyqmWNq5rrY2CPpew6g37XOCMtN2i?= =?us-ascii?Q?7cGmi6TXaseqSHtkoV5xj+hChf3PYo6vlo4L88B8f7ZrxZ9zWWL8imTTxn79?= =?us-ascii?Q?f6wjkqbGPsBvBfj33Qp9VK18dextRGpzww4vUXOF+kPXbuzdq1ZO024+dvmK?= =?us-ascii?Q?yMiKdUhbHduDYjX5FXPLw3M+S+w1c+5Io4t9+LbWdBTka68TDGxFGvf5/fc1?= =?us-ascii?Q?Snv5TZbdOmU0oYHqaVto3Y0QVSUHLPudRIoTfaogLkqIiLQnkDuF9y4I73fg?= =?us-ascii?Q?FV6NPc4u4/tBolDi6KCv4L4bU2bYVvKHQRav2mRAXHu2CqPlHxeGt9HUdFi6?= =?us-ascii?Q?vp4uNnAn+f890KE5pqAUgczISEALEUtl0iAZfhx2MBlhEhgPxex3fAL41FS1?= =?us-ascii?Q?m2E5tBwM9gICPSfpJZAIksP+MYQNHR442M/f7VhbQYOdDFQWKd25MV2MqljG?= =?us-ascii?Q?rkLvyosW051NZRzj8XfGIWOyj6bbU2fU88O9GFf3stfjCFrW1vGeMwFx9Er6?= =?us-ascii?Q?9AV6m1QRZY3wthRzUOTxwZSF1DvBmzJWhG/p/sjKZYxQUWA4ADxaoLSn40Bj?= =?us-ascii?Q?Xg+pAvx4rHeUFX07KR8sVvVcIz889K9aGUT2AN6e6i6OSqy3uG1SCIBms8R+?= =?us-ascii?Q?NkIVmE6pkwjvDU8SC8HzAwHL76XmJdiXjRbMT654DzSI4kC5jZPa1SrRE26b?= =?us-ascii?Q?4w36ybmOjQisHzpbLpFS8jGq3YhftBtbWIGNVhC/xlXInN9FM/Hs3tf6Dpvk?= =?us-ascii?Q?nCOGKWUPTJHTNGq1Uc0pv9R5hOtru0wGZmamm8v83Uvyc3kq+Z7x6XUz0ET5?= =?us-ascii?Q?v9B15MAPzaH+06mk5fwJDosJ7NM4GgyrcFZkXUnVbLR9VqRwZK44+HIJfjWa?= =?us-ascii?Q?z2NyhBicHunH+gZvMbgouheh7TgcphgWXnRzzBdgYK17yOkRADeNbg0oGGoz?= =?us-ascii?B?Zz09?= X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB1965; 6:sRjW5VdkQlz5zQHEP+ghaBNxMgTGqf770ifDqFbCnce4vZVDaH07pXD3DQ1ItHnRWg81Aq9ZTpK5sgFknKZoEF+DJ5cfHtZho1GWHeNx+KbgSRzljwRVUYjU3RWDof3c9JhWPqXBj2oTakLqCv0+wzdrxOvb6JeetrlLXBnyS8UMbvOReAUNmC9CQp0wLOvvBepmO26HLKhLRH4PSUjjOEe0ewh1ClrK+TUGHTesTnZbqFpgy7oGWmaKnIlMMGR8EH3iMdig9GxtAkxq1C/AABZJ/cflZqrwbM0/QpaNi2stpPfx412BusRtp48g/FLsr5yFJwO5jjVu0+akzWPNL40qPt8saC6y6x0SCSWyIQg=; 5:fVlelmTUuOB3+dR/pAvow4I1Iuo4CoqGvTRryTYqAisx+WpUzlov+/btW4zZLqR9nAGoG78bL0AlpFQfywoLlSDxZ01Pt6ikW1X+y5W+EHcvAzKY2AgLY+/BqZUXuIbXQZZy0FOm3mEsrUXl2rxgswEVyNeyHL+YRqRBBYTs8Pc=; 24:Ng+uXHXJYDohnWxwZD+p+YWFNpJVnaTVuf4qUwLu6mmXYX9syzxMY4KSAld1Y7On6YqVXO9vI0KAERZIaXuLxLamyq3nGDdEf0JOeZmKCpI=; 7:vjnH9UM2yeV0bHczlhRXlJkZhFAlyx+ccZXxDbnzgrtcbQxgvpy7/24vuBlBy76A7ihTFHERx/6JdtDVRoUri+Kh1PsC8so1uwNjr1EvavjESIsrZj45dWBwhvUJTgrdxPs9DtmVPQx7kGtHdAXcjr1taC2aeAMN5xZnILq7g0TybsgwXM7uYQ6tU9SftDj3ZpNaduUMVCqFe2JOhgAxhkS27y12YiM1QkawFLCT86V5qrOX2+PlhGnUzQILScwv SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB1965; 20:Yh5S+X6E3t2bXDRQlBqgNPaXmv3IK69Iq2l03Uci8+FNge9sLvtxvV08bX/xvozN9xStN1bBSsUGNtpK8/YZeNrzUF6n1fijPi3YYqHOgwkIkREnf3jZ1B0EM19EgBcw9AQ21oho23jKb6wR1DAhHSGVmDQmKA7D643uuRVU5bM= X-OriginatorOrg: ksu.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2017 11:59:21.3956 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d53c4417-68bc-4bf9-ee24-08d51d3228f9 X-MS-Exchange-CrossTenant-Id: d9a2fa71-d67d-4cb6-b541-06ccaa8013fb X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=d9a2fa71-d67d-4cb6-b541-06ccaa8013fb; Ip=[129.130.18.151]; Helo=[ome-vm-smtp2.campus.ksu.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR05MB1965 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 11:59:27 -0000 What happens if you just invoke printcore directly, like the example script in the printrun readme? Pronterface has got to be doing something not-entirely-sane here. The reset should always coincide with the port being open()d, and it should behave like the Arduino IDE and cu(1) do. The mega doesn't really have any crazy requirements just to function properly. On Oct 26, 2017 11:46 PM, "Zaphod Beeblebrox" wrote: OK. I played with this all again ... a bit. Firstly, when I run "arduino" (the IDE) ... the arduino board resets immediately (I can tell this because it has an LCD screen attached). But when I run pronterface, it doesn't reset until 5 seconds (roughly) after pronterface exits. I tried adding a hardcoded setDTR(0) or setDTR(1) near this code ... but it doesn't seem to make any palpable difference. On Wed, Oct 25, 2017 at 1:11 PM, Kyle Evans wrote: > On Wed, Oct 25, 2017 at 11:43 AM, Kyle Evans wrote: > >> On Wed, Oct 25, 2017 at 11:34 AM, Zaphod Beeblebrox >> wrote: >> >>> On Mon, Oct 23, 2017 at 9:45 AM, Kyle Evans wrote: >>> >>>> Hi, >>>> >>>> Are you able to connect to it otherwise (w/ cu or friends) and issue, >>>> say, an M105 manually? >>>> >>> >>> yes. With CU I can connect, it resets, then I can issue an "M105" >>> and it parrots back some status. >>> >> >> Ok, cool, that's expected and sounds like Pronterface is doing something >> it shouldn't be. >> >> I'll poke at it a little bit more- last I checked, it didn't look like it >> was doing anything too crazy with pyserial and I've got a working OctoPrint >> (w/ pyserial) setup, so I know that works to some extent. >> >> > For the sake of argument, can you try applying the following patch [1] to > printrun? I don't see a need to be toggling DTR here, and that might narrow > things down a little bit. > > [1] > diff --git a/printrun/printcore.py b/printrun/printcore.py > index b54e750..fd531c3 100644 > --- a/printrun/printcore.py > +++ b/printrun/printcore.py > @@ -218,11 +218,6 @@ class printcore(): > parity = PARITY_ODD) > self.printer.close() > self.printer.parity = PARITY_NONE > - try: #this appears not to work on many platforms, so > we're going to call it but not care if it fails > - self.printer.setDTR(dtr); > - except: > - #self.logError(_("Could not set DTR on this > platform")) #not sure whether to output an error message > - pass > self.printer.open() > except SerialException as e: > self.logError(_("Could not connect to %s at baudrate > %s:") % (self.port, self.baud) + > > > From owner-freebsd-hackers@freebsd.org Fri Oct 27 12:39:09 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D6764E43E67 for ; Fri, 27 Oct 2017 12:39:09 +0000 (UTC) (envelope-from swall@redcom.com) Received: from smtp1.redcom.com (smtp1.redcom.com [192.86.3.143]) by mx1.freebsd.org (Postfix) with ESMTP id A8A1D63A96 for ; Fri, 27 Oct 2017 12:39:09 +0000 (UTC) (envelope-from swall@redcom.com) Received: from localhost (localhost [127.0.0.1]) by smtp1.redcom.com (Postfix) with ESMTP id B04B9A043 for ; Fri, 27 Oct 2017 08:39:08 -0400 (EDT) X-Virus-Scanned: amavisd-new at redcom.com Received: from smtp1.redcom.com ([127.0.0.1]) by localhost (smtp1.redcom.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hg+CO1T8EzLs for ; Fri, 27 Oct 2017 08:39:06 -0400 (EDT) Received: from pie.redcom.com (pie [192.168.33.15]) by smtp1.redcom.com (Postfix) with ESMTP id 44EBCA014 for ; Fri, 27 Oct 2017 08:39:06 -0400 (EDT) Received: from exch-02.redcom.com (exch-02.redcom.com [192.168.32.9]) by pie.redcom.com (8.11.7p1+Sun/8.10.2) with ESMTP id v9RCcml01417 for ; Fri, 27 Oct 2017 08:39:06 -0400 (EDT) Received: from exch-02.redcom.com (fd00::ccaa:c259:22f8:6f4b) by exch-02.redcom.com (fd00::ccaa:c259:22f8:6f4b) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 27 Oct 2017 08:38:48 -0400 Received: from exch-02.redcom.com ([fe80::ccaa:c259:22f8:6f4b]) by exch-02.redcom.com ([fe80::ccaa:c259:22f8:6f4b%12]) with mapi id 15.00.1178.000; Fri, 27 Oct 2017 08:38:48 -0400 From: "Wall, Stephen" To: "freebsd-hackers@freebsd.org" Subject: RE: Crypto overhaul Thread-Topic: RE: Crypto overhaul Thread-Index: AdNPHatXl0NSYB7UT+qMHMXV6x96Qg== Date: Fri, 27 Oct 2017 12:38:47 +0000 Message-ID: <51e5e3f85b6445ed85faf770773118bb@exch-02.redcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.84.20] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 12:39:09 -0000 Be aware that moving away from a crypto library that has a FIPS-approved cr= ypto core will have a significant impact on commercial users of FreeBSD who= do business with U.S. government (and likely some other governments and co= rporate sectors as well). BoringSSL is persuing/has persued FIPS validatio= n, but they offer this warning on their web page: Although BoringSSL is an open source project, it is not intended for genera= l use, as OpenSSL is. We don't recommend that third parties depend upon it.= Doing so is likely to be frustrating because there are no guarantees of AP= I or ABI stability. BearSSL, being a new, small project, is highly unlikely to pursue FIPS cert= ification. LibreSSL has deliberately stripped anything FIPS related out of= their fork, and the project has stated multiple times that it will not com= e back. I am not opposing a change (indeed, consolidating the various crypto source= s in FreeBSD to single (FIPS-possible) library would be a good thing) , I j= ust prefer (strongly) that FIPS not be pushed out of the picture. -spw From owner-freebsd-hackers@freebsd.org Fri Oct 27 13:46:25 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 95523E45788 for ; Fri, 27 Oct 2017 13:46:25 +0000 (UTC) (envelope-from jh-fbml@snkmail.com) Received: from sneak2.sneakemail.com (sneak2.sneakemail.com [64.46.156.55]) by mx1.freebsd.org (Postfix) with ESMTP id E4D9865DAC for ; Fri, 27 Oct 2017 13:46:24 +0000 (UTC) (envelope-from jh-fbml@snkmail.com) Received: from 206.168.13.214 by sneak2.sneakemail.com with SMTP; 27 Oct 2017 13:46:18 -0000 Received: (sneakemail censored 4207-1509111977-98568 #2); 27 Oct 2017 13:46:18 -0000 Received: (sneakemail censored 4207-1509111977-98568 #1); 27 Oct 2017 13:46:18 -0000 Message-ID: <4207-1509111977-98568@sneakemail.com> Date: Fri, 27 Oct 2017 07:46:07 -0600 From: "John Hein" To: freebsd-hackers@freebsd.org To: "Eric McCorkle" , , freebsd-security@freebsd.org, MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: References: Subject: Re: Crypto overhaul X-Mailer: Perl5 Mail::Internet v X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 13:46:25 -0000 Eric McCorkle wrote at 20:29 -0400 on Oct 26, 2017: > I was going to wait a bit to discuss this, but it's very pertinent to > the trust infrastructure I described earlier this week. > > There was a good bit of discussion at vBSDCon about a possible crypto > overhaul. This is my understanding of the current situation: > > * Userland crypto support is provided by OpenSSL, of course. My sense > is that there's a general dissatisfaction with OpenSSL, but that there's > a nontrivial effort required to liberate userland from it. > > * The kernel has sort of two crypto APIs: crypto and opencrypto. The > design of these APIs seems to be something of older hardware crypto > architectures and export restrictions. This is difficult to extract > from the kernel (and say, embed into the boot loader). > > * BIOS geli pulled the AES implementation out of opencrypto. This was > due in a large part to the size restrictions on BIOS loaders. > > * As a bridge measure, I've introduced boot_crypto into the EFI loader, > in order to support GELI. > > At vBSDcon, there seemed to be a consensus that this situation is too > fragmented. Moreover, it makes life difficult for anyone (like me) who > wants to do crypto-related projects. > > > A couple of options were discussed at vBSDcon. The two that seemed to > come to the forefront were BearSSL and LibreSSL. There seem to be some > advantages and disadvantages both ways: > > * LibreSSL is mature software with staff and support from another BSD > (OpenBSD), they've done some really good work, and have a definite > long-term roadmap. I'm not sure to what extent it could be easily > embedded into a kernel and bootloader, though. > > * BearSSL's design seemingly lends itself to acting as a userland, > kernel, and bootloader library. On the other hand, it's new (which > means it will need to be reviewed by crypto experts and thoroughly > tested), and has one developer at this point. > > > I think it's worth discussing and investigating these options further at > this point. What's the overhaul goal here? There's basic crypto libraries with symmetric & assymmetric crypto & hashing (e.g., NaCL, libsodium, openssl's libcrypto). There's libraries that add support for SSL/TLS & X.509 certificates and such. There's stuff to support using crypto hardware (accelerators, secure crypto token storage devices). And is the thought to [eventually] replace openssl in base with something lighter perhaps? I assume we're looking for bsd, isc, mit, etc., style licenses only. From owner-freebsd-hackers@freebsd.org Fri Oct 27 12:45:33 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7B08AE4419D; Fri, 27 Oct 2017 12:45:33 +0000 (UTC) (envelope-from mozolevsky@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 1E16963F8B; Fri, 27 Oct 2017 12:45:33 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: by mail-wr0-x230.google.com with SMTP id o44so6043427wrf.11; Fri, 27 Oct 2017 05:45:32 -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=wYLv4djExMSBeIpSe7YpemDIhoUVP7f45OwUe9MccpI=; b=b4/MozBvDnC7sRlbCexp9guO6CAagXBYVETqwLchtOkFSuBpeoNT1TxU8P1Zj33Py4 IJu2baQA/2BaUbQXF359+yO0eAIhGw5im3e26hYonSoQKrOzWE1YWh76DWkNChJg3Pc+ m/wCCdE4Jhmij0Q8cBUXn4v3MS2L+PcJJlA57AknbyNjEbtrb8HmjHmqQ8VI8bLHw2Cx EZ90MIwitpQqDoWmc6I4A+OQUG8s091Jl3XPn8g6ZWy9lsBXcfa4TbCb5sJjt3ZHUVbQ 9y+FbidTbEm9geEdZmdbDgWx+G5EDWddXU13gZaiZN9isV298GkoofDsD1O7I/yg1Ig+ lHkA== 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=wYLv4djExMSBeIpSe7YpemDIhoUVP7f45OwUe9MccpI=; b=BxQ1U7UdcwJ9JXQzu9G++iNrEQZDVsQ5PYM9Oidzs+ye8AlfJ3OSW0EIGeqc88oQqg 2uAJmk9J/gUC7+WKBW0gvWZiB35tVB7z4TaM3tVa6aiNxGU6v0z9mTnlvFBhmHxcUS5s DdlCk7HfgFrDxtPl1YNx/uAPm6Ew9HyQsYwxm8XhRrznZVATG7bSuwvme3AWyzHWop72 86YlGYhmt3nXTL8Vm87kFv/Nk1B5HIbe6gQsQPI6Bvi9TJ3MhVOKjVaSwUdrPWACQWLt PsDohNV6axs/Uv7HUCpDRvW6s5arsaKzdUCiXQylzhXuk74xta9oXhbtDamGaqjbdxDG GucA== X-Gm-Message-State: AMCzsaXXlyUZcuq0p3WEejN4HThhg8OtNkUuclCbpfHI9MS6q65AGM/r n2505duXdpHdPnwijr7gasdzUG2IxgdB4bgvgsOdlQ== X-Google-Smtp-Source: ABhQp+TbtaV5gZxFJCDJz/QdibQSq89rp67EMu4Uc4JjTvKhwGHmOJR8k5BmmzThWc2TK+LfQljBjeIe+3V8DvAVRRI= X-Received: by 10.223.157.40 with SMTP id k40mr322683wre.153.1509108331592; Fri, 27 Oct 2017 05:45:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.155.6 with HTTP; Fri, 27 Oct 2017 05:44:51 -0700 (PDT) In-Reply-To: References: From: Igor Mozolevsky Date: Fri, 27 Oct 2017 13:44:51 +0100 Message-ID: Subject: Re: Crypto overhaul To: Eric McCorkle Cc: "freebsd-arch@freebsd.org" , freebsd security , "freebsd-hackers@freebsd.org" X-Mailman-Approved-At: Fri, 27 Oct 2017 16:25:37 +0000 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 12:45:33 -0000 Eric, Have a look at mbedTLS which is now part of ARM: https://tls.mbed.org -- Igor M. From owner-freebsd-hackers@freebsd.org Fri Oct 27 17:11:59 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 83B05E4CB06 for ; Fri, 27 Oct 2017 17:11:59 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (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 6262D70A40 for ; Fri, 27 Oct 2017 17:11:58 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id v9RHD9Bi089838 for ; Fri, 27 Oct 2017 10:13:15 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) To: "freebsd-hackers@freebsd.org" In-Reply-To: <51e5e3f85b6445ed85faf770773118bb@exch-02.redcom.com> References: <51e5e3f85b6445ed85faf770773118bb@exch-02.redcom.com> From: "Chris H" Subject: Re: Crypto overhaul Date: Fri, 27 Oct 2017 10:13:15 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <161ecc025cd82beeca46dc7f55599b45@ultimatedns.net> Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 17:11:59 -0000 On Fri, 27 Oct 2017 12:38:47 +0000 "Wall, Stephen" wrote [ re-wrapped for better readability ] > Be aware that moving away from a crypto library that has a FIPS-approved > crypto core will have a significant impact on commercial users of > FreeBSD who do business with U.S. government (and likely some other > governments and corporate sectors as well). BoringSSL is persuing/has > persued FIPS validation, but they offer this warning on their web page: > > Although BoringSSL is an open source project, it is not intended for > general use, as OpenSSL is. We don't recommend that third parties > depend upon it. Doing so is likely to be frustrating because there > are no guarantees of API or ABI stability. > > BearSSL, being a new, small project, is highly unlikely to pursue FIPS > certification. LibreSSL has deliberately stripped anything FIPS related > out of their fork, and the project has stated multiple times that it > will not come back. > > I am not opposing a change (indeed, consolidating the various crypto > sources in FreeBSD to single (FIPS-possible) library would be a good > thing) , I just prefer (strongly) that FIPS not be pushed out of the > picture. > FIPS, or not, Typhoid Mary needs to go, and the sooner the better! Given a choice of using OpenSSl because it has FIPS certification; Knowing that it will likely permit a [near] future system compromise. Or using an alternative with a long history of reliability, safety, and a great deal of scrutiny by seasoned developers, and security engineers. Should be an easy question to answer. FIPS or not. It should be an easy pitch to make -- even to those on the FIPS bandwagon. I don't think there's any reason to panic; OpenSSL will likely still remain in the ports tree, no matter *what's* decided on for $BASE, for those that *must* have it. :) > -spw --Chris > _______________________________________________ > 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 Fri Oct 27 18:02:54 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 54BC0E4D935 for ; Fri, 27 Oct 2017 18:02:54 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::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 DA3BE7223F for ; Fri, 27 Oct 2017 18:02:53 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: by mail-wm0-x232.google.com with SMTP id y83so5277016wmc.4 for ; Fri, 27 Oct 2017 11:02:53 -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=oUTwmTMH2lISy09J9gZHvcXXGq6rMC/p2Nsdo+qUMBg=; b=f4rA2ZYN5E4fLUiFIrmyWBHhrDGrRp28a1GsJd91y/P60Ous2+JT+elR68jYRv70rf P9pbTjZ5MxU+jukgwoi0zvSHzzu+UUj1/KS69yMbLnDuklKOGmV7SF1mg3hDa2MCPTMS JzerHCFxgVC9ZCAXbTv5qt0BMBA7fOrUAMz1J/aqGxkSDO+bfdD5zoB+uy6lvxnpDfmz JnV8ccccCzRlxa0EWCcrBsUmwOxKektlllzq3Qfu2xJsj4dcA+M5ryFnXxLziuQpWJIK UC2YPqho4mod4D2wjtJmBD4sy8VG8npnf0XwlySn/bPr+QjNh4xviQfVYqq0fuzRat6r 7GLA== 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=oUTwmTMH2lISy09J9gZHvcXXGq6rMC/p2Nsdo+qUMBg=; b=JmgznQY1FeqczkaN4KSk6ejBsg11CWCDHiROdizVr2qGlla864dua9XFba3HjDzte0 OKCXAmdtUT6bGlqvP577gFFExhz3lQc9Fbm6yRI1fAZ95NS/bguCUWhMv3DdhLJq5oex mI8FkgMkygDp1tB5B664TlJSSOP5FGs5Wf7pbCZt36MDCENwZz1gGWU/3vbk6MRsRz7l EPbdYzCkkAAh1hPAKp+xGDfb9AP4Np5sA3TzJ/inupBgQA/+jbdHjjtu4WYM0pCYpevL hPnA19MwFMJk6tL4/RsuSa2o2RG/XV1UG6J00ZNZ6tHzU0BEbCCXwm4qyMsfRjV0pR/s uzAw== X-Gm-Message-State: AMCzsaW8+R1dCfqVs0J7Dtol+6B64AhqvkRMyE9MQjQSKtixoBhx/xnB e2sLPjc5RCrOCu3nLxZ3HAg5yfOq+zei9VhhXSDuzw== X-Google-Smtp-Source: ABhQp+QFbjXc1YmOJz5eesfmMROHgSSFBlEzKOeAfLztlV5BlNSpxtkr08zt78b3OT835liUEcjgk/ycn4eI8uIwRW4= X-Received: by 10.80.175.66 with SMTP id g60mr1672088edd.283.1509127372241; Fri, 27 Oct 2017 11:02:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.178.6 with HTTP; Fri, 27 Oct 2017 11:02:51 -0700 (PDT) X-Originating-IP: [38.104.68.66] In-Reply-To: <0d126774-3736-4a4c-c01f-07bc9caf82a6@freebsd.org> References: <333473BB-43C3-4E3E-B62F-03DE5650E403@freebsd.org> <7951e7d5-b5e6-033d-0b51-1d4a10946937@oktetlabs.ru> <0d126774-3736-4a4c-c01f-07bc9caf82a6@freebsd.org> From: Mark Saad Date: Fri, 27 Oct 2017 14:02:51 -0400 Message-ID: Subject: Re: Anyone using Solarflare on FreeBSD 10-STABLE ? To: Andrew Rybchenko Cc: Philip Paeps , Allan Jude , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 18:02:54 -0000 On Fri, Oct 27, 2017 at 2:55 AM, Andrew Rybchenko wrote: > On 10/25/2017 12:04 AM, Mark Saad wrote: > > On Tue, Oct 17, 2017 at 3:44 PM, Andrew Rybchenko > wrote: > > On 10/17/2017 08:54 PM, Philip Paeps wrote: > > On 2017-10-17 19:36:20 (+0200), Allan Jude wrote: > > On 10/17/2017 12:32, Mark Saad wrote: > > Speificly I wanted to know if anyone knew what this sysctl refers to > > dev.sfxge.NN.stats.rxdp_di_dropped_pkts > > I have two 11.1 boxes with a dual ported sfxge each, but I have no idea > what that counter is trying to describe. > > The man page says this is Philip's fault. > > This code is not my fault! ;-) I believe arybchik added it. > > Looking at the code, it's packets that have been dropped in the data path > by the dispatcher cpu. Probably related to virtual functions? > > Philip, thanks. I don't think in this particular case it is related to > virtual functions. > > Basically the counter means that ingress packet does not match any installed > filter. E.g. promiscuous mode is disabled and: > - destination MAC is unicast and not the interface MAC address, OR > - destination MAC is multicast and there is no matching multicast address > added. > > There is a race condition as well on interface bring up when packet is > received but default filters are not installed yet. > > SFN8522 and SFN8542 have other cases for encapsulated traffic depending on > driver version (right now I don't remember the state in 10-STABLE). > > Mark, let me know if I can help more. > > Andrew. > > Could you clarify what was meant by Virtual Functions ? Vlans , laggs > etc or srv-io ? > Also I do have IGMP snoop enabled and routing is done locally on each > router -, the freebsd box with the sfxge cards. > > > I meant SR-IOV. Which SF NIC do you use? > > Andrew. Andrew I am using IIRC 7140's This is what I get from the various utils Solarflare Flareon Ultra 7000 Series 10G Adapter Firmware version: v6.4.3 Controller type: Solarflare SFC9140 Boot ROM version: v5.0.4.1000 -- mark saad | nonesuch@longcount.org From owner-freebsd-hackers@freebsd.org Fri Oct 27 19:24:39 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8F3C3E4EF34; Fri, 27 Oct 2017 19:24:39 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 5665E74470; Fri, 27 Oct 2017 19:24:39 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id 3430C2736D; Fri, 27 Oct 2017 19:24:32 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTP id v9RJOU4K013960; Fri, 27 Oct 2017 19:24:30 GMT (envelope-from phk@phk.freebsd.dk) To: Ben Laurie cc: Eric McCorkle , "freebsd-security@freebsd.org security" , "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" Subject: Re: Crypto overhaul In-reply-to: From: "Poul-Henning Kamp" References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13958.1509132270.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Oct 2017 19:24:30 +0000 Message-ID: <13959.1509132270@critter.freebsd.dk> X-Mailman-Approved-At: Fri, 27 Oct 2017 19:29:13 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 19:24:39 -0000 -------- In message , Ben Laurie writes: >OpenSSL includes (and is used for) lots of crypto that is not used in >SSL - since BearSSL targets SSL/TLS only, it can't, presumably, be >used to replace all uses of OpenSSL. Which implicitly raises the question if we really need all the boatloads of crap OpenSSL drags in, or if we would be in a better position with something simpler and saner ? -- = 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 Oct 27 20:20:15 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6AA3AE4FEC5; Fri, 27 Oct 2017 20:20:15 +0000 (UTC) (envelope-from benlaurie@gmail.com) Received: from mail-qt0-x241.google.com (mail-qt0-x241.google.com [IPv6:2607:f8b0:400d:c0d::241]) (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 22C6A75D27; Fri, 27 Oct 2017 20:20:15 +0000 (UTC) (envelope-from benlaurie@gmail.com) Received: by mail-qt0-x241.google.com with SMTP id v41so9863441qtv.12; Fri, 27 Oct 2017 13:20:15 -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=hob5zPYqqke99nQrl/pKzkrDvJ/oVODIqCXCzeeLOMc=; b=mTvYrn/UTWC+1BBcZ9iuqBLZAqy0K83cqYMIjHz74r1YbXOb6eZaNZoHNabquiBixp 7fqk0rWFdjbZR6HReQ5JPuo30oC1u2Ya5yNyQnH4tlUr/nmUoNihwgS0DUbbHRkR6rEd uCL/MNrfJQP/JtxWYdWmYF5A2Lhn/xnOYYHQhbWxx4KamibrSjHohAcf2URHs/MZrNoD v2LtucNwVqkvkPHa79DLqFsjsuTQf6ym2S7aZcdZ0N0Hq2ihEjuk9VeoE/hY0L3Fp/k6 g/JWPmPo5GQKB0fI+A64rY/W/Z5MeaAIWAekF3bpzbxsat7UAZdKEAr11oHp/PzCYOUI Iz+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=hob5zPYqqke99nQrl/pKzkrDvJ/oVODIqCXCzeeLOMc=; b=RhPee9ZU4c54WHsYuCkpYeL/g9NmQfiQNaeo3XmD6crS0tG8E0DfDTstPaAvd2tUL2 3Gs5wfePxP3aByCwuQ6UsXJi3g+8YqL2s5ROyD1DDRfwXVAxmTjlaaWyXR8046u7vf5A OdcPc5StdCpbVZDDXVYB9bd1xIcCwB8pgzpQR6ChDS8w8AEr/DUbKK091im1wkAmG/+4 H4VYxAeLMN+YRbp6TYG5D5g3t2yNzaRv+IjD4U3ch6Yf0suhhpnKIHHMcIiphbZM4bBI mL873XSUnplk6+048dPkpEAmlaKDCnmdySDm1PtoR0RBVpMQXR04KpVb8hh3SpIHKF9k jkyw== X-Gm-Message-State: AMCzsaUD6875NBs3mNGKfZld5tJd7lD/+JWpyhuaAzm+1I87hNtnTjNo P0ddOfYZlHUxsz3JK5535GGuhYO7jHx7d1H4yP4dyQ== X-Google-Smtp-Source: ABhQp+QQc1awj77CB0MLCSrOltmcvmAmTqY2Ht1FmokSegFjSZOKR4CVsIw1YR1OuoMNxChR3YXggD/PDzG/EShiOq8= X-Received: by 10.200.43.78 with SMTP id 14mr2903815qtv.72.1509135614261; Fri, 27 Oct 2017 13:20:14 -0700 (PDT) MIME-Version: 1.0 Sender: benlaurie@gmail.com Received: by 10.200.22.174 with HTTP; Fri, 27 Oct 2017 13:20:13 -0700 (PDT) In-Reply-To: <13959.1509132270@critter.freebsd.dk> References: <13959.1509132270@critter.freebsd.dk> From: Ben Laurie Date: Fri, 27 Oct 2017 21:20:13 +0100 X-Google-Sender-Auth: ibYg2bI62ET_--wyIEY3HLGQGmM Message-ID: Subject: Re: Crypto overhaul To: Poul-Henning Kamp Cc: Eric McCorkle , "freebsd-security@freebsd.org security" , "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 20:20:15 -0000 On 27 October 2017 at 20:24, Poul-Henning Kamp wrote: > -------- > In message > , Ben Laurie writes: > >>OpenSSL includes (and is used for) lots of crypto that is not used in >>SSL - since BearSSL targets SSL/TLS only, it can't, presumably, be >>used to replace all uses of OpenSSL. > > Which implicitly raises the question if we really need all the > boatloads of crap OpenSSL drags in, or if we would be in a better > position with something simpler and saner ? Indeed it does. Perhaps worth noting that since it was staffed, OpenSSL has removed a fair amount of crap, BTW. Anyway, to answer that question will presumably require someone to either try it, or figure out what is actually needed, crypto-wise. > > -- > 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 Sat Oct 28 02:26:17 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 83E20E585EF; Sat, 28 Oct 2017 02:26:17 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 026B98456F; Sat, 28 Oct 2017 02:26:16 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 1209190e-651ff70000007a39-ef-59f3eac0500f Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 1B.04.31289.0CAE3F95; Fri, 27 Oct 2017 22:26:09 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id v9S2Q3wl031486; Fri, 27 Oct 2017 22:26:05 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v9S2PvpY019877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 27 Oct 2017 22:25:59 -0400 Date: Fri, 27 Oct 2017 21:25:57 -0500 From: Benjamin Kaduk To: Ben Laurie Cc: Poul-Henning Kamp , Eric McCorkle , "freebsd-security@freebsd.org security" , "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" Subject: Re: Crypto overhaul Message-ID: <20171028022557.GE96685@kduck.kaduk.org> References: <13959.1509132270@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIKsWRmVeSWpSXmKPExsUixG6nonvw1edIg0XX+S0Wzea0+Db9L4vF 7OnTmCy2b/7HaNGz6QmbxYdv/A5sHjM+zWfx2Nw0h83j3o4JTB6f9k9mC2CJ4rJJSc3JLEst 0rdL4Mq423GQreCzcMWJny/ZGxibBboYOTkkBEwkTk9Yy9TFyMUhJLCYSeLwtMWsEM5GRok5 r99AOVeZJJovH2ICaWERUJX4230UzGYTUJN4vLeZFcQWEZCT+H37CwtIA7PABiaJp4uugRUJ C8hIHDx7CczmBdp38dtbFoipPxglHuw/zAyREJQ4OfMJC4jNLKAlcePfS6AGDiBbWmL5Pw6Q MKdAoMTyTyvBlokKKEvM27eKbQKjwCwk3bOQdM9C6F7AyLyKUTYlt0o3NzEzpzg1Wbc4OTEv L7VI11gvN7NELzWldBMjKMQ5Jfl2ME5q8D7EKMDBqMTDK5H7OVKINbGsuDL3EKMkB5OSKO++ 858ihfiS8lMqMxKLM+KLSnNSiw8xSnAwK4nwXsgHKudNSaysSi3Kh0lJc7AoifNuC9oVKSSQ nliSmp2aWpBaBJOV4eBQkuA99xKoUbAoNT21Ii0zpwQhzcTBCTKcB2j4c5Aa3uKCxNzizHSI /ClGS45NN+/+YeLY8P0BkHw283UDsxBLXn5eqpQ47weQBgGQhozSPLiZoJQlkb2/5hWjONCL wrzCwAQmxANMd3BTXwEtZAJa2KT6AWRhSSJCSqqB8VjLFD9boZ7dM0W8cnjqRbse1BbEHlHN L163r+6yMltgdFiTbMW2RMmM2P/e92d2ZXz781tlm3Xw5ivij2ysThh01+5ZYmr7Lv2Cbuiu TQn35+wIDFee9UCoRPT4X6++ZdrvuRj/TvH56cE3va1PTOKtttnUP4+/KJ4UDdu4htElMMow 9U+QEktxRqKhFnNRcSIAIRI7gTQDAAA= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2017 02:26:17 -0000 On Fri, Oct 27, 2017 at 09:20:13PM +0100, Ben Laurie wrote: > On 27 October 2017 at 20:24, Poul-Henning Kamp wrote: > > -------- > > In message > > , Ben Laurie writes: > > > >>OpenSSL includes (and is used for) lots of crypto that is not used in > >>SSL - since BearSSL targets SSL/TLS only, it can't, presumably, be > >>used to replace all uses of OpenSSL. > > > > Which implicitly raises the question if we really need all the > > boatloads of crap OpenSSL drags in, or if we would be in a better > > position with something simpler and saner ? > > Indeed it does. Perhaps worth noting that since it was staffed, > OpenSSL has removed a fair amount of crap, BTW. Full disclosure: I am an OpenSSL committer (but not a member of the management committee). It is true that a lot of crap has been removed recently, and the test suite has gotten more robust (not the least due to the addition of a large portion of the BoringSSL test suite). But we're still constrained by a heavy burden of API/ABI stability in major release branches (compounded by a promise to make the next release branch 1.1.1, with TLS 1.3 support, so ABI-breaking changes are currently on indefinite hold). That, combined with an existing public API that grew quite organically and without a great deal of thought, still makes for a system that is hard to maintain well. But I think the main issue with OpenSSL in base that was leading to thoughts about replacing it is the mismatch between FreeBSD release branch support lifecycles and OpenSSL release branch support lifecycles. That is, we (FreeBSD) would be stuck supporting an OpenSSL version that is EOL upstream, which is not a great position to be in. On the other hand, upstream OpenSSL is taking ABI compatibility more seriously, so it might be reasonable to (e.g.) upgrade from 1.1.0 to 1.1.1 within a FreeBSD stable branch than it would (not) have been to upgrade from 1.0.1 to 1.0.2. That might make the support lifecycle concerns go away. > Anyway, to answer that question will presumably require someone to > either try it, or figure out what is actually needed, crypto-wise. Indeed, and I do not think I can volunteer. -Ben P.S., when Chris H mentioned "an alternative with a long history of reliability, safety, and a great deal of scrutiny by seasoned developers, and security engineers", I couldn't really tell what that alternative was supposed to be. From owner-freebsd-hackers@freebsd.org Sat Oct 28 08:17:52 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 32188E5ED4F; Sat, 28 Oct 2017 08:17:52 +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 0D26167A53; Sat, 28 Oct 2017 08:17:51 +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 v9S8Hodv018008 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 28 Oct 2017 01:17:50 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id v9S8Hogh018007; Sat, 28 Oct 2017 01:17:50 -0700 (PDT) (envelope-from jmg) Date: Sat, 28 Oct 2017 01:17:50 -0700 From: John-Mark Gurney To: Eric McCorkle Cc: "freebsd-arch@freebsd.org" , freebsd-security@freebsd.org, "freebsd-hackers@freebsd.org" Subject: Re: Crypto overhaul Message-ID: <20171028081750.GG42467@funkthat.com> Mail-Followup-To: Eric McCorkle , "freebsd-arch@freebsd.org" , freebsd-security@freebsd.org, "freebsd-hackers@freebsd.org" 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, 28 Oct 2017 01:17:50 -0700 (PDT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2017 08:17:52 -0000 Eric McCorkle wrote this message on Thu, Oct 26, 2017 at 20:29 -0400: > I was going to wait a bit to discuss this, but it's very pertinent to > the trust infrastructure I described earlier this week. > > There was a good bit of discussion at vBSDCon about a possible crypto > overhaul. This is my understanding of the current situation: > > * Userland crypto support is provided by OpenSSL, of course. My sense > is that there's a general dissatisfaction with OpenSSL, but that there's > a nontrivial effort required to liberate userland from it. > > * The kernel has sort of two crypto APIs: crypto and opencrypto. The > design of these APIs seems to be something of older hardware crypto > architectures and export restrictions. This is difficult to extract > from the kernel (and say, embed into the boot loader). I wouldn't call them crypto and opencrypto.. There is the opencrypto API, as documented by crypto(9), and then there are various undocumented API's in sys/crypto that give direct software access to various hash and cipher functions... > * BIOS geli pulled the AES implementation out of opencrypto. This was > due in a large part to the size restrictions on BIOS loaders. > > * As a bridge measure, I've introduced boot_crypto into the EFI loader, > in order to support GELI. > > At vBSDcon, there seemed to be a consensus that this situation is too > fragmented. Moreover, it makes life difficult for anyone (like me) who > wants to do crypto-related projects. The opencrypto API is a very terrible API. There are lots of issues w/ it, and it should be overhauled. The algorithm agility that it provides is more complex than needed, and very few people need the options it provides. It increases driver complexity to support the many different ways that encryption and mac algorithms can be ordered... -- 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 Oct 28 08:03:38 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BAC5EE5E67A; Sat, 28 Oct 2017 08:03:38 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 7977D6723E; Sat, 28 Oct 2017 08:03:38 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id 9503027374; Sat, 28 Oct 2017 08:03:35 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTP id v9S83Wap023377; Sat, 28 Oct 2017 08:03:34 GMT (envelope-from phk@phk.freebsd.dk) To: Benjamin Kaduk cc: Ben Laurie , Eric McCorkle , "freebsd-security@freebsd.org security" , "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" Subject: Re: Crypto overhaul In-reply-to: <20171028022557.GE96685@kduck.kaduk.org> From: "Poul-Henning Kamp" References: <13959.1509132270@critter.freebsd.dk> <20171028022557.GE96685@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <23375.1509177812.1@critter.freebsd.dk> Date: Sat, 28 Oct 2017 08:03:32 +0000 Message-ID: <23376.1509177812@critter.freebsd.dk> X-Mailman-Approved-At: Sat, 28 Oct 2017 11:04:21 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2017 08:03:38 -0000 -------- In message <20171028022557.GE96685@kduck.kaduk.org>, Benjamin Kaduk writes: >But I think the main issue with OpenSSL in base that was leading to >thoughts about replacing it is the mismatch between FreeBSD release >branch support lifecycles and OpenSSL release branch support lifecycles. That's not why I want OpenSSL gone from the tree. My reason is that I think OpenSSLs architecture, (to the extent you can talk about OpenSSL having one), APIs and the source code are all horrible. -- 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 Sat Oct 28 12:36:57 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 282C1E425B0; Sat, 28 Oct 2017 12:36:57 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (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 61F0C6E43C; Sat, 28 Oct 2017 12:36:55 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 12074422-b6dff7000000159a-82-59f478ad6dd6 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 22.44.05530.EA874F95; Sat, 28 Oct 2017 08:31:43 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id v9SCVbZ3006042; Sat, 28 Oct 2017 08:31:38 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v9SCVWaM031555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 28 Oct 2017 08:31:35 -0400 Date: Sat, 28 Oct 2017 07:31:32 -0500 From: Benjamin Kaduk To: Poul-Henning Kamp Cc: Ben Laurie , Eric McCorkle , "freebsd-security@freebsd.org security" , "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" Subject: Re: Crypto overhaul Message-ID: <20171028123132.GF96685@kduck.kaduk.org> References: <13959.1509132270@critter.freebsd.dk> <20171028022557.GE96685@kduck.kaduk.org> <23376.1509177812@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23376.1509177812@critter.freebsd.dk> User-Agent: Mutt/1.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIKsWRmVeSWpSXmKPExsUixG6nrru+4kukwYsnKhaLZnNafJv+l8Vi 9vRpTBbbN/9jtOjZ9ITN4sM3fgc2jxmf5rN4bG6aw+Zxb8cEJo9P+yezBbBEcdmkpOZklqUW 6dslcGVsWb2KseAMd8W/+/cZGxhXcHYxcnJICJhI7HrTx9jFyMUhJLCYSeL4ngYoZyOjxJG7 i9khnKtMEnv6DrKCtLAIqEqcvXOcEcRmE1CTeLy3GSwuIqAlsXb2WSaQBmaB2UwSq4+1gBUJ C8hIHDx7iQnE5gXaN+3FDmaIqaeZJD433mOESAhKnJz5hAXEZgaadOPfS6AGDiBbWmL5Pw6Q MKeAkcS2prNgy0QFlCXm7VvFNoFRYBaS7llIumchdC9gZF7FKJuSW6Wbm5iZU5yarFucnJiX l1qka6qXm1mil5pSuokRHOIuSjsYJ/7zOsQowMGoxMMrkfs5Uog1say4MvcQoyQHk5Io777z nyKF+JLyUyozEosz4otKc1KLDzFKcDArifAGlX+JFOJNSaysSi3Kh0lJc7AoifNuC9oVKSSQ nliSmp2aWpBaBJOV4eBQkuBdC9IoWJSanlqRlplTgpBm4uAEGc4DNPw02PDigsTc4sx0iPwp RkuOTTfv/mHi2PD9AZB8NvN1A7MQS15+XqqUOK8WSIMASENGaR7cTFDKksjeX/OKURzoRWHe RpAqHmC6g5v6CmghE9BCDUmwhSWJCCmpBkYOx6rmdXYcj5lerOv/uaev2n/Lpo08oU1xgf8v ntrGNVX31/I9Ebl/Q91UfGXUl9j/+P3P9ODTwHl/vNWurT7JYiIeb7ipXzSPcSZ/WcPvhzcY Ju7utrj6peyGWuONUxyXZRMX2yXmir7MqMqM5ul6JfzJ9qHStZnrr17bNn+S/Hzh+++X5vxV YinOSDTUYi4qTgQA0N6zLDQDAAA= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2017 12:36:57 -0000 On Sat, Oct 28, 2017 at 08:03:32AM +0000, Poul-Henning Kamp wrote: > -------- > In message <20171028022557.GE96685@kduck.kaduk.org>, Benjamin Kaduk writes: > > >But I think the main issue with OpenSSL in base that was leading to > >thoughts about replacing it is the mismatch between FreeBSD release > >branch support lifecycles and OpenSSL release branch support lifecycles. > > That's not why I want OpenSSL gone from the tree. > > My reason is that I think OpenSSLs architecture, (to the extent you > can talk about OpenSSL having one), APIs and the source code are > all horrible. Those are all fine reasons for an individual to want OpenSSL gone from the tree, and I can't really dispute any of them for the 1.0.x series. I would say that the 1.1.x series is less bad, especially on the last count, but don't know how much you've looked at the differences in the new branch. Regardless, the point I was intending to make is that, fine reasons those are, they in and of themselves may not be enough to overcome the weight of POLA for staying with OpenSSL. I do, however, remember a few years ago a Security Officer raising concerns about the support lifecycle mismatch, and in that context that reason does seem to be able to overcome the weight of POLA. That is, I was talking about history. We should of course make our own, fresh, decision about whether your reasons are currently enough to outweigh POLA, for the present discussion. -Ben From owner-freebsd-hackers@freebsd.org Sat Oct 28 13:16:03 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7118FE43448; Sat, 28 Oct 2017 13:16:03 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 1A4196F30E; Sat, 28 Oct 2017 13:16:02 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id 5543C27342; Sat, 28 Oct 2017 13:16:01 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTP id v9SDFxJF024229; Sat, 28 Oct 2017 13:15:59 GMT (envelope-from phk@phk.freebsd.dk) To: Benjamin Kaduk cc: Ben Laurie , Eric McCorkle , "freebsd-security@freebsd.org security" , "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" Subject: Re: Crypto overhaul In-reply-to: <20171028123132.GF96685@kduck.kaduk.org> From: "Poul-Henning Kamp" References: <13959.1509132270@critter.freebsd.dk> <20171028022557.GE96685@kduck.kaduk.org> <23376.1509177812@critter.freebsd.dk> <20171028123132.GF96685@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <24227.1509196559.1@critter.freebsd.dk> Date: Sat, 28 Oct 2017 13:15:59 +0000 Message-ID: <24228.1509196559@critter.freebsd.dk> X-Mailman-Approved-At: Sat, 28 Oct 2017 14:07:32 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2017 13:16:03 -0000 -------- In message <20171028123132.GF96685@kduck.kaduk.org>, Benjamin Kaduk writes: >I would say that the 1.1.x series is less bad, especially on the last count, >but don't know how much you've looked at the differences in the new branch. While "less bad" is certainly a laudable goal for OpenSSL, I hope FreeBSD has higher ambitions. -- 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 Sat Oct 28 14:52:58 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 82C57E4524D for ; Sat, 28 Oct 2017 14:52:58 +0000 (UTC) (envelope-from j.deboynepollard-newsgroups@ntlworld.com) Received: from know-smtprelay-omc-5.server.virginmedia.net (know-smtprelay-omc-5.server.virginmedia.net [80.0.253.69]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Bizanga Labs SMTP Client Certificate", Issuer "Bizanga Labs CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EC60C716D9 for ; Sat, 28 Oct 2017 14:52:57 +0000 (UTC) (envelope-from j.deboynepollard-newsgroups@ntlworld.com) Received: from [192.168.1.5] ([86.10.211.13]) by know-smtprelay-5-imp with bizsmtp id T2rk1w0060HtmFq012rkyU; Sat, 28 Oct 2017 15:51:44 +0100 X-Originating-IP: [86.10.211.13] X-Authenticated-User: J.deBoynePollard-newsgroups@NTLWorld.COM X-Spam: 0 X-Authority: v=2.1 cv=XuEHQgx9 c=1 sm=1 tr=0 a=SB7hr1IvJSWWr45F2gQiKw==:117 a=SB7hr1IvJSWWr45F2gQiKw==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=x7bEGLp0ZPQA:10 a=Hw8hSUHECGJrHUsrF90A:9 a=QEXdDO2ut3YA:10 From: Jonathan de Boyne Pollard Subject: New reboot flag: -c for 'power cycle' To: FreeBSD Arch , FreeBSD Hackers Message-ID: <01741ade-cd76-3e7a-2b75-0d9984a6ee90@NTLWorld.COM> Date: Sat, 28 Oct 2017 15:51:43 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2017 14:52:58 -0000 Warner Losh: > Since init has no controlling terminal, SIGWINCH is useless to it anyway. This is untrue for two reasons. First, for some years now the nosh toolset's system manager has been recognizing SIGWINCH on FreeBSD/TrueOS for Linux compatibility; as on Linux it is sent to process #1 in response to a kernel virtual terminal attention key sequence. Second, that argument is fallacious because it would also apply to controlling-terminal-generated signals such as SIGINT and clearly does not given that SIGINT is useful to process #1. So what I am doing in the nosh toolset for the forthcoming version 1.36 is this: * The compatibility shutdown command now sports a new -c/--powercycle option. * The compatibility reboot, halt, and poweroff commands now sport a new -c/--powercycle option, for the benefits of cruel system administrators. * There is a new compatibility fastpowercycle/powercycle command, with all of the same options for cruel system administrators. * system-manager now treats SIGWINCH differently on non-Linux operating systems, treading it as a request to invoke a new powercycle service. SIGRTMIN+6, unused in the systemd system, is the Linux equivalent. * system-manager now treats SIGRTMIN+16 as the underlying actual powercycle request, which it translates to either RB_POWERCYCLE if it is present in the C library headers, or RB_AUTOBOOT if it is not. * There is now a new system-control powercycle subcommand, which defaults to sending SIGWINCH/SIGRTMIN+6 or SIGRTMIN+16. * The system-control init subcommand now sports a new c/C argument, by analogy to h/H. This is of course thus reflected automatically in the compatibility telinit command and the initctl-read server. From owner-freebsd-hackers@freebsd.org Sat Oct 28 15:30:08 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7B23AE45EF3 for ; Sat, 28 Oct 2017 15:30:08 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::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 1D23472402 for ; Sat, 28 Oct 2017 15:30:08 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22d.google.com with SMTP id f20so18546546ioj.9 for ; Sat, 28 Oct 2017 08:30:08 -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=nGYU2ZWPBnItcaOT5DNyvM2UB1wTAg85F+PrNlqU8WM=; b=wv/qq7zuq/NFrvbBXA+u0gHfe65CuyRTxuDVq32ubG56ziKQLk/NkvjP04YrKdFDwr zz94cGyODbCfb7VjgxoOAC7bCAZw5IbfEDirXNwYpImyqE3gT6V5BrwjdRgkdC5XszhL HEltQWX7ajO2lquqbCTzQQKM/4Oj+Q0+rfj1wEF7Sumy4yl+wEBbOvKHzD5nLvy6J5eq +XE2SNAQdot3HvYF+lM85HuMgPrsAK0Ysyg/lwvnLzUo7gUrY1pb6vIZVkU81zgivbRy PSNDz5BehUgE3fsvWBypo9ICDaOSAqeNOKaj2k7lRFtoGeoDfUqQDKpmazGv9HdhFkTT P1DQ== 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=nGYU2ZWPBnItcaOT5DNyvM2UB1wTAg85F+PrNlqU8WM=; b=Ab9/HzAxuQypB9+JKN2z7ah5oXi9or5g2CaijCqsrPs1XKbqTaCKaKeadtMkwzcTTr xk5f59rHYFpk8gmHc1lB64O2xtJnpmtJXxRYGCoVrlH2NP/u+GtIf2VYuPC7+41z5IRV 7puxmoWpBTfTTZJEOZUdqxuiiPkePh7m54k+jAtua2C6ZzHoTkwCyNRe/jm30Qn66lLX /PsxLxjksBkGvSd9Bid/B5/ES2Wvo61ljIDRiUjCLz/NwyRP6NTEVNziBpHNyfa9RtUQ Hdl+gnWCGYNdrTG7sWq0VbDdCKaRb/SOmaIJicnDN+kLb2V8XNK28HbSn0I9KfAC/gL3 RTAA== X-Gm-Message-State: AMCzsaWf8oBPtVVrC3yStfFGDmJfNjBXqWpvG/6AA/xk28xRcoKhhxZ8 JTQkhGg2Wk8ACZ5Vc2WHlhLqrLe6lTfe1hftJQgKGQ== X-Google-Smtp-Source: ABhQp+SmGvL4/KSmQtOWBHTQBq+6dSrS69BWjIar4KFPe605yKR5arDFQv5gyRt4SymXDHL7slRHK4kw0EXDpLs19P4= X-Received: by 10.36.184.5 with SMTP id m5mr5259070ite.69.1509204606969; Sat, 28 Oct 2017 08:30:06 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.57.22 with HTTP; Sat, 28 Oct 2017 08:30:06 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:817e:dabb:4900:7bcb] In-Reply-To: <01741ade-cd76-3e7a-2b75-0d9984a6ee90@NTLWorld.COM> References: <01741ade-cd76-3e7a-2b75-0d9984a6ee90@NTLWorld.COM> From: Warner Losh Date: Sat, 28 Oct 2017 09:30:06 -0600 X-Google-Sender-Auth: VlqCl_-Fxp-__35b8txd5dx0y5M Message-ID: Subject: Re: New reboot flag: -c for 'power cycle' To: Jonathan de Boyne Pollard Cc: FreeBSD Arch , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2017 15:30:08 -0000 On Sat, Oct 28, 2017 at 8:51 AM, Jonathan de Boyne Pollard via freebsd-arch wrote: > > Warner Losh: > > > Since init has no controlling terminal, SIGWINCH is useless to it anyway. > > This is untrue for two reasons. First, for some years now the nosh > toolset's system manager has been recognizing SIGWINCH on FreeBSD/TrueOS > for Linux compatibility; as on Linux it is sent to process #1 in response > to a kernel virtual terminal attention key sequence. Second, that argument > is fallacious because it would also apply to controlling-terminal-generated > signals such as SIGINT and clearly does not given that SIGINT is useful to > process #1. > It's useless for its intended purpose, which is why it can be appropriated. I was completely unaware of SIGWINCH being used like this on Linux. It didn't pop up in the quick research I did before implementing this. But it would have been nice to know this sooner, but I'm OK with later since it isn't much later.. > So what I am doing in the nosh toolset for the forthcoming version 1.36 is > this: > Might want to hold off on this a smidge... See below... > * The compatibility shutdown command now sports a new -c/--powercycle > option. > > * The compatibility reboot, halt, and poweroff commands now sport a new > -c/--powercycle option, for the benefits of cruel system administrators. > > * There is a new compatibility fastpowercycle/powercycle command, with all > of the same options for cruel system administrators. > Hmmm, I like this. I'll have to add it to FreeBSD. I should have thought of it in the first place. > * system-manager now treats SIGWINCH differently on non-Linux operating > systems, treading it as a request to invoke a new powercycle service. > > SIGRTMIN+6, unused in the systemd system, is the Linux equivalent. > > * system-manager now treats SIGRTMIN+16 as the underlying actual > powercycle request, which it translates to either RB_POWERCYCLE if it is > present in the C library headers, or RB_AUTOBOOT if it is not. > > * There is now a new system-control powercycle subcommand, which defaults > to sending SIGWINCH/SIGRTMIN+6 or SIGRTMIN+16. > It looks like all the SIGRT* signals are user defined, and can be used for any purpose by the application. It could easily be SIGRTMIN+6 as it is SIGWINCH and we could ditch SIGWINCH on FreeBSD in init as well (since it's only been in -current for a few days). Would that suffice to address the compatibility concerns? There's no reason to be gratuitously different here. > * The system-control init subcommand now sports a new c/C argument, by > analogy to h/H. > > This is of course thus reflected automatically in the compatibility > telinit command and the initctl-read server. > Warner From owner-freebsd-hackers@freebsd.org Sat Oct 28 22:01:37 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 138D2E4E58D for ; Sat, 28 Oct 2017 22:01:37 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::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 D1E2381AAC for ; Sat, 28 Oct 2017 22:01:36 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: by mail-io0-x235.google.com with SMTP id b186so19649105iof.8 for ; Sat, 28 Oct 2017 15:01: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-language; bh=Vy8BCgKjuCfnKkuDEcmEwuJ/mRS0DTWE0ybd7gNQHs8=; b=faCHPejaReg2XIwZCrmLEhivhn9Y8wEGnMxrp37adg05eclifbGzo8IeRE7OXMNiRh /3f8a8xMFAfRRgcRF6I/3LoMeD7+7CzihAVo8egcSEuOlaifr/lSJ0UmK7rG0iKa0SEy XjUlcN89GaaDK62ipem4AosHtQvNfojXae5f4M4mHS8Fo3CUb/+eG/CZ1mflZ1k9perb XffhaU0QbSQ4UOEBq3kjO8MgY/b+B3IJb5C6g8JPjb+in2ZYqi0VWcmN89XgBAZ1L4zO aOkNxLT8OfP5efQuy352ttBoLeT8UsNxJtpSfflMMcAPuKIn5QaKoXYrWbxQ4THKiGb4 aFVQ== 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-language; bh=Vy8BCgKjuCfnKkuDEcmEwuJ/mRS0DTWE0ybd7gNQHs8=; b=VvrCwlZdXwLcINuNMHqJiLOdQe0S8k/+wzUYG4W7260kJj2OwIveZakqsAKRqRuQ45 Y8PvMGJzBC5a4+ZpS6N0Ph7RmLSwYSewtpcu2C0vkOP2VCOSU84BO09b4P16e12zzfXL 9DL4K6KfiMJQe3Q70EgI8TI8gWLt6m5MLzD9gQmfcNpfPzdKQHEKkdonOYrsArcL0ZB5 NmyR/VnHuFKnjIKdtana+xqXl0YTwln9yLpHkgXpkbntkFUaN+fVHamWmoUBR4g6IZiB QuBI7TqE9LZQ1nTi/3klhlL9jRkaDbDtgMQhbmYnPFxhoyjgRmLaaIBFxmN09KBzlnny QoDQ== X-Gm-Message-State: AMCzsaWCvDHH08iudMWswcwk68TERAOE8qkTX7NM2K+ylbuadk25Vxku qz3MgyuW6y9niW1zgZEt11z3fFM= X-Google-Smtp-Source: ABhQp+QrOAE3xAUAPhceCdIZrsglh/gl8BBmj4CvFE3QT2MCzvtDHJ4FAVtfvXVb1ryscyEB06+0mA== X-Received: by 10.107.10.82 with SMTP id u79mr5560532ioi.252.1509228095789; Sat, 28 Oct 2017 15:01:35 -0700 (PDT) Received: from canoe.dclg.ca (strike.eicat.ca. [66.96.16.50]) by smtp.gmail.com with ESMTPSA id h81sm181013itb.18.2017.10.28.15.01.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 28 Oct 2017 15:01:34 -0700 (PDT) Subject: Re: We do serial differently. To: Kyle Evans Cc: FreeBSD Hackers References: From: Zaphod Beeblebrox Message-ID: Date: Sat, 28 Oct 2017 18:01:35 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2017 22:01:37 -0000 I've tried hacking at directly.  I can't send it a file (as in that script) because the printer isn't setup yet.  I'm still working on it. ... I have poked on the .send() method (with M105) ... and that doesn't seem to have effect.  Also ... if I ctrl-C the python process, it doesn't exit.  I'm not patient... but so far I've only been able to exit with CTRL-\ ... (core dump). On 27/10/2017 07:59, Kyle Evans wrote: > What happens if you just invoke printcore directly, like the example > script in the printrun readme? > > Pronterface has got to be doing something not-entirely-sane here. The > reset should always coincide with the port being open()d, and it > should behave like the Arduino IDE and cu(1) do. The mega doesn't > really have any crazy requirements just to function properly. > > > On Oct 26, 2017 11:46 PM, "Zaphod Beeblebrox" > wrote: > > OK.  I played with this all again ... a bit. > > Firstly, when I run "arduino" (the IDE) ... the arduino board > resets  immediately (I can tell this because it has an LCD screen > attached). > > But when I run pronterface, it doesn't reset until 5 seconds > (roughly) after pronterface exits. > > I tried adding a hardcoded setDTR(0) or setDTR(1) near this code > ... but it doesn't seem to make any palpable difference. > > On Wed, Oct 25, 2017 at 1:11 PM, Kyle Evans > wrote: > > On Wed, Oct 25, 2017 at 11:43 AM, Kyle Evans > wrote: > > On Wed, Oct 25, 2017 at 11:34 AM, Zaphod Beeblebrox > > wrote: > > On Mon, Oct 23, 2017 at 9:45 AM, Kyle Evans > > wrote: > > Hi, > > Are you able to connect to it otherwise (w/ cu or > friends) and issue, say, an M105 manually? > > > yes.  With CU I can connect, it resets, then I can > issue an "M105" and it parrots back some status. > > > Ok, cool, that's expected and sounds like Pronterface is > doing something it shouldn't be. > > I'll poke at it a little bit more- last I checked, it > didn't look like it was doing anything too crazy with > pyserial and I've got a working OctoPrint (w/ pyserial) > setup, so I know that works to some extent. > > > For the sake of argument, can you try applying the following > patch [1] to printrun? I don't see a need to be toggling DTR > here, and that might narrow things down a little bit. > > [1] > diff --git a/printrun/printcore.py b/printrun/printcore.py > index b54e750..fd531c3 100644 > --- a/printrun/printcore.py > +++ b/printrun/printcore.py > @@ -218,11 +218,6 @@ class printcore(): >                        parity = PARITY_ODD) >  self.printer.close() >  self.printer.parity = PARITY_NONE > -   try:  #this appears not to work on many platforms, so > we're going to call it but not care if it fails > -       self.printer.setDTR(dtr); > -   except: > -       #self.logError(_("Could not set DTR on this > platform")) #not sure whether to output an error message > -       pass >  self.printer.open() >  except SerialException as e: >  self.logError(_("Could not connect to %s at baudrate %s:") % > (self.port, self.baud) + > > > > From owner-freebsd-hackers@freebsd.org Sat Oct 28 22:08:37 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 43E38E4E9C2 for ; Sat, 28 Oct 2017 22:08:37 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-145.reflexion.net [208.70.210.145]) (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 CA67A81D98 for ; Sat, 28 Oct 2017 22:08:35 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 32351 invoked from network); 28 Oct 2017 22:08:29 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 28 Oct 2017 22:08:29 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sat, 28 Oct 2017 18:08:29 -0400 (EDT) Received: (qmail 3706 invoked from network); 28 Oct 2017 22:08:29 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 28 Oct 2017 22:08:29 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id CF276EC8C4A; Sat, 28 Oct 2017 15:08:28 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Question for powerpc64 lib32 (powerpc) support: what ABI is the powerpc code supposed to be using? Message-Id: <618F5419-0BB7-496E-B1B8-DA8BE6D54A58@dsl-only.net> Date: Sat, 28 Oct 2017 15:08:28 -0700 To: FreeBSD PowerPC ML , freebsd-hackers X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2017 22:08:37 -0000 powerpc64 and powerpc have very different stack handling rules for FreeBSD. As an example, powerpc does not require red-zones for signal handling in the kernel but powerpc64 does. For lib32 support, what ABI is the powerpc code supposed to follow in the powerpc64 environment? What style of stack handling (and related register usage) is supposed to be in use? If it is distinct from powerpc native's ABI, what documentation should be looked at for the ABI? === Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Sat Oct 28 23:31:07 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5FE22E50747; Sat, 28 Oct 2017 23:31:07 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 3B66D83D9B; Sat, 28 Oct 2017 23:31:07 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 9489D174B; Sat, 28 Oct 2017 23:31:06 +0000 (UTC) Subject: Re: Crypto overhaul To: John Hein , freebsd-arch@freebsd.org, freebsd-security@freebsd.org, freebsd-hackers@FreeBSD.org References: <4207-1509111977-98568@sneakemail.com> From: Eric McCorkle Message-ID: Date: Sat, 28 Oct 2017 19:31:06 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <4207-1509111977-98568@sneakemail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2017 23:31:07 -0000 On 10/27/2017 09:46, John Hein wrote: > What's the overhaul goal here? There's basic crypto libraries with > symmetric & assymmetric crypto & hashing (e.g., NaCL, libsodium, > openssl's libcrypto). There's libraries that add support for SSL/TLS > & X.509 certificates and such. There's stuff to support using > crypto hardware (accelerators, secure crypto token storage devices). > > And is the thought to [eventually] replace openssl in base with > something lighter perhaps? > > I assume we're looking for bsd, isc, mit, etc., style licenses only. > Sorry for being slow to reply. There's a couple of goals that seem to be in common here (and which I've seen reflected in the comments to my original posting. * Dissatisfaction with the OpenSSL codebase and its history of vulnerabilities. * Desire to consolidate the crypto implementations, specifically, for a crypto library that can serve userland, kernel, and bootloaders. * In my case, the trust framework stuff I wrote about requires public-key crypto in the kernel and loader, which isn't something the kernel crypto framework can do. * It's also harder to add new ciphers when there's multiple crypto codebases.