From owner-freebsd-hackers@freebsd.org Sun May 29 09:18:36 2016 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 C8052B4C1A7 for ; Sun, 29 May 2016 09:18:36 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1E0E41AC0; Sun, 29 May 2016 09:18:35 +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 u4T9IRAH091519 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 29 May 2016 12:18:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u4T9IRAH091519 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u4T9IRdd091518; Sun, 29 May 2016 12:18:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 29 May 2016 12:18:27 +0300 From: Konstantin Belousov To: Eric McCorkle Cc: Allan Jude , freebsd-hackers@freebsd.org Subject: Re: EFI GELI support ready for testers Message-ID: <20160529091827.GD38613@kib.kiev.ua> References: <519CC1FC-84DF-4710-8E62-AF26D8AED2CF@metricspace.net> <20160528083656.GT38613@kib.kiev.ua> <20160528172618.GB38613@kib.kiev.ua> <6A9DADE0-B214-424A-BB14-0B0848F0D08D@metricspace.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6A9DADE0-B214-424A-BB14-0B0848F0D08D@metricspace.net> User-Agent: Mutt/1.6.1 (2016-04-27) 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.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2016 09:18:36 -0000 On Sat, May 28, 2016 at 04:02:43PM -0400, Eric McCorkle wrote: > > > On May 28, 2016, at 13:26, Konstantin Belousov wrote: > > > >> On Sat, May 28, 2016 at 10:27:40AM -0400, Allan Jude wrote: > >>> On 2016-05-28 04:36, Konstantin Belousov wrote: > >>>> On Fri, May 27, 2016 at 07:39:57PM -0400, Eric McCorkle wrote: > >>>> I am pleased to announce that my work to add support for GELI in the EFI boot loader (as well as perform more general refactoring) is now ready for testing. I am able to successfully detect multiple GELI partitions in boot1 and pass the keys into the kernel. > >>> > >>> Can somebody explain in which way this is useful ? > >>> Same question for the GELI code for non-EFI loader. > >>> > >>> BIOS cannot read raw data from the encrypted partition, so you need > >>> either old boot or the loader and some additional data on EFI boot > >>> partition anyway. > >>> > >>> Features adds significant amount of code, which must be maintained in > >>> parallel with the kernel code. > >>> _______________________________________________ > >>> 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" > >> > >> The motivation for my work (GELI in boot2 and loader for non-EFI boot) > >> was supporting ZFS boot environments. Previously, when you use GELI you > >> needed to have two ZFS pools, one for an unencrypted /boot and one for > >> the encrypted / > >> > >> This breaks ZFS boot environments, since a snapshot of the root file > >> system won't include the correct kernel etc. > > Why cannot /boot included into the boot environment ? > > When I last saw Solaris, somewhere in its 10-th, any amount of > > filesystems could be added to the bootenv. But whatever the definition > > of bootenv is used, it exists at a level of the shell scripts and selecting > > the actual partition for loader. Throw thousand lines of code into > > the unstable and very hard to debug environment of loader looks somewhat > > unproductive. > > You misunderstand. Alan was talking about pure ZFS systems, where there is one big ZFS pool holding everything. You need to be able to access /boot obviously, but ZFS does not allow you to assign separate out data on to a single device. It creates a pool, which combines all devices. > > To have /boot unencrypted, you have to have a separate partition for just /boot, which is undesirable. Why it is undesirable ? You must have EFI boot partition by any means. And why it is simultaneously desirable to add a bunch of code to loader to hide this ? > > >> > >> The final version of my geliboot took an extra effort to reuse the AES > >> code from sys/crypto/rijndael and sys/opencrypto and GELI directly from > >> sys/geom/eli to avoid maintaining a separate copy of that code in sys/boot > > Which means that kernel code must be also runnable in the strange and > > incompatible environment of the loader. I cannot see how this reduces > > code maintanability even a bit. I am already rather unhappy about ZFS > > kernel code being compiled as the userspace library, which hurt me > > and other people more than once. Now (?) the kernel code must be also > > verified for the loader. > > I mean, the loader has to be able to access the filesystems, there's no way around it (barring crazy coreboot stuff). > > Also, it should be possible to create a synthetic EFI test-harness that runs in *userland*. EFI is basically just a bunch of tables of function pointers, no bios interrupts or anything. As long as you implement the interfaces, any loader should also run in your synthetic environment. I had plans to look into this after this work is done. > Of course EFI is not 'just a bunch of tables'. It might look so when you have tunnel vision and all you do is writing code making calls, but it is definitely not when you consider it as a part of platform. UEFI makes it absurdly easy to distribute a code that gets executed on every boot before boot loaders. The most straighforward is to put UEFI driver binary into the UEFI FAT and register it into some variables (too lazy to remember details). You get this way both boot- and runtime- injection, officially supported. This was one of the reason for secure boot. To avoid trivial debunks, I put a note that of course drivers are not the only way for such code to appear on the system, without requiring any hardware modifications. The rich programming environment, with flat memory and full control over hardware, with easily explorable data structures, with documented and compatible ways to get code persistent are the characteristics of it. It is much easier to target such preboot env then to maintain dynamic list of the userspace escalation code. > >> > >> Hopefully the work I did to make sys/opencrypto and sys/geom/eli more > >> reusable outside of the kernel will make it easier for Eric to do the > >> same for the EFI version. > >> > >> The motivation for the EFI version is the same, ZFS boot environments, > >> plus the obvious security advantages of having the kernel stored > >> encrypted rather than not. > > > > Obvious security advantages ? Seriously ? > > What is a single 'security' advantage of hiding the kernel ? > > > > There are plenty. > > Right up at the top, an attacker able to access /boot is free to tamper with anything, and can insert back-doors into the kernel, loader, or any module. If you assume that the attacker can't write, then they can still scan the kernel and modules for signatures for known vulnerabilities (since the kernel itself has a commit id and detailed version info, they can compare this against a CVE database). Even if they can't do that for some reason, they could still potentially exfilt a kernel address map for use in rootkit attacks against your system. Lastly, general security principles say to minimize the attack surface, which would definitely mean you should protect the core of the system. > I cannot believe that somebody considers hiding kernel binary even remotely viable 'security' measure. But let me accompany that for a second and see what attack surface does the attacker get from knowing the kernel binary ? >From inspecting quirks in the syscalls it is (almost trivially) easy to reconstruct the date of kernel sources up to probably month, without causing much observable havoc in the system. The kern.osreldate is around as well, not only as sysctl, but also having some impact on the runtime behaviour of several syscalls and image activators. Same fingerprints are available from the sizes of the objects in UMA zones, readily available from vmstat -z. Changes in the basic kernel structures layout are reflected in the size changes. Facilities like procstat -kk would show code reorganization and refactoring changes. The list above was written after about 10 minutes spent on thinking how to identify the system sources without having access to binaries. I believe another 10 minutes would give even more suggestions. > > Since you noted a 'security', I realized that your changes decrypt the > > keys in the pre-kernel environment. In other words, very sensitive > > material becoming accessible to strange and unknown code which is > > managed by firmware. > > The likelihood of such an attack, while something I considered, is very low. A key should look like random binary data (much like the GUIDs prevalent in EFI code). I seriously doubt someone could write a firmware module that could dig through the memory state of an arbitrary OS's boot loader and find keys. You'd basically have to put a full online binary analysis framework in the firmware, and have it run fast enough to not be noticed. That would be some serious Turing award-worthy work kept secret from the world solely to build firmware backdoors. I don't think even Lenovo would go that far. > > (I know I mentioned scanning the kernel as a threat above; that's an offline attack that can be done on a copy. Online undetectable analysis of a running program is WAY harder.) > Nobody would scan for random data looking like keys. If attacker is interested in keys from the freebsd loader or password decrypting the keys, the address of the memory region where the material is stored and region' layout are immediately available for any code collocated in the common address space. The hooks into the interfaces and pre-recorded sequence of calls for the initialization of loader give unique execution profile which allow to determine the password and key storage location. Exact attack scenario is not the point I am trying to make. Instead, I point out that UEFI execution environment is shared one, with no walls between software components from arbitrary sources. It is absolutely unsuitable for exposing sensitive material. Even more laughtable to simultaneosly hide kernel binary. In contrast with the kernel environment, which even with ME/BMC/ACPI/UEFI runtime components, is less penetrable by trying to own the execution state of the machine. > Besides, if someone wants to do evil things in firmware, I think it's far more likely they'd just backdoor the network or USB controllers to let someone send an override packet and execute bundled code in kernel mode. That works every time for every OS and doesn't require surreptitiously picking apart arbitrary programs' data structures in real time. > Of course backdoring hardware is order of magnitude harder and requires physical access to the machine. The realistic action by level of script kiddie is getting UEFI driver installed. To close this branch, backdored busmasters (but not ME) are trivially mitigated by enabling IOMMU, FWIW. > For what it's worth, I have considered possible hardening measures: using alias GUIDs to disguise interfaces and adding per-build padding or XOR masks to structures with keys to throw off scanners. However, I don't think the threat is realistic enough to warrant such measures. > I do not see a way to comment about the measures, without adding the word 'theatre'. > > Putting aside ineradicable evil of Intel ME or its > > AMD twin, and SMM handler, you are exposing keys to whatever code happen > > to inhabit the preboot env, not neccessary originating from the firmware > > vendor. Secure Boot would not help there, since when the measurement > > indicate that untrusted component was there, it is too late. I.e., > > you making much easier for malice hacker to steal the keys. > > I mean, the same argument holds for the kernel, if not moreso. You have ACPI bytecode, SMM, device blobs, anything that the boot environment chose to keep around for runtime by marking that memory as "unavailable", and of course, the evil that is Intel ME. This is an unavoidable risk of having keys in main memory ever. > See above. > If you really want any kind of safety from this, you need to use a hardware crypto device that stores keys in a separate memory (which, I specifically designed things to make it easy to add support for one). Of course, you then have to trust the device... > No, what I want is avoiding bad choices which are seemingly made just because code can be written. Code exposing sensitive material is written for very weak and leaking environment, at least without secure boot turned on. Arguments supporting that decision reference 'security' by e.g. hiding kernel binary, and undesire to have /boot partition. Please take a step outside and see bigger picture. From owner-freebsd-hackers@freebsd.org Sun May 29 14:10:24 2016 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 4C19EB5154B for ; Sun, 29 May 2016 14:10:24 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (207-172-209-83.c3-0.arl-ubr1.sbo-arl.ma.static.cable.rcn.com [207.172.209.83]) by mx1.freebsd.org (Postfix) with ESMTP id 1C09A1437; Sun, 29 May 2016 14:10:23 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:8fe:6a13:797b:e9c9] (unknown [IPv6:2001:470:1f11:617:8fe:6a13:797b:e9c9]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 8912D1880; Sun, 29 May 2016 14:10:17 +0000 (UTC) References: <519CC1FC-84DF-4710-8E62-AF26D8AED2CF@metricspace.net> <20160528083656.GT38613@kib.kiev.ua> <20160528172618.GB38613@kib.kiev.ua> <6A9DADE0-B214-424A-BB14-0B0848F0D08D@metricspace.net> <20160529091827.GD38613@kib.kiev.ua> Mime-Version: 1.0 (1.0) In-Reply-To: <20160529091827.GD38613@kib.kiev.ua> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <46B3F9E2-A25B-4F9D-B35F-11AC782495B1@metricspace.net> Cc: Allan Jude , freebsd-hackers@freebsd.org X-Mailer: iPad Mail (13D15) From: Eric McCorkle Subject: Re: EFI GELI support ready for testers Date: Sun, 29 May 2016 10:10:16 -0400 To: Konstantin Belousov X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2016 14:10:24 -0000 > On May 29, 2016, at 05:18, Konstantin Belousov wrote= : >=20 >> On Sat, May 28, 2016 at 04:02:43PM -0400, Eric McCorkle wrote: >>=20 >>>> On May 28, 2016, at 13:26, Konstantin Belousov wr= ote: >>>>=20 >>>>> On Sat, May 28, 2016 at 10:27:40AM -0400, Allan Jude wrote: >>>>>> On 2016-05-28 04:36, Konstantin Belousov wrote: >>>>>> On Fri, May 27, 2016 at 07:39:57PM -0400, Eric McCorkle wrote: >>>>>> I am pleased to announce that my work to add support for GELI in the E= FI boot loader (as well as perform more general refactoring) is now ready fo= r testing. I am able to successfully detect multiple GELI partitions in boo= t1 and pass the keys into the kernel. >>>>>=20 >>>>> Can somebody explain in which way this is useful ? >>>>> Same question for the GELI code for non-EFI loader. >>>>>=20 >>>>> BIOS cannot read raw data from the encrypted partition, so you need >>>>> either old boot or the loader and some additional data on EFI boot >>>>> partition anyway. >>>>>=20 >>>>> Features adds significant amount of code, which must be maintained in >>>>> parallel with the kernel code. >>>>> _______________________________________________ >>>>> 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 >>>> The motivation for my work (GELI in boot2 and loader for non-EFI boot) >>>> was supporting ZFS boot environments. Previously, when you use GELI you= >>>> needed to have two ZFS pools, one for an unencrypted /boot and one for >>>> the encrypted / >>>>=20 >>>> This breaks ZFS boot environments, since a snapshot of the root file >>>> system won't include the correct kernel etc. >>> Why cannot /boot included into the boot environment ? >>> When I last saw Solaris, somewhere in its 10-th, any amount of >>> filesystems could be added to the bootenv. But whatever the definition >>> of bootenv is used, it exists at a level of the shell scripts and select= ing >>> the actual partition for loader. Throw thousand lines of code into >>> the unstable and very hard to debug environment of loader looks somewhat= >>> unproductive. >>=20 >> You misunderstand. Alan was talking about pure ZFS systems, where there i= s one big ZFS pool holding everything. You need to be able to access /boot o= bviously, but ZFS does not allow you to assign separate out data on to a sin= gle device. It creates a pool, which combines all devices. >>=20 >> To have /boot unencrypted, you have to have a separate partition for just= /boot, which is undesirable. > Why it is undesirable ? You must have EFI boot partition by any means. >=20 > And why it is simultaneously desirable to add a bunch of code to loader > to hide this ? >=20 It's undesirable because the whole point of ZFS is to have one ZFS volume fo= r the whole system. The ESP is a minor annoyance that's unavoidable. But h= aving to have a UFS volume or two ZFS systems just so I can keep the kernel,= loader, and all the modules unencrypted is bad. >>=20 >>>>=20 >>>> The final version of my geliboot took an extra effort to reuse the AES >>>> code from sys/crypto/rijndael and sys/opencrypto and GELI directly from= >>>> sys/geom/eli to avoid maintaining a separate copy of that code in sys/b= oot >>> Which means that kernel code must be also runnable in the strange and >>> incompatible environment of the loader. I cannot see how this reduces >>> code maintanability even a bit. I am already rather unhappy about ZFS >>> kernel code being compiled as the userspace library, which hurt me >>> and other people more than once. Now (?) the kernel code must be also >>> verified for the loader. >>=20 >> I mean, the loader has to be able to access the filesystems, there's no w= ay around it (barring crazy coreboot stuff). >>=20 >> Also, it should be possible to create a synthetic EFI test-harness that r= uns in *userland*. EFI is basically just a bunch of tables of function point= ers, no bios interrupts or anything. As long as you implement the interface= s, any loader should also run in your synthetic environment. I had plans to= look into this after this work is done. > Of course EFI is not 'just a bunch of tables'. It might look so when you > have tunnel vision and all you do is writing code making calls, but it > is definitely not when you consider it as a part of platform. =46rom the standpoint of building a synthetic test environment to make it ea= sy to test and debug boot and loader code, it is. > UEFI makes it absurdly easy to distribute a code that gets executed on > every boot before boot loaders. The most straighforward is to put UEFI > driver binary into the UEFI FAT and register it into some variables (too > lazy to remember details). You get this way both boot- and runtime- > injection, officially supported. This was one of the reason for secure > boot. >=20 > To avoid trivial debunks, I put a note that of course drivers are not > the only way for such code to appear on the system, without > requiring any hardware modifications. The rich programming environment, > with flat memory and full control over hardware, with easily explorable > data structures, with documented and compatible ways to get code > persistent are the characteristics of it. >=20 > It is much easier to target such preboot env then to maintain dynamic > list of the userspace escalation code. Ok fine. But this is a risk anyone using EFI has to assume, and it doesn't e= nd at the boot environment. There are plenty of nasty tricks an EFI boot en= vironment can play that affect the OS as well. It's simply impossible for a= n OS to provide reliable security when the hardware or firmware is compromis= ed, and this isn't limited to the boot loader. This kind of thing is the reason for projects like coreboot gaining traction= . If you really don't trust EFI, then the right answer is to use something l= ike coreboot, or else don't use a system with EFI. Trying to compensate for= this by keeping stuff out of the boot loader (and exposing vital parts of y= our system in a powered-off state) is futile, as a determined attacker can j= ust set things up to compromise the kernel anyway. >=20 >>>>=20 >>>> Hopefully the work I did to make sys/opencrypto and sys/geom/eli more >>>> reusable outside of the kernel will make it easier for Eric to do the >>>> same for the EFI version. >>>>=20 >>>> The motivation for the EFI version is the same, ZFS boot environments, >>>> plus the obvious security advantages of having the kernel stored >>>> encrypted rather than not. >>>=20 >>> Obvious security advantages ? Seriously ? >>> What is a single 'security' advantage of hiding the kernel ? >>=20 >> There are plenty. >>=20 >> Right up at the top, an attacker able to access /boot is free to tamper w= ith anything, and can insert back-doors into the kernel, loader, or any modu= le. If you assume that the attacker can't write, then they can still scan t= he kernel and modules for signatures for known vulnerabilities (since the ke= rnel itself has a commit id and detailed version info, they can compare this= against a CVE database). Even if they can't do that for some reason, they c= ould still potentially exfilt a kernel address map for use in rootkit attack= s against your system. Lastly, general security principles say to minimize t= he attack surface, which would definitely mean you should protect the core o= f the system. > I cannot believe that somebody considers hiding kernel binary even > remotely viable 'security' measure. But let me accompany that for a > second and see what attack surface does the attacker get from knowing > the kernel binary ? What you completely ignore in all this is the capability for an attacker to t= amper with the unencrypted kernel, loader, and drivers. > =46rom inspecting quirks in the syscalls it is (almost trivially) easy > to reconstruct the date of kernel sources up to probably month, without > causing much observable havoc in the system. The kern.osreldate is around= > as well, not only as sysctl, but also having some impact on the runtime > behaviour of several syscalls and image activators. >=20 > Same fingerprints are available from the sizes of the objects in UMA > zones, readily available from vmstat -z. Changes in the basic kernel > structures layout are reflected in the size changes. >=20 > Facilities like procstat -kk would show code reorganization and refactorin= g > changes. >=20 > The list above was written after about 10 minutes spent on thinking how > to identify the system sources without having access to binaries. I > believe another 10 minutes would give even more suggestions. This is all academic. Yes, maybe someone can piece together what version of= things I'm running. Of course, they'd have no idea what my address map loo= ks like, unless they can get my compiler version and custom kernel config. M= aybe there's some way to do that too. But they get all of this with 100% accuracy by scanning the unencrypted boot= partition, AND they can tamper with any of it. It's *just* less secure, pl= ain and simple. >=20 >=20 >>> Since you noted a 'security', I realized that your changes decrypt the >>> keys in the pre-kernel environment. In other words, very sensitive >>> material becoming accessible to strange and unknown code which is >>> managed by firmware. >>=20 >> The likelihood of such an attack, while something I considered, is very l= ow. A key should look like random binary data (much like the GUIDs prevalen= t in EFI code). I seriously doubt someone could write a firmware module tha= t could dig through the memory state of an arbitrary OS's boot loader and fi= nd keys. You'd basically have to put a full online binary analysis framewor= k in the firmware, and have it run fast enough to not be noticed. That woul= d be some serious Turing award-worthy work kept secret from the world solely= to build firmware backdoors. I don't think even Lenovo would go that far. >>=20 >> (I know I mentioned scanning the kernel as a threat above; that's an offl= ine attack that can be done on a copy. Online undetectable analysis of a ru= nning program is WAY harder.) > Nobody would scan for random data looking like keys. If attacker is > interested in keys from the freebsd loader or password decrypting the > keys, the address of the memory region where the material is stored and > region' layout are immediately available for any code collocated in the > common address space. No, they don't necessarily know the memory location at all. The keys are st= ored either in static variables (i.e. no symbol to tell you where it is), st= ack frames, or malloc data structures (and the static variable ones can be m= oved if it's REALLY a concern). Plus you've got other operating systems with their own full disk encryption m= ethods, as well as every revision of the FreeBSD boot loader. Unless you're specifically targeting an individual for attack (in which case= , going by your proposal, I could just tamper with their unencrypted kernel,= so why would I bother with EFI tricks), you'd have to have either a huge nu= mber of profiles for every version of every OS boot loader, or you'd have to= have some kind of analysis framework. > The hooks into the interfaces and pre-recorded sequence of calls for > the initialization of loader give unique execution profile which allow > to determine the password and key storage location. And this changes on every platform, with every revision, and is wildly diffe= rent for other OSes. Moreover, this sort of attack is in no way unique to G= ELI, and could just as easily be used to insert a backdoor into a kernel, or= anything else. > Exact attack scenario is not the point I am trying to make. Instead, I > point out that UEFI execution environment is shared one, with no walls > between software components from arbitrary sources. It is absolutely > unsuitable for exposing sensitive material. Even more laughtable to > simultaneosly hide kernel binary. >=20 > In contrast with the kernel environment, which even with ME/BMC/ACPI/UEFI > runtime components, is less penetrable by trying to own the execution > state of the machine. I see no reason why. Sure, it's bigger, but any method that could recover a= key from a boot loader should also work on a kernel. These sorts of things= have been demonstrated all the time in conference presentations, academic p= ublications, and other venues. >=20 >> Besides, if someone wants to do evil things in firmware, I think it's far= more likely they'd just backdoor the network or USB controllers to let some= one send an override packet and execute bundled code in kernel mode. That w= orks every time for every OS and doesn't require surreptitiously picking apa= rt arbitrary programs' data structures in real time. > Of course backdoring hardware is order of magnitude harder and requires > physical access to the machine. The realistic action by level of script > kiddie is getting UEFI driver installed. It seems you're considering only one kind of attacker, and specifically not t= he kind that are relevant to disk encryption. The whole point of disk encryption IS to deal with people who have varying l= evels of physical access to your machine. By definition, the script kiddie o= f which you speak would be running their attacks when the encrypted partitio= ns are all attached. So they'd have access to all the data anyway. The sam= e holds for a more sophisticated attacker. Why would they bother with a fan= cy EFI malware when they already have access to all the data anyway. I'll admit there may be some kind of persistent threat scenario where someon= e plants EFI malware to sniff keys at a later date, but this seems extraordi= nary rare. By contrast, data protection is a real thing: many organizations= have requirements for full disk encryption, and there are people in the wor= ld who have to deal with getting harassed and having their computers seized a= nd searched. > To close this branch, backdored busmasters (but not ME) are > trivially mitigated by enabling IOMMU, FWIW. >=20 >> For what it's worth, I have considered possible hardening measures: using= alias GUIDs to disguise interfaces and adding per-build padding or XOR mask= s to structures with keys to throw off scanners. However, I don't think the= threat is realistic enough to warrant such measures. > I do not see a way to comment about the measures, without adding > the word 'theatre'. Right, which is why I decided they aren't worth it. >=20 >>> Putting aside ineradicable evil of Intel ME or its >>> AMD twin, and SMM handler, you are exposing keys to whatever code happen= >>> to inhabit the preboot env, not neccessary originating from the firmware= >>> vendor. Secure Boot would not help there, since when the measurement >>> indicate that untrusted component was there, it is too late. I.e., >>> you making much easier for malice hacker to steal the keys. >>=20 >> I mean, the same argument holds for the kernel, if not moreso. You have A= CPI bytecode, SMM, device blobs, anything that the boot environment chose to= keep around for runtime by marking that memory as "unavailable", and of cou= rse, the evil that is Intel ME. This is an unavoidable risk of having keys i= n main memory ever. > See above. >=20 >> If you really want any kind of safety from this, you need to use a hardwa= re crypto device that stores keys in a separate memory (which, I specificall= y designed things to make it easy to add support for one). Of course, you t= hen have to trust the device... >=20 > No, what I want is avoiding bad choices which are seemingly made just > because code can be written. Code exposing sensitive material is written > for very weak and leaking environment, at least without secure boot > turned on. Arguments supporting that decision reference 'security' by > e.g. hiding kernel binary, and undesire to have /boot partition. Please > take a step outside and see bigger picture. I'd say the same to you... You are only considering one kind of scenario. Alan's and my work is aimed a= t protecting systems from attackers that have some level of physical access t= o the machines. There are people in the world who have to contend with this= sort of thing, and the major competing OSes (Apple, Linux, MS, etc) all hav= e their own full-disk encryption solutions. Moreover, my work is aimed at tamper-resilience at the OS level. Yes, I kno= w OS tamper-resistance can be undermined without trusted firmware, but we ar= e seeing projects like coreboot and others working toward that end. Moreove= r, these kinds of efforts are themselves pointless when the OS does things l= ike leaving the most sensitive part of the system wide open to tampering. Speaking personally, I would like to see a system where I have full disk enc= ryption combined with EFI secure boot with a unique platform key stored on m= y encrypted disk. Having an unencrypted boot partition in such a system just= opens up more attacks, plain an simple. (I would also like to see an open s= ource firmware and no ME, but that's out of scope here) Finally, it's not like Alan's and my work *forces* anyone to use GELI. If y= ou are really worried about some scenario where an attacker doesn't have phy= sical access and needs to backdoor the firmware to sniff keys so they can ac= cess data they can't see despite being able to write to firmware, then fine,= don't use GELI at boot. Better yet, use the compile flag to remove it from= boot1 and loader completely. But if you want full disk encryption, you hav= e the option of having it.= From owner-freebsd-hackers@freebsd.org Sun May 29 19:16:17 2016 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 41F09B532D1 for ; Sun, 29 May 2016 19:16:17 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 331B2169B; Sun, 29 May 2016 19:16:17 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by freefall.freebsd.org (Postfix) with ESMTP id E8BA7199D; Sun, 29 May 2016 19:16:16 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Sun, 29 May 2016 19:16:14 +0000 From: Glen Barber To: Allan Jude Cc: freebsd-hackers@freebsd.org Subject: Re: contributing to open source Message-ID: <20160529191614.GC80759@FreeBSD.org> References: <53164a51-5389-7ca5-b40f-d58902fffe87@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Fig2xvG2VGoz8o/s" Content-Disposition: inline In-Reply-To: <53164a51-5389-7ca5-b40f-d58902fffe87@freebsd.org> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2016 19:16:17 -0000 --Fig2xvG2VGoz8o/s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 27, 2016 at 11:37:01PM -0400, Allan Jude wrote: > On 2016-05-27 23:30, Kefeh Collins wrote: > > hello > > please i need help installing freebsd using the virtual box > > actually am at my concluding phase but the problem is i downloaded = a VM > > image with the .vhd.xz as well as the .raw.xz extensions > > but i cant unzip it and i cant locate it when choosing a virtual > > optical disk file > > any help is very much appreciated > >=20 > > On Sun, May 22, 2016 at 1:40 PM, Kefeh Collins > > wrote: > >=20 > >> hello > >> i am a second year computer science student, program in c and c++ and= am > >> interested in contributing in operating system (kernel) directed proje= cts > >> please i need guidance > >> > >> thanks in advance > >> >=20 > To unzip it, type: > unxz imagename.vhd.xz >=20 > Then you will have a .vhd file and be able to use it normally. >=20 > .vhd files are for Microsoft HyperV, so it is likely not the image you > want. VirtualBox and VMware uses the .vmdk file >=20 VirtualBox should recognize the VHD format just fine. The only formats I am aware do not work with VirtualBox are the '.raw' and '.qcow2' (and I think the '.qcow2' do work somewhat recently). Just a "FWIW" statement. I actually haven't checked if the raw format works in a while, so it is possible it may work now. Glen --Fig2xvG2VGoz8o/s Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXSz/+AAoJEAMUWKVHj+KTvxwP/inmJ00Ve7W9mb8Acn29sJk0 Ym1BwwBybpAai0vaM1Z0Na/UyjKLIOUWJBPkEpVdGNIF1v13QGNNRbDvLZaVZFTj sALB/aBhM9FqY7QLhHIC310M4C+ClZ/3L0Lnda0EknkqIE+TDF6g60obqk1XVWX7 N58r4us9tPfXUCVuA+rlBTcJ+IbJkPMG/8KLc/J6HDPLmdY6Ac7Y+6xAnTsnwf5J AVjF0wVGNEftLqfoKI/NANhyOj8mcvygrgLfB4bSnJR6tPLURBP/L2BqND2KmH9/ VUbpgSY2rVgHQDeVMjQ4z/2BnVguWfru0CVZtpfGBiirKaAayG0zpV2AzP97ytgF fm4tnC4N8ZArXVXtylmKGKpHO6dnzUoWLbBNC2lxBWMid0OAfPAUvLHw/sZWTS+D KHKM7iMeT853e087M7+MB4vCxFb49rV+MS3nhrkfZTMhawTH4uykj8kx/7rkk1Gy AHv7llk56vE+ZCUs1Iwp9ZJmGTtw6fhwba0FCDMRX5htTmFA6HBEJlK6hmfwvrot DrT+McMZIDZZ7dhirWTuXaguCGKTbUT5YXeSriwTNn8Aogj3+bFTwIDfs1Je20o6 ZS4IqqBFmdRnh6DrYjgThIq6vHXzJfJQxEzGc888FQQLfkaSj4pOq5EiOhnhJ/Ua 2al21VrTX3eoTCgLD9eW =R5CP -----END PGP SIGNATURE----- --Fig2xvG2VGoz8o/s-- From owner-freebsd-hackers@freebsd.org Sun May 29 23:21:01 2016 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 CD04CB541D3 for ; Sun, 29 May 2016 23:21:01 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7300F16A3; Sun, 29 May 2016 23:21:01 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.15.2/8.15.2) with ESMTPS id u4TNKxug099439 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 29 May 2016 17:20:59 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.15.2/8.15.2/Submit) with ESMTP id u4TNKxP9099436; Sun, 29 May 2016 17:20:59 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sun, 29 May 2016 17:20:59 -0600 (MDT) From: Warren Block To: Glen Barber cc: Allan Jude , freebsd-hackers@freebsd.org Subject: Re: contributing to open source In-Reply-To: <20160529191614.GC80759@FreeBSD.org> Message-ID: References: <53164a51-5389-7ca5-b40f-d58902fffe87@freebsd.org> <20160529191614.GC80759@FreeBSD.org> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Sun, 29 May 2016 17:20:59 -0600 (MDT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2016 23:21:01 -0000 On Sun, 29 May 2016, Glen Barber wrote: > On Fri, May 27, 2016 at 11:37:01PM -0400, Allan Jude wrote: >> On 2016-05-27 23:30, Kefeh Collins wrote: >>> hello >>> please i need help installing freebsd using the virtual box >>> actually am at my concluding phase but the problem is i downloaded a VM >>> image with the .vhd.xz as well as the .raw.xz extensions >>> but i cant unzip it and i cant locate it when choosing a virtual >>> optical disk file >>> any help is very much appreciated >>> >>> On Sun, May 22, 2016 at 1:40 PM, Kefeh Collins >>> wrote: >>> >>>> hello >>>> i am a second year computer science student, program in c and c++ and am >>>> interested in contributing in operating system (kernel) directed projects >>>> please i need guidance >>>> >>>> thanks in advance >>>> >> >> To unzip it, type: >> unxz imagename.vhd.xz >> >> Then you will have a .vhd file and be able to use it normally. >> >> .vhd files are for Microsoft HyperV, so it is likely not the image you >> want. VirtualBox and VMware uses the .vmdk file >> > > VirtualBox should recognize the VHD format just fine. > > The only formats I am aware do not work with VirtualBox are the '.raw' > and '.qcow2' (and I think the '.qcow2' do work somewhat recently). Just > a "FWIW" statement. > > I actually haven't checked if the raw format works in a while, so it is > possible it may work now. Raw images can be converted to other formats with VBoxManage. The parameters are not the most obvious: https://www.virtualbox.org/manual/ch08.html#idp46691721399456 From owner-freebsd-hackers@freebsd.org Sun May 29 23:24:25 2016 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 38D3EB54270 for ; Sun, 29 May 2016 23:24:25 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 1F06D19AE; Sun, 29 May 2016 23:24:25 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by freefall.freebsd.org (Postfix) with ESMTP id C955C1335; Sun, 29 May 2016 23:24:24 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Sun, 29 May 2016 23:24:23 +0000 From: Glen Barber To: Warren Block Cc: Allan Jude , freebsd-hackers@freebsd.org Subject: Re: contributing to open source Message-ID: <20160529232423.GK80759@FreeBSD.org> References: <53164a51-5389-7ca5-b40f-d58902fffe87@freebsd.org> <20160529191614.GC80759@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="OX2aLCKeO1apYW07" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2016 23:24:25 -0000 --OX2aLCKeO1apYW07 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, May 29, 2016 at 05:20:59PM -0600, Warren Block wrote: > On Sun, 29 May 2016, Glen Barber wrote: >=20 > >On Fri, May 27, 2016 at 11:37:01PM -0400, Allan Jude wrote: > >>On 2016-05-27 23:30, Kefeh Collins wrote: > >>>hello > >>> please i need help installing freebsd using the virtual box > >>> actually am at my concluding phase but the problem is i downloaded= a VM > >>>image with the .vhd.xz as well as the .raw.xz extensions > >>> but i cant unzip it and i cant locate it when choosing a virtual > >>>optical disk file > >>>any help is very much appreciated > >>> > >>>On Sun, May 22, 2016 at 1:40 PM, Kefeh Collins > >>>wrote: > >>> > >>>>hello > >>>> i am a second year computer science student, program in c and c++ an= d am > >>>>interested in contributing in operating system (kernel) directed proj= ects > >>>>please i need guidance > >>>> > >>>>thanks in advance > >>>> > >> > >>To unzip it, type: > >>unxz imagename.vhd.xz > >> > >>Then you will have a .vhd file and be able to use it normally. > >> > >>.vhd files are for Microsoft HyperV, so it is likely not the image you > >>want. VirtualBox and VMware uses the .vmdk file > >> > > > >VirtualBox should recognize the VHD format just fine. > > > >The only formats I am aware do not work with VirtualBox are the '.raw' > >and '.qcow2' (and I think the '.qcow2' do work somewhat recently). Just > >a "FWIW" statement. > > > >I actually haven't checked if the raw format works in a while, so it is > >possible it may work now. >=20 > Raw images can be converted to other formats with VBoxManage. The > parameters are not the most obvious: > https://www.virtualbox.org/manual/ch08.html#idp46691721399456 >=20 Ah, right. Thanks for that, I had forgotten about it since Marcel's mkimg(1) tool supported various output formats. Glen --OX2aLCKeO1apYW07 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXS3onAAoJEAMUWKVHj+KTbyAP/iyeR1Z7OE3HgI5vNF2vBnCV GxRQVJJ2ASoUzv3yatfMhbuYlYYZSt5JhI0Y79oUYNlj4bC4QCmk6PtWqInOsHds gP7lfbsSYsBOa+80aaIUO4+0XIKFXFtst7Ar3CDOf1eqxLvaDiofA/UtTBmZRM9H wqvy4mSS+VDXAnVjo+QHgNrXm45DgwFiD4Br9SvP/EAb2RhB8MMzrJoOin/5paVB WyMzIvyuK+/00A9dQlH5JZztw+CZ+XlwqDr2kVo81UJxlhaOKk42Gc4uI2fvmqd7 Q7453Rg4PFaS+cKfmF+RkuHsugqnyHbT19Z4KWVV4tQwM23rAgqzPyRPcuN58HMR BN41KTddOBfb2mfU4Ov4UB24b7pp1vbf8kQFvkyca5jMwcje912wrKcD761K+s0f psqUhMFlXd9EVgRvJRaKgR2M8+7QSO94PJ3+3e5qj/lLGWITG9y85mpq+nG7Rm0Q o8OVvVJdtCOH0KmGrDpmspvA2mawqIPNn2f0aNkPep2uzS9yWtiWR2IyHbPcyYGk 0BrmfbEKq01X8/tXcGVFPwxTcKnkejBx4F77AH76j/y0UQCncdWiK6FSrz+swh1b JqYOp0Yj1EU+pYM4CedUgd0gqZpz7+GyHSZAeB2NnmVbDb+JGD/UqOmrARYPXpSd 7941/yVm2tsxPyU9iNbz =GiCy -----END PGP SIGNATURE----- --OX2aLCKeO1apYW07-- From owner-freebsd-hackers@freebsd.org Sun May 29 23:49:17 2016 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 F176DB5458D for ; Sun, 29 May 2016 23:49:17 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C110A1103; Sun, 29 May 2016 23:49:17 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.15.2/8.15.2) with ESMTPS id u4TNnGjK006775 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 29 May 2016 17:49:16 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.15.2/8.15.2/Submit) with ESMTP id u4TNnG4Z006772; Sun, 29 May 2016 17:49:16 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sun, 29 May 2016 17:49:16 -0600 (MDT) From: Warren Block To: Glen Barber cc: Allan Jude , freebsd-hackers@freebsd.org Subject: Re: contributing to open source In-Reply-To: <20160529232423.GK80759@FreeBSD.org> Message-ID: References: <53164a51-5389-7ca5-b40f-d58902fffe87@freebsd.org> <20160529191614.GC80759@FreeBSD.org> <20160529232423.GK80759@FreeBSD.org> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Sun, 29 May 2016 17:49:16 -0600 (MDT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2016 23:49:18 -0000 On Sun, 29 May 2016, Glen Barber wrote: >>> VirtualBox should recognize the VHD format just fine. >>> >>> The only formats I am aware do not work with VirtualBox are the '.raw' >>> and '.qcow2' (and I think the '.qcow2' do work somewhat recently). Just >>> a "FWIW" statement. >>> >>> I actually haven't checked if the raw format works in a while, so it is >>> possible it may work now. >> >> Raw images can be converted to other formats with VBoxManage. The >> parameters are not the most obvious: >> https://www.virtualbox.org/manual/ch08.html#idp46691721399456 >> > > Ah, right. Thanks for that, I had forgotten about it since Marcel's > mkimg(1) tool supported various output formats. For completeness: It is possible to use VBoxManage to attach a physical drive directly to a VM. I forget the details on doing it, but it can be done. It is also possible to set up a raw image file as a virtual drive with iSCSI. I've been meaning to write that up, but... have not. It involves VBoxManage storageattach and --medium iscsi. From owner-freebsd-hackers@freebsd.org Tue May 31 12:04:29 2016 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 4D1BEB5409B for ; Tue, 31 May 2016 12:04:29 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EB30E1EAB; Tue, 31 May 2016 12:04:28 +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 u4VC4Lcx086698 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 31 May 2016 15:04:21 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u4VC4Lcx086698 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u4VC4IXk086697; Tue, 31 May 2016 15:04:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 31 May 2016 15:04:18 +0300 From: Konstantin Belousov To: Eric McCorkle Cc: Allan Jude , freebsd-hackers@freebsd.org Subject: Re: EFI GELI support ready for testers Message-ID: <20160531120418.GF38613@kib.kiev.ua> References: <519CC1FC-84DF-4710-8E62-AF26D8AED2CF@metricspace.net> <20160528083656.GT38613@kib.kiev.ua> <20160528172618.GB38613@kib.kiev.ua> <6A9DADE0-B214-424A-BB14-0B0848F0D08D@metricspace.net> <20160529091827.GD38613@kib.kiev.ua> <46B3F9E2-A25B-4F9D-B35F-11AC782495B1@metricspace.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46B3F9E2-A25B-4F9D-B35F-11AC782495B1@metricspace.net> User-Agent: Mutt/1.6.1 (2016-04-27) 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.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 12:04:29 -0000 On Sun, May 29, 2016 at 10:10:16AM -0400, Eric McCorkle wrote: > > Ok fine. But this is a risk anyone using EFI has to assume, and it doesn't end at the boot environment. There are plenty of nasty tricks an EFI boot environment can play that affect the OS as well. It's simply impossible for an OS to provide reliable security when the hardware or firmware is compromised, and this isn't limited to the boot loader. > This statement, althought looking true, does not account for difference in the level of efforts required to target the corresponding environment. > This kind of thing is the reason for projects like coreboot gaining traction. If you really don't trust EFI, then the right answer is to use something like coreboot, or else don't use a system with EFI. Trying to compensate for this by keeping stuff out of the boot loader (and exposing vital parts of your system in a powered-off state) is futile, as a determined attacker can just set things up to compromise the kernel anyway. > No, you do not understand, or went into the protective mode where the broad statements should cover the place. I am fine with the security implications of the UEFI environment activating the kernel. I am not fine with exposing the sensitive material to UEFI boot. Same from the classic BIOS. > What you completely ignore in all this is the capability for an attacker to tamper with the unencrypted kernel, loader, and drivers. At which point would the attacker tamper ? Immediately after your GELI UEFI code provides him with the keys to do so ? > This is all academic. Yes, maybe someone can piece together what version of things I'm running. Of course, they'd have no idea what my address map looks like, unless they can get my compiler version and custom kernel config. Maybe there's some way to do that too. > > But they get all of this with 100% accuracy by scanning the unencrypted boot partition, AND they can tamper with any of it. It's *just* less secure, plain and simple. > Ok, another 'security' theatre. Let me restate the question I aked in my first mail, but now after having the discussion rolled forward. Is there any other 'security' benefit from having /boot encrypted, other than obscuring the kernel binary ? > You are only considering one kind of scenario. Alan's and my work is aimed at protecting systems from attackers that have some level of physical access to the machines. There are people in the world who have to contend with this sort of thing, and the major competing OSes (Apple, Linux, MS, etc) all have their own full-disk encryption solutions. > > Moreover, my work is aimed at tamper-resilience at the OS level. Yes, I know OS tamper-resistance can be undermined without trusted firmware, but we are seeing projects like coreboot and others working toward that end. Moreover, these kinds of efforts are themselves pointless when the OS does things like leaving the most sensitive part of the system wide open to tampering. > > Speaking personally, I would like to see a system where I have full disk encryption combined with EFI secure boot with a unique platform key stored on my encrypted disk. Having an unencrypted boot partition in such a system just opens up more attacks, plain an simple. (I would also like to see an open source firmware and no ME, but that's out of scope here) What you describe makes even less sense. If secure boot is in action, then kernel binary should be measured and its fingerprints compared with the protected records in TPM. Then all the layers that you add are useless. > > Finally, it's not like Alan's and my work *forces* anyone to use GELI. If you are really worried about some scenario where an attacker doesn't have physical access and needs to backdoor the firmware to sniff keys so they can access data they can't see despite being able to write to firmware, then fine, don't use GELI at boot. Better yet, use the compile flag to remove it from boot1 and loader completely. But if you want full disk encryption, you have the option of having it. It forces us to maintain that code. It pulls large amount of code into environment that is hard to debug in the comfortable local setup, and is absolutely impossible to inspect and diagnose in the wild, where the problems occur on the user machine. All that cost for the only 'security' provided not exposing the kernel binary. From owner-freebsd-hackers@freebsd.org Wed Jun 1 04:22:11 2016 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 DDFC9B58A41 for ; Wed, 1 Jun 2016 04:22: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 B1B681393; Wed, 1 Jun 2016 04:22:11 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:8fe:6a13:797b:e9c9] (unknown [IPv6:2001:470:1f11:617:8fe:6a13:797b:e9c9]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 2F6651DDD; Wed, 1 Jun 2016 04:22:11 +0000 (UTC) References: <519CC1FC-84DF-4710-8E62-AF26D8AED2CF@metricspace.net> <20160528083656.GT38613@kib.kiev.ua> <20160528172618.GB38613@kib.kiev.ua> <6A9DADE0-B214-424A-BB14-0B0848F0D08D@metricspace.net> <20160529091827.GD38613@kib.kiev.ua> <46B3F9E2-A25B-4F9D-B35F-11AC782495B1@metricspace.net> <20160531120418.GF38613@kib.kiev.ua> Mime-Version: 1.0 (1.0) In-Reply-To: <20160531120418.GF38613@kib.kiev.ua> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Cc: freebsd-hackers@freebsd.org, Allan Jude X-Mailer: iPad Mail (13D15) From: Eric McCorkle Subject: Re: EFI GELI support ready for testers Date: Wed, 1 Jun 2016 00:22:10 -0400 To: Konstantin Belousov X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 04:22:12 -0000 > On May 31, 2016, at 08:04, Konstantin Belousov wrote= : >=20 >> On Sun, May 29, 2016 at 10:10:16AM -0400, Eric McCorkle wrote: >>=20 >> Ok fine. But this is a risk anyone using EFI has to assume, and it doesn= 't end at the boot environment. There are plenty of nasty tricks an EFI boo= t environment can play that affect the OS as well. It's simply impossible f= or an OS to provide reliable security when the hardware or firmware is compr= omised, and this isn't limited to the boot loader. >>=20 > This statement, althought looking true, does not account for difference > in the level of efforts required to target the corresponding environment. It is not any more difficult; BIOS/EFI based exploits against kernels /alrea= dy exist/, have been demoed in multiple forums, and have been discovered in t= he wild. As a PoC, a simple kernel exploit might like this: 1) replace bios disk read/EFI block read with malware that tracks contiguous= sections of memory written by disk reads. 2) look for ELF headers in any such sections 3) store runtime malware in a memory section disguised in the memory map as a= n option rom or something similar 4) insert a trap similar to what debuggers do at the start point of any elf f= ile you detect, have the traps jump into the runtime malware 5) once you trap into the runtime malware, you have them. If you just want G= ELI keys, I'd say drop another debugging-style trap in geli_taste, but the p= ossibilities are really endless (just deploy your favorite rootkit) But the fact is, you can find this kind of thing on the dark web today (or r= eferenced in leaked documents, or just go to DefCon or some other venue). S= omeone would have to actively sit down and write malware to sniff GELI keys i= n the boot loader, where they can just use what already exists if they want t= o back-door the kernel. >> What you completely ignore in all this is the capability for an attacker t= o tamper with the unencrypted kernel, loader, and drivers. >=20 > At which point would the attacker tamper ? Immediately after your > GELI UEFI code provides him with the keys to do so ? No this attack is *offline*. I'm going to break down all the major attack s= cenarios here, because you don't seem to get what I'm talking about. 1) Attacker has physical access, tampers with machine while offline, possess= es ability to tamper with all hardware. This is mentioned only for complete= ness. You're helpless with or without full disk encryption, as they just pu= t a hardware keylogger in place (or anything else, really). A variation on t= his is the malevolent bios/EFI code scenario, in which they just deploy an a= lready existing rootkit on you. 2) Attacker has physical access, tampers with machine while offline, only po= ssesses ability to tamper with disk. Without full-disk encryption, they ins= ert malware into the unprotected kernel, loader, or modules. They cannot do= this with full-disk encryption, as they can't read the contents of /boot at= all. 3) Attacker seizes/steals machine while offline. With or without full-disk e= ncryption, there is no way to obtain most of the data. There is an informat= ion leak from examining unencrypted drivers, configs, and the kernel. This d= oesn't compromise this specific machine, as we assume we will never regain t= he machine. However, the attacker can potentially learn something about how= we configure machines. In the worst case, they discover something that cou= ld be used to attack other machines (unpatched CVE, etc). Some organization= s and people *do* consider this worth protecting against. 4) Attacker seizes/steals machine while online. Again, this is for complete= ness sake. They get all the data in either case. 5) Attacker accesses machine remotely while online, gains sufficient privile= ges to tamper with filesystems and disks. Total disclosure in either case. = They just steal the data directly, or tamper with loader/kernel if they *re= ally* want the keys. 6) Same as #5, but they are also able to flash firmware. No difference. Th= ey may actually mess with the firmware if they're mean or if they're doing s= ome kind of persistent penetration, but in all likelihood they just steal th= e data or backdoor loader and kernel again. Takeaway: there's no scenario where an attacker would be able to sniff GELI k= eys in the boot loader that they can't already get the keys today (or do wor= se), therefore, they gain no significant advantage from GELI keys being pres= ent at boot time. By contrast, a backdoor is defeated in scenario #2 and an= information leak is defeated in scenario #3, meaning full disk encryption *= does* provide an advantage. > Let me restate the question I aked in my first mail, but now after > having the discussion rolled forward. Is there any other 'security' > benefit from having /boot encrypted, other than obscuring the kernel > binary ? I will say that it denies them the ability to tamper with it offline, since y= ou have not yet acknowledged that case yourself. Aside from denying attackers the ability to read *and tamper with* the kerne= l, loader, modules, possible configurations, and other data given offline ac= cess to the machine, no there isn't any other advantage I can think of. >> You are only considering one kind of scenario. Alan's and my work is aim= ed at protecting systems from attackers that have some level of physical acc= ess to the machines. There are people in the world who have to contend with= this sort of thing, and the major competing OSes (Apple, Linux, MS, etc) al= l have their own full-disk encryption solutions. >>=20 >> Moreover, my work is aimed at tamper-resilience at the OS level. Yes, I k= now OS tamper-resistance can be undermined without trusted firmware, but we a= re seeing projects like coreboot and others working toward that end. Moreov= er, these kinds of efforts are themselves pointless when the OS does things l= ike leaving the most sensitive part of the system wide open to tampering. >>=20 >> Speaking personally, I would like to see a system where I have full disk e= ncryption combined with EFI secure boot with a unique platform key stored on= my encrypted disk. Having an unencrypted boot partition in such a system ju= st opens up more attacks, plain an simple. (I would also like to see an ope= n source firmware and no ME, but that's out of scope here) >=20 > What you describe makes even less sense. If secure boot is in action, > then kernel binary should be measured and its fingerprints compared with > the protected records in TPM. Then all the layers that you add are > useless. There is still the information disclosure. Also, some people don't have har= dware supporting secure boot. >=20 >>=20 >> Finally, it's not like Alan's and my work *forces* anyone to use GELI. I= f you are really worried about some scenario where an attacker doesn't have p= hysical access and needs to backdoor the firmware to sniff keys so they can a= ccess data they can't see despite being able to write to firmware, then fine= , don't use GELI at boot. Better yet, use the compile flag to remove it fro= m boot1 and loader completely. But if you want full disk encryption, you ha= ve the option of having it. >=20 > It forces us to maintain that code. It pulls large amount of code into > environment that is hard to debug in the comfortable local setup, and is > absolutely impossible to inspect and diagnose in the wild, where the > problems occur on the user machine. That is a legitimate concern, though I think it's way overblown here. The G= ELI code in the boot loader is simply not that complicated, nor is it that l= arge. It's mostly calling some crypto functions and reading some metadata. = As for my changeset, the majority of it is just EFI boilerplate to implemen= t various protocol interfaces (EFI is a rather tedious framework in some way= s). A more constructive direction for this, I think, would be to figure out how t= o reduce duplication and improve testability. The GELI functionality used i= n Alan's and my work ought to be pretty easily testable; all you need for a t= est suite is to make a few GELI volumes and turn their metadata blocks into a= constant array. Additionally, things could probably be refactored such tha= t there could be a single implementation of the metadata and crypto handling= bits. (I was also asking in another branch if a similar thing couldn't be d= one for the crypto code itself). The userland EFI test framework I put forw= ard is another way to deal with the difficulties of maintaining boot loader c= ode...= From owner-freebsd-hackers@freebsd.org Wed Jun 1 14:22:42 2016 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 E36AEB4F6E8 for ; Wed, 1 Jun 2016 14:22:42 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4F5DC1BDC; Wed, 1 Jun 2016 14:22:42 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.14.9) with ESMTPS id u51EMW7d033332 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 1 Jun 2016 16:22:33 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from laptop.wojtek.intra (localhost [127.0.0.1]) by laptop.wojtek.intra (8.14.9/8.14.9) with ESMTP id u51EMUtc003520; Wed, 1 Jun 2016 16:22:30 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by laptop.wojtek.intra (8.14.9/8.14.9/Submit) with ESMTP id u51EMMJG003517; Wed, 1 Jun 2016 16:22:22 +0200 (CEST) (envelope-from wojtek@puchar.net) X-Authentication-Warning: laptop.wojtek.intra: wojtek owned process doing -bs Date: Wed, 1 Jun 2016 16:22:22 +0200 (CEST) From: Wojciech Puchar X-X-Sender: wojtek@laptop.wojtek.intra To: Eric McCorkle cc: Konstantin Belousov , freebsd-hackers@freebsd.org, Allan Jude Subject: Re: EFI GELI support ready for testers In-Reply-To: <6A9DADE0-B214-424A-BB14-0B0848F0D08D@metricspace.net> Message-ID: References: <519CC1FC-84DF-4710-8E62-AF26D8AED2CF@metricspace.net> <20160528083656.GT38613@kib.kiev.ua> <20160528172618.GB38613@kib.kiev.ua> <6A9DADE0-B214-424A-BB14-0B0848F0D08D@metricspace.net> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (puchar.net [10.0.1.1]); Wed, 01 Jun 2016 16:22:33 +0200 (CEST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 14:22:43 -0000 > > To have /boot unencrypted, you have to have a separate partition for just /boot, which is undesirable. what a problem? it is standard on ALL my instalations - just to have booting independent of configuration i make. i often put this (by using gmirror or making copies) on all disks so i don't have to care about disk numbering etc. From owner-freebsd-hackers@freebsd.org Wed Jun 1 14:23:42 2016 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 1F508B4F79C for ; Wed, 1 Jun 2016 14:23:42 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7DC081D12; Wed, 1 Jun 2016 14:23:41 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.14.9) with ESMTPS id u51ENcpc033383 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 1 Jun 2016 16:23:38 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from laptop.wojtek.intra (localhost [127.0.0.1]) by laptop.wojtek.intra (8.14.9/8.14.9) with ESMTP id u51ENZtr003526; Wed, 1 Jun 2016 16:23:35 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by laptop.wojtek.intra (8.14.9/8.14.9/Submit) with ESMTP id u51ENUkr003523; Wed, 1 Jun 2016 16:23:30 +0200 (CEST) (envelope-from wojtek@puchar.net) X-Authentication-Warning: laptop.wojtek.intra: wojtek owned process doing -bs Date: Wed, 1 Jun 2016 16:23:30 +0200 (CEST) From: Wojciech Puchar X-X-Sender: wojtek@laptop.wojtek.intra To: Konstantin Belousov cc: Eric McCorkle , freebsd-hackers@freebsd.org, Allan Jude Subject: Re: EFI GELI support ready for testers In-Reply-To: <20160529091827.GD38613@kib.kiev.ua> Message-ID: References: <519CC1FC-84DF-4710-8E62-AF26D8AED2CF@metricspace.net> <20160528083656.GT38613@kib.kiev.ua> <20160528172618.GB38613@kib.kiev.ua> <6A9DADE0-B214-424A-BB14-0B0848F0D08D@metricspace.net> <20160529091827.GD38613@kib.kiev.ua> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (puchar.net [10.0.1.1]); Wed, 01 Jun 2016 16:23:39 +0200 (CEST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 14:23:42 -0000 > > And why it is simultaneously desirable to add a bunch of code to loader > to hide this ? For me it is nonsense ending with having another copy of kernel as boot loader ;), which will in turn require another normal boot loader to load it ;) From owner-freebsd-hackers@freebsd.org Wed Jun 1 14:29:28 2016 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 C8F98B4F94E for ; Wed, 1 Jun 2016 14:29:28 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2B7661FC8; Wed, 1 Jun 2016 14:29:27 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.14.9) with ESMTPS id u51ETOwx033747 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 1 Jun 2016 16:29:25 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from laptop.wojtek.intra (localhost [127.0.0.1]) by laptop.wojtek.intra (8.14.9/8.14.9) with ESMTP id u51ETMVl003534; Wed, 1 Jun 2016 16:29:22 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by laptop.wojtek.intra (8.14.9/8.14.9/Submit) with ESMTP id u51ETGse003531; Wed, 1 Jun 2016 16:29:16 +0200 (CEST) (envelope-from wojtek@puchar.net) X-Authentication-Warning: laptop.wojtek.intra: wojtek owned process doing -bs Date: Wed, 1 Jun 2016 16:29:16 +0200 (CEST) From: Wojciech Puchar X-X-Sender: wojtek@laptop.wojtek.intra To: Eric McCorkle cc: Konstantin Belousov , freebsd-hackers@freebsd.org, Allan Jude Subject: Re: EFI GELI support ready for testers In-Reply-To: <46B3F9E2-A25B-4F9D-B35F-11AC782495B1@metricspace.net> Message-ID: References: <519CC1FC-84DF-4710-8E62-AF26D8AED2CF@metricspace.net> <20160528083656.GT38613@kib.kiev.ua> <20160528172618.GB38613@kib.kiev.ua> <6A9DADE0-B214-424A-BB14-0B0848F0D08D@metricspace.net> <20160529091827.GD38613@kib.kiev.ua> <46B3F9E2-A25B-4F9D-B35F-11AC782495B1@metricspace.net> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (puchar.net [10.0.1.1]); Wed, 01 Jun 2016 16:29:25 +0200 (CEST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 14:29:28 -0000 > It's undesirable because the whole point of ZFS is to have one ZFS volume for the whole system. This sounds more like a religious dogma than anything else. what if i run single disk (or mirrored 2 disk) system, no ZFS but i want everything encrypted by GELI and want only ona partition? Will you write special bootloader that would be hidden unencrypted on geli volume? Will you write 10000 special bootloaders to cope with 10000 cases of configuration FreeBSD admins want to have in the world? Or maybe - in the future admins would not be allowed to decide and there will be only one allowed storage configuration - ZFS volume occupying all disks, with bootloader designed for that one case? Seems i made about year ago a right decision to stick to FreeBSD-10.(between 0 and 1) and then manually apply only security patches and once backport needed driver from newer one.... From owner-freebsd-hackers@freebsd.org Wed Jun 1 14:32:16 2016 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 57566B4FC25 for ; Wed, 1 Jun 2016 14:32:16 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (207-172-209-83.c3-0.arl-ubr1.sbo-arl.ma.static.cable.rcn.com [207.172.209.83]) by mx1.freebsd.org (Postfix) with ESMTP id 339EC13E0; Wed, 1 Jun 2016 14:32:15 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:8fe:6a13:797b:e9c9] (unknown [IPv6:2001:470:1f11:617:8fe:6a13:797b:e9c9]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 3FD3C1EFF; Wed, 1 Jun 2016 14:32:09 +0000 (UTC) References: <519CC1FC-84DF-4710-8E62-AF26D8AED2CF@metricspace.net> <20160528083656.GT38613@kib.kiev.ua> <20160528172618.GB38613@kib.kiev.ua> <6A9DADE0-B214-424A-BB14-0B0848F0D08D@metricspace.net> <20160529091827.GD38613@kib.kiev.ua> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <56B11DFF-7E1D-4D93-80E2-6F91F697AB9A@metricspace.net> Cc: Konstantin Belousov , freebsd-hackers@freebsd.org, Allan Jude X-Mailer: iPad Mail (13D15) From: Eric McCorkle Subject: Re: EFI GELI support ready for testers Date: Wed, 1 Jun 2016 10:32:08 -0400 To: Wojciech Puchar X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 14:32:16 -0000 On Jun 1, 2016, at 10:23, Wojciech Puchar wrote: >>=20 >> And why it is simultaneously desirable to add a bunch of code to loader >> to hide this ? >=20 > For me it is nonsense ending with having another copy of kernel as boot lo= ader ;), which will in turn require another normal boot loader to load it ;)= What are you talking about? Nobody's added another stage to the boot loader= , nor is anyone advocating doing so.= From owner-freebsd-hackers@freebsd.org Wed Jun 1 14:40:38 2016 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 75DB0B60059 for ; Wed, 1 Jun 2016 14:40:38 +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 527321A5C; Wed, 1 Jun 2016 14:40:38 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:8fe:6a13:797b:e9c9] (unknown [IPv6:2001:470:1f11:617:8fe:6a13:797b:e9c9]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id AFEA11F05; Wed, 1 Jun 2016 14:40:37 +0000 (UTC) References: <519CC1FC-84DF-4710-8E62-AF26D8AED2CF@metricspace.net> <20160528083656.GT38613@kib.kiev.ua> <20160528172618.GB38613@kib.kiev.ua> <6A9DADE0-B214-424A-BB14-0B0848F0D08D@metricspace.net> <20160529091827.GD38613@kib.kiev.ua> <46B3F9E2-A25B-4F9D-B35F-11AC782495B1@metricspace.net> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Cc: Konstantin Belousov , freebsd-hackers@freebsd.org, Allan Jude X-Mailer: iPad Mail (13D15) From: Eric McCorkle Subject: Re: EFI GELI support ready for testers Date: Wed, 1 Jun 2016 10:40:37 -0400 To: Wojciech Puchar X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 14:40:38 -0000 On Jun 1, 2016, at 10:29, Wojciech Puchar wrote: >> It's undesirable because the whole point of ZFS is to have one ZFS volume= for the whole system. > This sounds more like a religious dogma than anything else. >=20 > what if i run single disk (or mirrored 2 disk) system, no ZFS but i want e= verything encrypted by GELI and want only ona partition? So do it. I don't see the problem. > Will you write special bootloader that would be hidden unencrypted on geli= volume? No, the boot block lives either on the ESP or the boot sector. Same as it a= lways has. > Will you write 10000 special bootloaders to cope with 10000 cases of confi= guration FreeBSD admins want to have in the world? >=20 > Or maybe - in the future admins would not be allowed to decide and there w= ill be only one allowed storage configuration - ZFS volume occupying all dis= ks, with bootloader designed for that one case? These are just straw-man arguments, and nobody has suggested anything of the= sort.= From owner-freebsd-hackers@freebsd.org Wed Jun 1 14:47:41 2016 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 BBF84B603F6 for ; Wed, 1 Jun 2016 14:47:41 +0000 (UTC) (envelope-from joerg@bec.de) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) (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 8714F1F2B for ; Wed, 1 Jun 2016 14:47:41 +0000 (UTC) (envelope-from joerg@bec.de) Received: from britannica.bec.de (p20030057E2138604050FB0D91903B4F3.dip0.t-ipconnect.de [IPv6:2003:57:e213:8604:50f:b0d9:1903:b4f3]) (Authenticated sender: joerg@bec.de) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 72ABAA810C for ; Wed, 1 Jun 2016 16:47:39 +0200 (CEST) Date: Wed, 1 Jun 2016 16:47:38 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Subject: Re: EFI GELI support ready for testers Message-ID: <20160601144738.GA14531@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <519CC1FC-84DF-4710-8E62-AF26D8AED2CF@metricspace.net> <20160528083656.GT38613@kib.kiev.ua> <20160528172618.GB38613@kib.kiev.ua> <6A9DADE0-B214-424A-BB14-0B0848F0D08D@metricspace.net> <20160529091827.GD38613@kib.kiev.ua> <46B3F9E2-A25B-4F9D-B35F-11AC782495B1@metricspace.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 14:47:41 -0000 On Wed, Jun 01, 2016 at 04:29:16PM +0200, Wojciech Puchar wrote: > > It's undesirable because the whole point of ZFS is to have one ZFS > > volume for the whole system. > This sounds more like a religious dogma than anything else. If "ZFS volume" means "ZFS pool" here, it is also blatant bullshit. There are a lot of reasons for having more than one ZFS pool, the easiest being separating SSDs and HDDs for fast vs cheap storage. Joerg From owner-freebsd-hackers@freebsd.org Wed Jun 1 15:15:01 2016 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 02605B60D70 for ; Wed, 1 Jun 2016 15:15:01 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) by mx1.freebsd.org (Postfix) with ESMTP id D988210CA for ; Wed, 1 Jun 2016 15:15:00 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [192.168.1.10] (unknown [192.168.1.10]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 41C11D50A for ; Wed, 1 Jun 2016 15:14:54 +0000 (UTC) Subject: Re: EFI GELI support ready for testers To: freebsd-hackers@freebsd.org References: <519CC1FC-84DF-4710-8E62-AF26D8AED2CF@metricspace.net> <20160528083656.GT38613@kib.kiev.ua> <20160528172618.GB38613@kib.kiev.ua> <6A9DADE0-B214-424A-BB14-0B0848F0D08D@metricspace.net> <20160529091827.GD38613@kib.kiev.ua> <46B3F9E2-A25B-4F9D-B35F-11AC782495B1@metricspace.net> <20160601144738.GA14531@britannica.bec.de> From: Allan Jude Message-ID: <609c25ce-7d3e-cdc5-534f-e885e20abd40@freebsd.org> Date: Wed, 1 Jun 2016 11:14:49 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160601144738.GA14531@britannica.bec.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 15:15:01 -0000 On 2016-06-01 10:47, Joerg Sonnenberger wrote: > On Wed, Jun 01, 2016 at 04:29:16PM +0200, Wojciech Puchar wrote: >>> It's undesirable because the whole point of ZFS is to have one ZFS >>> volume for the whole system. >> This sounds more like a religious dogma than anything else. > > If "ZFS volume" means "ZFS pool" here, it is also blatant bullshit. > There are a lot of reasons for having more than one ZFS pool, the > easiest being separating SSDs and HDDs for fast vs cheap storage. > > Joerg > _______________________________________________ > 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" > Again, my only motivation for adding GELI encryption support to gptzfsboot was to allow ZFS Boot Environments, one of the biggest selling features of ZFS-on-root, to work with GELI encrypted disks. For boot environments to work, your kernel must reside in the / (root) ZFS dataset, so it can be snapshotted and cloned along with the rest of the base system. You can still use multiple pools. But for this useful feature to work, you need to be able to use a single pool, so I made it so. I added support for UFS, because it was only ~10 more lines of code. In my geliboot work, no new crypto code is introduced. It just reuses GELI and OpenCrypto. The entire geliboot codebase is only 450 lines including license and comments, mostly of boilerplate, and 100 lines of .h file to bridge the gap between the kernel and the boot2/loader environments. -- Allan Jude From owner-freebsd-hackers@freebsd.org Wed Jun 1 15:16:31 2016 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 63F65B60EBE for ; Wed, 1 Jun 2016 15:16:31 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C41FC1214; Wed, 1 Jun 2016 15:16:30 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.14.9) with ESMTPS id u51FGQQm036384 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 1 Jun 2016 17:16:26 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from laptop.wojtek.intra (localhost [127.0.0.1]) by laptop.wojtek.intra (8.14.9/8.14.9) with ESMTP id u51FGNJJ003773; Wed, 1 Jun 2016 17:16:23 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by laptop.wojtek.intra (8.14.9/8.14.9/Submit) with ESMTP id u51FGHHK003770; Wed, 1 Jun 2016 17:16:17 +0200 (CEST) (envelope-from wojtek@puchar.net) X-Authentication-Warning: laptop.wojtek.intra: wojtek owned process doing -bs Date: Wed, 1 Jun 2016 17:16:17 +0200 (CEST) From: Wojciech Puchar X-X-Sender: wojtek@laptop.wojtek.intra To: Eric McCorkle cc: Konstantin Belousov , freebsd-hackers@freebsd.org, Allan Jude Subject: Re: EFI GELI support ready for testers In-Reply-To: <56B11DFF-7E1D-4D93-80E2-6F91F697AB9A@metricspace.net> Message-ID: References: <519CC1FC-84DF-4710-8E62-AF26D8AED2CF@metricspace.net> <20160528083656.GT38613@kib.kiev.ua> <20160528172618.GB38613@kib.kiev.ua> <6A9DADE0-B214-424A-BB14-0B0848F0D08D@metricspace.net> <20160529091827.GD38613@kib.kiev.ua> <56B11DFF-7E1D-4D93-80E2-6F91F697AB9A@metricspace.net> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (puchar.net [10.0.1.1]); Wed, 01 Jun 2016 17:16:26 +0200 (CEST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 15:16:31 -0000 >>> to hide this ? >> >> For me it is nonsense ending with having another copy of kernel as boot loader ;), which will in turn require another normal boot loader to load it ;) > > What are you talking about? about FreeBSD team doing nonsense, From owner-freebsd-hackers@freebsd.org Wed Jun 1 15:19:49 2016 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 991B4B61055 for ; Wed, 1 Jun 2016 15:19:49 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 083E11509 for ; Wed, 1 Jun 2016 15:19:48 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.14.9) with ESMTPS id u51FJimn036483 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 1 Jun 2016 17:19:44 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from laptop.wojtek.intra (localhost [127.0.0.1]) by laptop.wojtek.intra (8.14.9/8.14.9) with ESMTP id u51FJfRK003779; Wed, 1 Jun 2016 17:19:41 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by laptop.wojtek.intra (8.14.9/8.14.9/Submit) with ESMTP id u51FJaHd003776; Wed, 1 Jun 2016 17:19:36 +0200 (CEST) (envelope-from wojtek@puchar.net) X-Authentication-Warning: laptop.wojtek.intra: wojtek owned process doing -bs Date: Wed, 1 Jun 2016 17:19:36 +0200 (CEST) From: Wojciech Puchar X-X-Sender: wojtek@laptop.wojtek.intra To: Joerg Sonnenberger cc: freebsd-hackers@freebsd.org Subject: Re: EFI GELI support ready for testers In-Reply-To: <20160601144738.GA14531@britannica.bec.de> Message-ID: References: <519CC1FC-84DF-4710-8E62-AF26D8AED2CF@metricspace.net> <20160528083656.GT38613@kib.kiev.ua> <20160528172618.GB38613@kib.kiev.ua> <6A9DADE0-B214-424A-BB14-0B0848F0D08D@metricspace.net> <20160529091827.GD38613@kib.kiev.ua> <46B3F9E2-A25B-4F9D-B35F-11AC782495B1@metricspace.net> <20160601144738.GA14531@britannica.bec.de> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (puchar.net [10.0.1.1]); Wed, 01 Jun 2016 17:19:45 +0200 (CEST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 15:19:49 -0000 >> This sounds more like a religious dogma than anything else. > > If "ZFS volume" means "ZFS pool" here, it is also blatant bullshit. > There are a lot of reasons for having more than one ZFS pool, the > easiest being separating SSDs and HDDs for fast vs cheap storage. assuming one would like to use ZFS - it is of course right. As with any other filesystem. Even more - no matter what filesystem i would use i would never want to put tens of disks as one filesystem. for simple reason of recovery and reliability. And i consider FreeBSD loader already overcomplex. having separate partition for boot stuff is just fine. After kernel is loaded it takes care of all stuff. From owner-freebsd-hackers@freebsd.org Wed Jun 1 15:24:51 2016 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 6BC3BB61354 for ; Wed, 1 Jun 2016 15:24:51 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) by mx1.freebsd.org (Postfix) with ESMTP id 4E24D1D80 for ; Wed, 1 Jun 2016 15:24:50 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [192.168.1.10] (unknown [192.168.1.10]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 52FDBD5A9 for ; Wed, 1 Jun 2016 15:24:50 +0000 (UTC) Subject: Re: EFI GELI support ready for testers To: freebsd-hackers@freebsd.org References: <519CC1FC-84DF-4710-8E62-AF26D8AED2CF@metricspace.net> <20160528083656.GT38613@kib.kiev.ua> <20160528172618.GB38613@kib.kiev.ua> <6A9DADE0-B214-424A-BB14-0B0848F0D08D@metricspace.net> <20160529091827.GD38613@kib.kiev.ua> <46B3F9E2-A25B-4F9D-B35F-11AC782495B1@metricspace.net> <20160601144738.GA14531@britannica.bec.de> From: Allan Jude Message-ID: Date: Wed, 1 Jun 2016 11:24:45 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 15:24:51 -0000 On 2016-06-01 11:19, Wojciech Puchar wrote: >>> This sounds more like a religious dogma than anything else. >> >> If "ZFS volume" means "ZFS pool" here, it is also blatant bullshit. >> There are a lot of reasons for having more than one ZFS pool, the >> easiest being separating SSDs and HDDs for fast vs cheap storage. > assuming one would like to use ZFS - it is of course right. As with any > other filesystem. > > Even more - no matter what filesystem i would use i would never want to > put tens of disks as one filesystem. for simple reason of recovery and > reliability. > > And i consider FreeBSD loader already overcomplex. having separate > partition for boot stuff is just fine. After kernel is loaded it takes > care of all stuff. > _______________________________________________ > 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" Well, that is kind of the point of ZFS, to have a filesystem with more than just a few disks, but reliably. We are not taking anything away from you, just allowing you to have the option to keep the kernel in a convenient place. -- Allan Jude From owner-freebsd-hackers@freebsd.org Wed Jun 1 15:25:34 2016 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 58D1DB613C2 for ; Wed, 1 Jun 2016 15:25:34 +0000 (UTC) (envelope-from fjwcash@gmail.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 20D221E9F for ; Wed, 1 Jun 2016 15:25:34 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: by mail-io0-x22d.google.com with SMTP id p194so25363864iod.1 for ; Wed, 01 Jun 2016 08:25:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=rtioOiXiMPaEBQR5PGkgp/aUC449bN2Zv6kn2exLHRU=; b=E0uNUE1IhBV+jxlecddXQQw4+cHvLh4Yb24/+Q1WMScFzCcY9/NjjG1kJAAC7kYzH6 /DMKuAhyg+XDLTc1Z+5obSXtjzp29KebNAGcHfUKVKGGIgOKf/CvIeAtGmH8xJtkjzWr GZU3dbjGO0zd+L39kw7aYnpx0IJpXRGukugK4J546X68ElRUzK1eimylCUEMEixbEItx f1iYO+f/7H3TI17Nq8JIPHSNbxMuZ+bYNdOMGaoP+FYT+6k+8hhyddYDmOB+eef+HUin V476TyjwvSEVuE9t9QFOOzVVaYBXHhNB9grMKYZeUm+5uLjWtGftX/rx0RM0j+hz8NEs u/bQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=rtioOiXiMPaEBQR5PGkgp/aUC449bN2Zv6kn2exLHRU=; b=f/viuu49t+xaYrJ6aw5w4kMm1fpkrYbZngdF9EQwNT2BHXE7wwkBsRR8miQ9yKjiz1 ovZF5ITEJlWy+W0FvKj+o+VS3xaS/pXmC9j6frGCtaqdJDc2orq2AbhCwyQIEv94MLrk Cme/cCDKWzhh3sWkXTpZNvetUs7yNrbzkJjLetl0JuSGRC4O+cI0yaQM8iaKGeDN212+ IaCQ7Z07SNGeN4Y6hOxXZ1xCGnyq8YvYQLg8OXbuDDFEfKTwXKSjCfq3VfRacAJBbz9U 0ecWIBbUp3Rz+on8Ri9e3z1RKSVykBwH6imIDvHUqWGHw5bAlNywkYWlwuhznx1Jn6pt 8dsQ== X-Gm-Message-State: ALyK8tIgbxe0Jqb/1/+qbmTbSD5+VDChXZ7G9cTN51ThMtRswzR2BL977M/bljdA+vRqAp8YMbKPP7bebuKb4g== MIME-Version: 1.0 X-Received: by 10.107.164.12 with SMTP id n12mr653753ioe.48.1464794733072; Wed, 01 Jun 2016 08:25:33 -0700 (PDT) Received: by 10.107.182.214 with HTTP; Wed, 1 Jun 2016 08:25:32 -0700 (PDT) In-Reply-To: <20160601144738.GA14531@britannica.bec.de> References: <519CC1FC-84DF-4710-8E62-AF26D8AED2CF@metricspace.net> <20160528083656.GT38613@kib.kiev.ua> <20160528172618.GB38613@kib.kiev.ua> <6A9DADE0-B214-424A-BB14-0B0848F0D08D@metricspace.net> <20160529091827.GD38613@kib.kiev.ua> <46B3F9E2-A25B-4F9D-B35F-11AC782495B1@metricspace.net> <20160601144738.GA14531@britannica.bec.de> Date: Wed, 1 Jun 2016 08:25:32 -0700 Message-ID: Subject: Re: EFI GELI support ready for testers From: Freddie Cash To: FreeBSD Hackers Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 15:25:34 -0000 On Wed, Jun 1, 2016 at 7:47 AM, Joerg Sonnenberger wrote: > On Wed, Jun 01, 2016 at 04:29:16PM +0200, Wojciech Puchar wrote: > > > It's undesirable because the whole point of ZFS is to have one ZFS > > > volume for the whole system. > > This sounds more like a religious dogma than anything else. > > If "ZFS volume" means "ZFS pool" here, it is also blatant bullshit. > There are a lot of reasons for having more than one ZFS pool, the > easiest being separating SSDs and HDDs for fast vs cheap storage. > =E2=80=8BNo one is saying you can't have multiple ZFS pools in a system. F= or example, there's nothing wrong with having a "system" pool where the OS is installed (say, on SSD), and a "storage" pool where all your data goes (say, on a dozen hard drives). But, in order to properly support ZFS Boot Environments, you *NEED* to have /boot as a directory on the / (root) filesystem in a ZFS pool.=E2=80=8B =E2=80=8B When you create BEs, you snapshot and clone the root filesystem (ideally, which includes the entire base OS install). If you have a separate /boot partition outside of the BE, things get hairy, out-of-sync, hard-to-manage, and cause all kinds of issues with versioning of boot blocks, loader, kernel, modules, and OS. If you want to encrypt a ZFS-on-root install *AND*=E2=80=8B use Boot Enviro= nments, then you need to have a way to load the GELI stuff and access the ZFS pool ... without having a separate /boot; ie from the loader. --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-hackers@freebsd.org Wed Jun 1 15:39:07 2016 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 B7EA6B6170C for ; Wed, 1 Jun 2016 15:39:07 +0000 (UTC) (envelope-from joerg@bec.de) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:c:538::196]) (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 840FE188A for ; Wed, 1 Jun 2016 15:39:07 +0000 (UTC) (envelope-from joerg@bec.de) Received: from britannica.bec.de (p20030057E2138604050FB0D91903B4F3.dip0.t-ipconnect.de [IPv6:2003:57:e213:8604:50f:b0d9:1903:b4f3]) (Authenticated sender: joerg@bec.de) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 5403A1720F0 for ; Wed, 1 Jun 2016 17:39:05 +0200 (CEST) Date: Wed, 1 Jun 2016 17:39:03 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Subject: Re: EFI GELI support ready for testers Message-ID: <20160601153903.GB17357@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <519CC1FC-84DF-4710-8E62-AF26D8AED2CF@metricspace.net> <20160528083656.GT38613@kib.kiev.ua> <20160528172618.GB38613@kib.kiev.ua> <6A9DADE0-B214-424A-BB14-0B0848F0D08D@metricspace.net> <20160529091827.GD38613@kib.kiev.ua> <46B3F9E2-A25B-4F9D-B35F-11AC782495B1@metricspace.net> <20160601144738.GA14531@britannica.bec.de> <609c25ce-7d3e-cdc5-534f-e885e20abd40@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <609c25ce-7d3e-cdc5-534f-e885e20abd40@freebsd.org> User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 15:39:07 -0000 On Wed, Jun 01, 2016 at 11:14:49AM -0400, Allan Jude wrote: > Again, my only motivation for adding GELI encryption support to gptzfsboot > was to allow ZFS Boot Environments, one of the biggest selling features of > ZFS-on-root, to work with GELI encrypted disks. I'm not saying anything against your patch. We spoke about it before :) Joerg From owner-freebsd-hackers@freebsd.org Wed Jun 1 15:40:46 2016 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 336FAB617F6 for ; Wed, 1 Jun 2016 15:40:46 +0000 (UTC) (envelope-from joerg@bec.de) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) (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 F2A101C58 for ; Wed, 1 Jun 2016 15:40:45 +0000 (UTC) (envelope-from joerg@bec.de) Received: from britannica.bec.de (p20030057E2138604050FB0D91903B4F3.dip0.t-ipconnect.de [IPv6:2003:57:e213:8604:50f:b0d9:1903:b4f3]) (Authenticated sender: joerg@bec.de) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id D35E71720C2 for ; Wed, 1 Jun 2016 17:40:42 +0200 (CEST) Date: Wed, 1 Jun 2016 17:40:41 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Subject: Re: EFI GELI support ready for testers Message-ID: <20160601154041.GC17357@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <519CC1FC-84DF-4710-8E62-AF26D8AED2CF@metricspace.net> <20160528083656.GT38613@kib.kiev.ua> <20160528172618.GB38613@kib.kiev.ua> <6A9DADE0-B214-424A-BB14-0B0848F0D08D@metricspace.net> <20160529091827.GD38613@kib.kiev.ua> <46B3F9E2-A25B-4F9D-B35F-11AC782495B1@metricspace.net> <20160601144738.GA14531@britannica.bec.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 15:40:46 -0000 On Wed, Jun 01, 2016 at 08:25:32AM -0700, Freddie Cash wrote: > On Wed, Jun 1, 2016 at 7:47 AM, Joerg Sonnenberger wrote: > > > On Wed, Jun 01, 2016 at 04:29:16PM +0200, Wojciech Puchar wrote: > > > > It's undesirable because the whole point of ZFS is to have one ZFS > > > > volume for the whole system. > > > This sounds more like a religious dogma than anything else. > > > > If "ZFS volume" means "ZFS pool" here, it is also blatant bullshit. > > There are a lot of reasons for having more than one ZFS pool, the > > easiest being separating SSDs and HDDs for fast vs cheap storage. > > > > No one is saying you can't have multiple ZFS pools in a system. For > example, there's nothing wrong with having a "system" pool where the OS is > installed (say, on SSD), and a "storage" pool where all your data goes > (say, on a dozen hard drives). > > But, in order to properly support ZFS Boot Environments, you *NEED* to have > /boot as a directory on the / (root) filesystem in a ZFS pool. I am fully aware of that. It is also quite different from what Wojciech wrote. As such, Alan, just go on... Joerg From owner-freebsd-hackers@freebsd.org Wed Jun 1 15:42:15 2016 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 51A3EB61974 for ; Wed, 1 Jun 2016 15:42:15 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) (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 25BFD1E84 for ; Wed, 1 Jun 2016 15:42:14 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id BA5331BF53D for ; Wed, 1 Jun 2016 10:34:41 -0500 (CDT) Subject: Re: EFI GELI support ready for testers To: freebsd-hackers@freebsd.org References: <519CC1FC-84DF-4710-8E62-AF26D8AED2CF@metricspace.net> <20160528083656.GT38613@kib.kiev.ua> <20160528172618.GB38613@kib.kiev.ua> <6A9DADE0-B214-424A-BB14-0B0848F0D08D@metricspace.net> <20160529091827.GD38613@kib.kiev.ua> <46B3F9E2-A25B-4F9D-B35F-11AC782495B1@metricspace.net> <20160601144738.GA14531@britannica.bec.de> <609c25ce-7d3e-cdc5-534f-e885e20abd40@freebsd.org> From: Karl Denninger Message-ID: <85c26cf4-5c28-526c-71f7-8ff463e0d4bd@denninger.net> Date: Wed, 1 Jun 2016 10:34:08 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <609c25ce-7d3e-cdc5-534f-e885e20abd40@freebsd.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms000606020208080605040407" X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 15:42:15 -0000 This is a cryptographically signed message in MIME format. --------------ms000606020208080605040407 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 6/1/2016 10:14, Allan Jude wrote: > On 2016-06-01 10:47, Joerg Sonnenberger wrote: >> On Wed, Jun 01, 2016 at 04:29:16PM +0200, Wojciech Puchar wrote: >>>> It's undesirable because the whole point of ZFS is to have one ZFS >>>> volume for the whole system. >>> This sounds more like a religious dogma than anything else. >> >> If "ZFS volume" means "ZFS pool" here, it is also blatant bullshit. >> There are a lot of reasons for having more than one ZFS pool, the >> easiest being separating SSDs and HDDs for fast vs cheap storage. >> >> Joerg >> _______________________________________________ >> 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" >> > > Again, my only motivation for adding GELI encryption support to > gptzfsboot was to allow ZFS Boot Environments, one of the biggest > selling features of ZFS-on-root, to work with GELI encrypted disks. > > For boot environments to work, your kernel must reside in the / (root) > ZFS dataset, so it can be snapshotted and cloned along with the rest > of the base system. > > You can still use multiple pools. > > But for this useful feature to work, you need to be able to use a > single pool, so I made it so. I added support for UFS, because it was > only ~10 more lines of code. > > In my geliboot work, no new crypto code is introduced. It just reuses > GELI and OpenCrypto. > > The entire geliboot codebase is only 450 lines including license and > comments, mostly of boilerplate, and 100 lines of .h file to bridge > the gap between the kernel and the boot2/loader environments. > I just want to add to this -- using Geli-encrypted volumes is fine as things sit now, _*but*_ you cannot do so _*and*_ have BEADM (boot environments) work properly which is a huge problem from a standpoint of deployment and maintainability for complex installations /where//kernel and system updates are made from time to time to either fix bugs or roll forward new versions. /This becomes a quite-material issue as security problems are found and fixed. With BE you clone the running environment, install the patch onto the cloned copy and reboot. Further, the previous (unpatched) copy remains available until you wish to dump it should there prove to be a problem with the patch or update you deployed. / /BE is a big deal in this regard, as it makes reverting such a change a near-instant operation if it goes sideways on you and sometimes these sorts of things *do* go sideways. Without root-on-boot for the booting pool, however, you have to manually sync things back and forth and the risk of a mistake is quite high -- and a mistake can cost you data on a production system. Reducing the attack surface (somewhat) is a (convenient) side effect; the real benefit is in maintainability as patches and new versions are released. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms000606020208080605040407 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA2MDExNTM0MDhaME8GCSqGSIb3DQEJBDFCBEDs H0I3oeVdXJFC74F431Ur+od2udoNQ7A2vTZTZ9CrTDdSJvy9w+njLnh5ykEqqoM6vZNL1xrQ V5yOVylhpQs1MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAXxQRFS/z CfLKJ7f+Vx+FEleHoJFprT3s/3nlerYqtjDZFgzrpAyZ8nsqFdTtrrdd4ujz1pGIfk51czxD tuZjwdJKNyUPmjUCKOFNVZNeeQ3OIafhneRblp2LbWl6MUvOnQgQ2fu7fpp5wG+JqDzgYj0e BfcQJKwfZAlrJV0fVK0StOmeK7sgFCfnmAl4pf2GXV9wIZDgLfiB99Blw9aQGysakXAmQCeA hIRFbjc/vWvEH5o7vHOGitPNm028Zthyy0lDfzoJdsYEtHqkOaNV9u3LqFt1QTV2yGaR4EV1 sWvm6UilrKtZ7uzSL7LFxzxkxgNMHp270XegFJwbz0OR1nBl7w6vGKPlmrd3HVoZuuvvSG2M GZgo6Pff9PPLSv/2Q4og35JkHZBVqU3KTw9kYMfevf2+QsxVlKitDb5OFvnsWdgjglKYHaPV N4tMpuqPvUMmTJn/7cWbx0zOdBElnzXcJItvzuaAdgFBy1ds2ya2N84YtT2YKixmS4adJDR4 JWnHI7JTe/yowuiX/cfRD+m9FOmxpCOtNZAoJztolXMIn1nLY38wCr1BY87MiSKaEHxxMU5f iPMZl4oOOQfDXU+nl+nHRz627f9aDE9dEMJ3NFtHZyrU5sYgKp3hz8tcqc15n8R4qId+cIuL LQiVFk6+3LWgcCh+7OvOnC+ZiFsAAAAAAAA= --------------ms000606020208080605040407-- From owner-freebsd-hackers@freebsd.org Wed Jun 1 15:44:41 2016 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 2C4E4B61A54 for ; Wed, 1 Jun 2016 15:44:41 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8D6531038 for ; Wed, 1 Jun 2016 15:44:40 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.14.9) with ESMTPS id u51Fibeg037496 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 1 Jun 2016 17:44:37 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from laptop.wojtek.intra (localhost [127.0.0.1]) by laptop.wojtek.intra (8.14.9/8.14.9) with ESMTP id u51FiYb9003889; Wed, 1 Jun 2016 17:44:34 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by laptop.wojtek.intra (8.14.9/8.14.9/Submit) with ESMTP id u51FiQnV003886; Wed, 1 Jun 2016 17:44:26 +0200 (CEST) (envelope-from wojtek@puchar.net) X-Authentication-Warning: laptop.wojtek.intra: wojtek owned process doing -bs Date: Wed, 1 Jun 2016 17:44:26 +0200 (CEST) From: Wojciech Puchar X-X-Sender: wojtek@laptop.wojtek.intra To: Freddie Cash cc: FreeBSD Hackers Subject: Re: EFI GELI support ready for testers In-Reply-To: Message-ID: References: <519CC1FC-84DF-4710-8E62-AF26D8AED2CF@metricspace.net> <20160528083656.GT38613@kib.kiev.ua> <20160528172618.GB38613@kib.kiev.ua> <6A9DADE0-B214-424A-BB14-0B0848F0D08D@metricspace.net> <20160529091827.GD38613@kib.kiev.ua> <46B3F9E2-A25B-4F9D-B35F-11AC782495B1@metricspace.net> <20160601144738.GA14531@britannica.bec.de> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (puchar.net [10.0.1.1]); Wed, 01 Jun 2016 17:44:37 +0200 (CEST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 15:44:41 -0000 > > But, in order to properly support ZFS Boot Environments, you *NEED* to have > /boot as a directory on the / (root) filesystem in a ZFS pool.? i didn't know that and .... boot reliably ;) From owner-freebsd-hackers@freebsd.org Wed Jun 1 18:04:30 2016 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 9238BB61934 for ; Wed, 1 Jun 2016 18:04:30 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (unknown [IPv6:2602:304:b010:ef20::f2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gw.catspoiler.org", Issuer "gw.catspoiler.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6095211F4 for ; Wed, 1 Jun 2016 18:04:30 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTP id u51I4NrN036166 for ; Wed, 1 Jun 2016 11:04:27 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201606011804.u51I4NrN036166@gw.catspoiler.org> Date: Wed, 1 Jun 2016 11:04:23 -0700 (PDT) From: Don Lewis Subject: how to MFC when the target moved? To: freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 18:04:30 -0000 I'd like to MFC r300705, which updates usr.bin/fortune/unstr/unstr.c, but fortune moved from /usr/games to /usr/bin between FreeBSD 10 and 11. What is the best way to proceed? Manually apply the patch and direct commit? From owner-freebsd-hackers@freebsd.org Wed Jun 1 20:59:44 2016 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 CAEA6B646A0 for ; Wed, 1 Jun 2016 20:59:44 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 898D01121; Wed, 1 Jun 2016 20:59:44 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-qg0-x22f.google.com with SMTP id q32so114564440qgq.3; Wed, 01 Jun 2016 13:59:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=YeY2cjrtceGSigyIRrbo8lmmINj0c353WbsuaVjBFxI=; b=uD1faoJEHiwXHQp2u/q8/clWzY56rxQuuXQDl2/DK0s19A3bzJmbryxIJkjKsoC6HM +0hZGeirEwFBYMUKkeUjuUKmDFxJ6c1if9DAu750czszZu3jSc8DKu6TAuR7rn6rZG5U e3mddMRNNKdNeGMC3FNWd1e3THO1Um1TwwGMH7PqWDk4sA0wMsDwPAqa8U+H8+iSHmwV 576MdL1uJU6E8ekwZR9EqJ6ROgEUXjkxure4SnDW11AYIccsrnYp7UGHRPjE1KCSOrWG d1eWIDq2BfOU/Xoh69Hz3MQdGcEOavuatAQs5yEqLmvuxh1WtEP3IfQYrBgitIfID9Du zR7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=YeY2cjrtceGSigyIRrbo8lmmINj0c353WbsuaVjBFxI=; b=UarZbax6t53CY4N57+WcxcNrQLPBnnCpUTJS0HtkEYF8h225/YSALIiZ4+edJLwvJg LxDoJ1EkhlqxUq3yu4NflfPU0v81mcVCj4WwLsgJa5KPqLiJFot83vbq7IVLHeFeWWmM bq5A+5fyPjTgpKcV0hTLzcgKq6xa7LeFBdmv/Xb9J6YqIQyznEdvPPD5PPjbvFPeV6H9 xkTaXpIH1J0cBpzgeL+A0BKdCVT0D6rdVKg9bLrXPEgomzMWnPivJ0+vJJSyxQB8TGZU eEXaouNzx/lFegtqTJ4+ZETBGVAMYixXJxxsmA4eDyrVg2haVURfBgubnqINON9BaV+U /yQA== X-Gm-Message-State: ALyK8tKUwlG90HYfkbjQyJ3yM9jNZsMPTw/EupvMcTquydGpcmOjNPymfipmzTGTWuAj+111kVTsY4D8twV0cg== MIME-Version: 1.0 X-Received: by 10.140.156.195 with SMTP id c186mr40716979qhc.58.1464814783500; Wed, 01 Jun 2016 13:59:43 -0700 (PDT) Received: by 10.55.146.69 with HTTP; Wed, 1 Jun 2016 13:59:43 -0700 (PDT) In-Reply-To: <201606011804.u51I4NrN036166@gw.catspoiler.org> References: <201606011804.u51I4NrN036166@gw.catspoiler.org> Date: Wed, 1 Jun 2016 13:59:43 -0700 Message-ID: Subject: Re: how to MFC when the target moved? From: Ngie Cooper To: Don Lewis Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 20:59:44 -0000 On Wed, Jun 1, 2016 at 11:04 AM, Don Lewis wrote: > I'd like to MFC r300705, which updates usr.bin/fortune/unstr/unstr.c, > but fortune moved from /usr/games to /usr/bin between FreeBSD 10 and 11. > What is the best way to proceed? Manually apply the patch and direct > commit? Something like this is what you want to do when recording the merge.. Cheers! -Ngie cd /usr/src svn merge -c --record-only ^/head patch file manually svn commit $PWD From owner-freebsd-hackers@freebsd.org Wed Jun 1 22:42:06 2016 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 08B70B66C34 for ; Wed, 1 Jun 2016 22:42:06 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (unknown [IPv6:2602:304:b010:ef20::f2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gw.catspoiler.org", Issuer "gw.catspoiler.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DE9631161 for ; Wed, 1 Jun 2016 22:42:05 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTP id u51Mfvdw036856; Wed, 1 Jun 2016 15:42:01 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201606012242.u51Mfvdw036856@gw.catspoiler.org> Date: Wed, 1 Jun 2016 15:41:57 -0700 (PDT) From: Don Lewis Subject: Re: how to MFC when the target moved? To: yaneurabeya@gmail.com cc: freebsd-hackers@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 22:42:06 -0000 On 1 Jun, Ngie Cooper wrote: > On Wed, Jun 1, 2016 at 3:12 PM, Don Lewis wrote: >> On 1 Jun, Ngie Cooper wrote: >>> On Wed, Jun 1, 2016 at 11:04 AM, Don Lewis >>> wrote: >>>> I'd like to MFC r300705, which updates >>>> usr.bin/fortune/unstr/unstr.c, but fortune moved from /usr/games to >>>> /usr/bin between FreeBSD 10 and 11. What is the best way to >>>> proceed? Manually apply the patch and direct commit? >>> >>> Something like this is what you want to do when recording the merge.. >>> Cheers! >> >> Hmn ... it wants to record merginfo into sys/gnu/dts when I do that ... >> >> mousie:src 382%svn merge -c 300705 --record-only '^/head/' . >> --- Recording mergeinfo for merge of r300705 into '.': >> U . >> --- Recording mergeinfo for merge of r300705 into 'sys/gnu/dts': >> U sys/gnu/dts >> >> >> It doesn't to that if I omit --record-only. > > Eh... revert those items. Not sure why it's trying to merge in that > mergeinfo... Yeah, I managed to figure out the revert workaround on my own. It seems to be a svn bug with --record-only. I merged a whole bunch of other stuff earlier and didn't run into this. From owner-freebsd-hackers@freebsd.org Wed Jun 1 22:12:11 2016 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 50473B66E69 for ; Wed, 1 Jun 2016 22:12:11 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (unknown [IPv6:2602:304:b010:ef20::f2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gw.catspoiler.org", Issuer "gw.catspoiler.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 335451D1B for ; Wed, 1 Jun 2016 22:12:11 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTP id u51MC2UR036796; Wed, 1 Jun 2016 15:12:06 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201606012212.u51MC2UR036796@gw.catspoiler.org> Date: Wed, 1 Jun 2016 15:12:02 -0700 (PDT) From: Don Lewis Subject: Re: how to MFC when the target moved? To: yaneurabeya@gmail.com cc: freebsd-hackers@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 22:12:11 -0000 On 1 Jun, Ngie Cooper wrote: > On Wed, Jun 1, 2016 at 11:04 AM, Don Lewis wrote: >> I'd like to MFC r300705, which updates usr.bin/fortune/unstr/unstr.c, >> but fortune moved from /usr/games to /usr/bin between FreeBSD 10 and 11. >> What is the best way to proceed? Manually apply the patch and direct >> commit? > > Something like this is what you want to do when recording the merge.. > Cheers! Hmn ... it wants to record merginfo into sys/gnu/dts when I do that ... mousie:src 382%svn merge -c 300705 --record-only '^/head/' . --- Recording mergeinfo for merge of r300705 into '.': U . --- Recording mergeinfo for merge of r300705 into 'sys/gnu/dts': U sys/gnu/dts It doesn't to that if I omit --record-only. From owner-freebsd-hackers@freebsd.org Wed Jun 1 22:32:45 2016 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 86204B668F7 for ; Wed, 1 Jun 2016 22:32:45 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::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 552FA1CB7; Wed, 1 Jun 2016 22:32:45 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-qg0-x234.google.com with SMTP id p34so45618363qgp.1; Wed, 01 Jun 2016 15:32:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=O1iTkilxZqYh3lV1r6G940E9QGr/mj1DQ6MCx0YdCps=; b=raw+mrGupSN/Rlqv67I0AsKvxotE2ez5Zsb1akugAYKMDWNs1tRUIcsc1lFvQBUuYj vKd66o1tlPd5MjrcFiHCiK09761Ke8J9pSF4wD/tO6Pg9+gOtapdipZ1cDLxmo/TlxZH okZROCdAOfADLdgctAyJusGBoJX+GqISjGiDOH8oqgbnEgxSHCtWhD5epkcbT/R3kkZ6 2666vQA7bz1KLmd0RDvVJEZWuq0s02fC1VVfrDf8XO9PnIDz+HCP47sxmlZluxKgMU5E 9kBIEPoZbKDwvKDa+6hjciS3nsqbptP7R+KfCgD37q3mHl8xh9S6SuvcU9oCmHqoMs08 hi2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=O1iTkilxZqYh3lV1r6G940E9QGr/mj1DQ6MCx0YdCps=; b=aHXebFZbWZ01If7eyONPCTes8UZcRy4a0ddAIqM5bYwkbioa7+BYbMS/87K2rjDOEU TGBMFFktQaANfaRORaj7amNZPdIpDvLVx9QLcFeTnRrIO6GbJNNiNkKdCJNjAVexQFkm EeomJw6KWdNl3FcFv1d+kbJs3/QNbymmN+Iv6o7T0Y1Bs0tFZDyuVQrWGNCEvl5+hTxS 5TMX9bGNgHaL6pLAeB6FY9Z7ewu+oVlaBS+JHHRdpqmWLRk0pfwFZJaM2tLmMFl5FOKo LhzM0KwvdorHlmhDWdyiHwM1prKoKoPY8L2A5pPRAUTo/lt0DGR9an7zC241DAkYnm9R UrOQ== X-Gm-Message-State: ALyK8tIF8/TqRQJ7RQ/me8PFfnPWhthznkoqlTmYwQHk69a9Ulgn9sHyXgxaHH0dmy9UrGoJWjfggrvUfyGIIA== MIME-Version: 1.0 X-Received: by 10.140.34.199 with SMTP id l65mr32185735qgl.62.1464820364446; Wed, 01 Jun 2016 15:32:44 -0700 (PDT) Received: by 10.55.146.69 with HTTP; Wed, 1 Jun 2016 15:32:44 -0700 (PDT) In-Reply-To: <201606012212.u51MC2UR036796@gw.catspoiler.org> References: <201606012212.u51MC2UR036796@gw.catspoiler.org> Date: Wed, 1 Jun 2016 15:32:44 -0700 Message-ID: Subject: Re: how to MFC when the target moved? From: Ngie Cooper To: Don Lewis Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 22:32:45 -0000 On Wed, Jun 1, 2016 at 3:12 PM, Don Lewis wrote: > On 1 Jun, Ngie Cooper wrote: >> On Wed, Jun 1, 2016 at 11:04 AM, Don Lewis wrote: >>> I'd like to MFC r300705, which updates usr.bin/fortune/unstr/unstr.c, >>> but fortune moved from /usr/games to /usr/bin between FreeBSD 10 and 11. >>> What is the best way to proceed? Manually apply the patch and direct >>> commit? >> >> Something like this is what you want to do when recording the merge.. >> Cheers! > > Hmn ... it wants to record merginfo into sys/gnu/dts when I do that ... > > mousie:src 382%svn merge -c 300705 --record-only '^/head/' . > --- Recording mergeinfo for merge of r300705 into '.': > U . > --- Recording mergeinfo for merge of r300705 into 'sys/gnu/dts': > U sys/gnu/dts > > > It doesn't to that if I omit --record-only. Eh... revert those items. Not sure why it's trying to merge in that mergeinfo... From owner-freebsd-hackers@freebsd.org Thu Jun 2 11:04:17 2016 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 9DB2FB62E8D for ; Thu, 2 Jun 2016 11:04:17 +0000 (UTC) (envelope-from danielsh@apache.org) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx1.freebsd.org (Postfix) with SMTP id 6273311B1 for ; Thu, 2 Jun 2016 11:04:16 +0000 (UTC) (envelope-from danielsh@apache.org) Received: (qmail 82319 invoked by uid 99); 2 Jun 2016 11:04:16 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Jun 2016 11:04:16 +0000 Received: by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org, from userid 3316) id B20441A0044; Thu, 2 Jun 2016 11:04:15 +0000 (UTC) Date: Thu, 2 Jun 2016 11:04:02 +0000 From: Daniel Shahaf To: Ngie Cooper Cc: Don Lewis , freebsd-hackers@freebsd.org Subject: Re: how to MFC when the target moved? Message-ID: <20160602110100.GA2451@tarsus.local2> References: <201606011804.u51I4NrN036166@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Thu, 02 Jun 2016 18:07:57 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 11:04:17 -0000 Ngie Cooper wrote on Wed, Jun 01, 2016 at 13:59:43 -0700: > On Wed, Jun 1, 2016 at 11:04 AM, Don Lewis wrote: > > I'd like to MFC r300705, which updates usr.bin/fortune/unstr/unstr.c, > > but fortune moved from /usr/games to /usr/bin between FreeBSD 10 and 11. > > What is the best way to proceed? Manually apply the patch and direct > > commit? > > Something like this is what you want to do when recording the merge.. > Cheers! > -Ngie > > cd /usr/src > svn merge -c --record-only ^/head > patch file manually > svn commit $PWD That would work, but for future reference, you could do it in one command: svn merge -c r300705 ^/head/usr.bin/fortune /usr/src/games/fortune Also, you don't need to pass «$PWD»; if you leave it out it's implied (with all subcommands except 'revert'). Cheers, Daniel From owner-freebsd-hackers@freebsd.org Thu Jun 2 18:47:30 2016 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 6AAEAB655C5 for ; Thu, 2 Jun 2016 18:47:30 +0000 (UTC) (envelope-from mpp302@gmail.com) Received: from mail-lf0-f41.google.com (mail-lf0-f41.google.com [209.85.215.41]) (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 204411738; Thu, 2 Jun 2016 18:47:29 +0000 (UTC) (envelope-from mpp302@gmail.com) Received: by mail-lf0-f41.google.com with SMTP id k98so40047932lfi.1; Thu, 02 Jun 2016 11:47:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:date:message-id:cc:to:mime-version; bh=0JWi45e7AxC2G2scgt2dAN8JSrjgE14Q7P2Zivqi3B4=; b=D39vkjfvOD7dx1CzL8Nj2a1zCENb2BjZnlA8Mn6mAYL7GVU1udm0StMNB35btbWPtw ajXRbdfdNepwM0FKTOsKEXyBH5j+LpjiC23AOh/NrUjFDVuwOYta2xIXjr+iAm89xzEo 9r43Vd0ZwguajFNi/mc1aDYFSpnbADR/xJZ+yb/Ozj3/GgIsGPLT++TjsDEGAMBp2r/h qj6cx5SPdVXqAuGN2RINYl6bRnbBlodN2mKAx9B3jlQhDSSzDWjODpkfw0VL1hKcZL/U kNr11aPy1KfYfN/TCnl1FNA+PhbBN0+G803pniPyKt+NA10/TVmj1WHwVTxfsiX0eQSp 2sKw== X-Gm-Message-State: ALyK8tJd2xMFDogIOod4qx/Q5M9ynvppPTeRhs4Bh17+vFHBrf8xeqyC3/0KnzTqPhx/Yw== X-Received: by 10.25.77.129 with SMTP id a123mr3914462lfb.3.1464893241763; Thu, 02 Jun 2016 11:47:21 -0700 (PDT) Received: from [192.168.0.15] (87-207-152-10.dynamic.chello.pl. [87.207.152.10]) by smtp.gmail.com with ESMTPSA id nq9sm180354lbc.7.2016.06.02.11.47.20 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Jun 2016 11:47:20 -0700 (PDT) From: Mateusz Piotrowski <0mp@FreeBSD.org> Subject: How does /etc/security/audit_event work? Date: Thu, 2 Jun 2016 20:47:19 +0200 Message-Id: <323FC4BC-C4BB-4090-9C9B-7F1BCC6BCC6B@FreeBSD.org> Cc: Konrad Witaszczyk To: freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 18:47:30 -0000 Hi, I participate in Google Summer of Code and I am working on a Non-BSM to = BSM audit trails conversion (link below). I=E2=80=99m feeling a little bit stuck. =46rom what I understand this file is generated by audit_kevents.h and = audit_uevent.h from within contrib/openbsm (although I couldn=E2=80=99t = find the audit_uevent.h anywhere except the directory with the FreeBSD = source code; I read the source of audit_uevent.h and I could find any = definitions with a comment =E2=80=9CThese definitions are for FreeBSD").=20= What strikes me is that the audit_event file on my working FreeBSD has = some definitions for Darwin and Solaris and those definitions not always = have a unique value of their eventnum (like the events with = eventnum=3D6171). My questions are: 1. How does /etc/security/audit_event work? 2. How does FreeBSD use this file and choose the right event type?=20 3. Which eventnums of the event types can I use on FreeBSD? Cheers, Mateusz Piotrowski Project=E2=80=99s Wiki: = https://wiki.freebsd.org/SummerOfCode2016/NonBSMtoBSMConversionTools = PS I misunderstood a lot of things here for sure - sorry about that. = I=E2=80=99ll be grateful if you correct me. From owner-freebsd-hackers@freebsd.org Fri Jun 3 09:01:43 2016 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 7A8A0B680C6 for ; Fri, 3 Jun 2016 09:01:43 +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 E1DDC1D35 for ; Fri, 3 Jun 2016 09:01:42 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: cababb5e-2969-11e6-ac92-3142cfe117f2 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound1.eu.mailhop.org (Halon Mail Gateway) with ESMTPSA; Fri, 3 Jun 2016 09:01:42 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u52G5WVJ010637; Thu, 2 Jun 2016 10:05:32 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1464883532.1204.181.camel@freebsd.org> Subject: Re: how to MFC when the target moved? From: Ian Lepore To: Don Lewis , yaneurabeya@gmail.com Cc: freebsd-hackers@freebsd.org Date: Thu, 02 Jun 2016 10:05:32 -0600 In-Reply-To: <201606012212.u51MC2UR036796@gw.catspoiler.org> References: <201606012212.u51MC2UR036796@gw.catspoiler.org> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 09:01:43 -0000 On Wed, 2016-06-01 at 15:12 -0700, Don Lewis wrote: > On 1 Jun, Ngie Cooper wrote: > > On Wed, Jun 1, 2016 at 11:04 AM, Don Lewis > > wrote: > > > I'd like to MFC r300705, which updates > > > usr.bin/fortune/unstr/unstr.c, > > > but fortune moved from /usr/games to /usr/bin between FreeBSD 10 > > > and 11. > > > What is the best way to proceed? Manually apply the patch and > > > direct > > > commit? > > > > Something like this is what you want to do when recording the > > merge.. > > Cheers! > > Hmn ... it wants to record merginfo into sys/gnu/dts when I do that > ... > > mousie:src 382%svn merge -c 300705 --record-only '^/head/' . > --- Recording mergeinfo for merge of r300705 into '.': > U . > --- Recording mergeinfo for merge of r300705 into 'sys/gnu/dts': > U sys/gnu/dts > > > It doesn't to that if I omit --record-only. I ran into something similar last year; there's just something strange about sys/gnu/dts (maybe related to its vendor-branch heritage somehow). I eventually worked around it by just doing what I needed to do and then doing svn revert -R sys/gnu/dts, leaving only the mergeinfo I actually wanted to commit. -- Ian From owner-freebsd-hackers@freebsd.org Fri Jun 3 16:27:47 2016 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 8AD97B687DC; Fri, 3 Jun 2016 16:27:47 +0000 (UTC) (envelope-from papowell@astart.com) Received: from astart2.astart.com (wsip-72-214-30-30.sd.sd.cox.net [72.214.30.30]) (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 6179D1C0C; Fri, 3 Jun 2016 16:27:46 +0000 (UTC) (envelope-from papowell@astart.com) Received: from laptop_103.private (localhost [127.0.0.1]) by astart2.astart.com (8.14.9/8.14.9) with ESMTP id u53GRjKE075914; Fri, 3 Jun 2016 09:27:46 -0700 (PDT) (envelope-from papowell@astart.com) Reply-To: papowell@astart.com To: freebsd-apache@freebsd.org, "freebsd-hackers@freebsd.org" From: Patrick Powell Subject: Apache and Dynamic Loading Modules Problems. Organization: Astart Technologies Message-ID: <9b77907e-70fc-16f3-c389-0e79239b9206@astart.com> Date: Fri, 3 Jun 2016 09:27:45 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 16:27:47 -0000 This is a bit complicated. I have filed a bug report: Bug 209585 - www/apache24 dynamic loading of MySQL client library generates errors with mod_perl CGI I suspect that the problem I am seeing is the symptom of something more serious. I want to do some further investigation but I have run into a couple of roadblocks. Before I reinvent the round rolling thing I thought I would ask the experts for some advice. It appears (from my limited tests) that the problem happens when Apache loads a module which has duplicate references to the same set of modules. In this case it appears to be the MySQL library. From my limited reading, on FreeBSD Apache uses the dynamic loadable library facilities. Note that this problem does not occur on FreeBSD 9.3 but it does occur on 10.X. This indicates that there is some change in the support for this between 9.3 and 10.X. (But I could be wrong. Just guessing here.) Just to confuse the issue here, the two Apache modules which appear to cause the problem are mod_perl + Perl DBD + Mysql support mod_dbd + APR1 + Mysql via /usr/local/lib/apr-util-1/apr_dbd_mysql-1.so Can somebody point me to some UP TO DATE or definitive documentation on the dynamic loading facility? There is lots of references to loadable kernel modules but not much on how Apache uses dynamic loading. Secondly, can somebody suggest a way to try to try to see what is happening as Apache loads these modules? I was thinking about seeing what the difference is between loading only one module (no problem) and loading two modules (problem) and trying to track down the issue. -- Patrick Powell Astart Technologies papowell@astart.com 1530 Jamacha Rd, Suite X Network and System San Diego, CA 92019 Consulting 858-874-6543 FAX 858-751-2435 Web: www.astart.com From owner-freebsd-hackers@freebsd.org Sat Jun 4 05:52:13 2016 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 E9130B691BA for ; Sat, 4 Jun 2016 05:52:13 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 774301F3C for ; Sat, 4 Jun 2016 05:52:13 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.14.9) with ESMTPS id u545pxSt083676 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 4 Jun 2016 07:51:59 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from laptop.wojtek.intra (localhost [127.0.0.1]) by laptop.wojtek.intra (8.14.9/8.14.9) with ESMTP id u545pv0E004590; Sat, 4 Jun 2016 07:51:57 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by laptop.wojtek.intra (8.14.9/8.14.9/Submit) with ESMTP id u545pqA7004587; Sat, 4 Jun 2016 07:51:52 +0200 (CEST) (envelope-from wojtek@puchar.net) X-Authentication-Warning: laptop.wojtek.intra: wojtek owned process doing -bs Date: Sat, 4 Jun 2016 07:51:52 +0200 (CEST) From: Wojciech Puchar X-X-Sender: wojtek@laptop.wojtek.intra To: Karl Denninger cc: freebsd-hackers@freebsd.org Subject: Re: EFI GELI support ready for testers In-Reply-To: <85c26cf4-5c28-526c-71f7-8ff463e0d4bd@denninger.net> Message-ID: References: <519CC1FC-84DF-4710-8E62-AF26D8AED2CF@metricspace.net> <20160528083656.GT38613@kib.kiev.ua> <20160528172618.GB38613@kib.kiev.ua> <6A9DADE0-B214-424A-BB14-0B0848F0D08D@metricspace.net> <20160529091827.GD38613@kib.kiev.ua> <46B3F9E2-A25B-4F9D-B35F-11AC782495B1@metricspace.net> <20160601144738.GA14531@britannica.bec.de> <609c25ce-7d3e-cdc5-534f-e885e20abd40@freebsd.org> <85c26cf4-5c28-526c-71f7-8ff463e0d4bd@denninger.net> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (puchar.net [10.0.1.1]); Sat, 04 Jun 2016 07:51:59 +0200 (CEST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 05:52:14 -0000 > I just want to add to this -- using Geli-encrypted volumes is fine as > things sit now, _*but*_ you cannot do so _*and*_ have BEADM (boot > environments) work properly which is a huge problem from a standpoint of ??? /dev/mirror/root.eli 3857667076 3059125276 798541800 79% / /dev/mirror/boot 251544 87408 164136 35% /b lrwxr-xr-x 1 root wheel 7 21 mar 08:28 boot -> /b/boot From owner-freebsd-hackers@freebsd.org Sat Jun 4 18:47:56 2016 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 21685B6A294 for ; Sat, 4 Jun 2016 18:47:56 +0000 (UTC) (envelope-from outro.pessoa@gmail.com) 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 9D3A01754; Sat, 4 Jun 2016 18:47:55 +0000 (UTC) (envelope-from outro.pessoa@gmail.com) Received: by mail-wm0-x232.google.com with SMTP id m124so25811201wme.1; Sat, 04 Jun 2016 11:47:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=qznujcU8delIG5e8UMLuyLqYPzSSdKyVovwcD5TnoyI=; b=wFQTfn3qAlJzxkrS/x88/bwPl+lFF5Ah3JyxFuMXi13h0UiJJnN1cJwAvVo9BcBhHy TBpyLiq1vr0BSZDfeyKFWcEQvGlh4VlROXN3nJ6iYEEsIKExYg1ddUtnA386H92V7BmZ m9UG7B5nKoN/rqtxqRDRlDSjQ18bFT8jGau+zOAZRsLzu7KjUHseRsANQOytpep3+vsE o4F1LNdhr3dnBl3ZyVVM1LAfZqikeOb714hbEsAlA7E5DDMs4kLQ4QSsMXk/CBtulfPp ZR5vLOGI18S0Fw8PRk3scDYcKW7UN8W35W9lJ4IIS/9UecO1Ps6TuED79BSIVQHkLND9 fRWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=qznujcU8delIG5e8UMLuyLqYPzSSdKyVovwcD5TnoyI=; b=ltxP+V2LEuDtLFescX12HnwpS+KF2LYsnqwBU9jg9AZa1IyWIOhDgR4ovJZK/5Svwc lbq5K6VSymA891WbjAp4780IwLESVXVgnUJFM0lmhPa7YEC/Mn07ycsjLbjfKUsnHKnd OxuNS83tH+AAJ4ffPysppccUBuhgaJspIfG9F5Dmu43WcYXDc4Wlf7nrEhjKjpVUn8hr LfX/LjBdbDplnodsrdZMvGEoNqJj1RD31eWwxDQtN7iUdtciWJm6wHQZZ/9/7wEvTfF8 913eGKhI7PRed7R63S0jWfrMzndPsMtkibeKXe1VS/UOR2gN5310WdBF0YY0BKoZkfff wUcg== X-Gm-Message-State: ALyK8tK9OH7yi/hunCCRmwPEoNRip9hQsJhlEVB8onDgbpsI1Str6OH+XpaF8Uu9lBx1Fsl7SOCfKoThjR0TQQ== X-Received: by 10.194.164.200 with SMTP id ys8mr8430113wjb.79.1465066074195; Sat, 04 Jun 2016 11:47:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.137.193 with HTTP; Sat, 4 Jun 2016 11:47:53 -0700 (PDT) In-Reply-To: <1464374270.3554715.620840249.499F5076@webmail.messagingengine.com> References: <1464374270.3554715.620840249.499F5076@webmail.messagingengine.com> From: outro pessoa Date: Sat, 4 Jun 2016 14:47:53 -0400 Message-ID: Subject: Re: We have a problem here To: Eric Furman , freebsd-hackers@freebsd.org, wblock@wonkity.com, sorressean , dru@freebsd.org, adrian@freebsd.org, misc@openbsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 18:47:56 -0000 You are allowed and encouraged to make this reply public. You may judge me as long as you are willing to be judged along side of me . By those standards you place upon me, you must meet yourself. By the standards I live and judge myself, you must also meet and be without lacking or wanting of anything. In Schrodinger's paradox, one assumes /guesses at the result within the limited environment. The environment is controlled. Will it survive within Nature? If not, then the thought experiment must be closed. If it does pass, then you must remember your observations and re-position your viewpoint to reflect that of which you had observed of/from/as another. Time is more fluid and may be folded in upon itself. Solid = Space, Liquid = Time , Gas = Probability, Plasma = Decision.. Probabilities are hazy unless the environment and conditions are exact. You re-position yourself constantly from all known vantage points and observation points within the thought experiment. What is your new hypothesis on the event? After comparing your findings with another, you choose the best probability which is positive and forward moving to the omniverse. Those possibilities which are negative and destructive will be folded upon themselves. The loop of reality will pass. On the nature of the human psyche: Freewill prevents you from eschewing responsibility for your words and actions. You nurture yourself to react differently to each environment. You are a single being; and, therefore, your personality should be singular across all aspects of your life. Experience and desire determine one's perception. Here the two secondary parts of metaphysics - nature=1, nurture=2, perception=3, desire=4 - blend into each other as would probability and decision on the quantum side. To think of it, all four parts act as one. Go back. Time is fluid and is a type of atmosphere. Each individual has their own "time zone" with the more dense having the slowest time and the less having the fastest time. Put this into perspective, the omniverse moves forward and is positive. It is dynamic and chaotically harmonious. Now, who am I? On Fri, May 27, 2016 at 2:37 PM, Eric Furman wrote: > Please, you need to calm down. > Please go to your counselor or the nearest hospital and > explain the situation to them. > They will be able to help you. > > On Tue, May 24, 2016, at 04:33 PM, outro pessoa wrote: > > It seems that some of you are willing to accuse one of speaking and > > writing > > falsehoods. > > A man comes on her being honest and the first reaction you give him is > > that > > he is a liar. When his reaction is one that you do not expect, you become > > defensive and start setting down standards. > > Every single time that I am honest, one of you comes out and insults me > > to > > no end, expecting me just to suck up your bullshit as if nothing > > occurred. > > You speak to me and of me as if I were a piece of shit on your shoe. > > You disrespect me. > > And when I react and warn you, you start crying and you try to muscle up > > like the bullies that you are. > > All of you are behind your computers picking on the homeless guy who is > > trying to do something right. > > And you go from there to insult me and my family to no end. > > It is libel and slander for any of you to call me a liar about what is on > > my birth certificate. > > It is harassment for you people to continuously use me as your scapegoat > > for whatever reasons that make you ill. > > All of you are aware of my sensitivity; yet, you still go out of your way > > to harass me. > > If I had done the same to you, I would have been arrested and put in > > jail. > > And yet, you people are still free to annoy and harass me again. > > > > I am homeless. > > I was given equipment and I want to use it as an animation station for > > children. > > You will go out of your way -as you already have - to degrade me just for > > being humble, considerate and kind. > > You laugh at me when I try to aid others. > > > > > > > > What right do any of you have to judge me when you have broken your own > > laws many times? > > I am able to present documentation that will state none of you have the > > right to put me in any stressful situation. If doing such does occur, I > > have the right to file charges. > > > > > > Go through the mailing list. > > And read how Mr Sorrenson harassed me to no end. > > And then you will support him > > after he has broken state laws. > > > > You see, I want all of you to come here and meet me. > > I want all of you to bring your accusations against me in a court of law. > > Theo de Raadt also went beyond what was normal and insulted me to the > > point > > of harassment. > > And then he cried about my reaction. > > > > > > Unlike you - plural - I do not deny anything that I have said or done. > > I also do not admit to such until the time is right. > > > > I sit here and watch your conversations in person, overhearing - ear > > hustling, and reading the mailing lists and forums. > > You go back in your everyday lives with no regard of what you say or > > do... > > Until you fuck up and anger someone that did you no harm and no wrong. > > > > > > You called me a liar about my own mother and my birth when I told you the > > truth. > > What in the hell is wrong with all of you? > > Seriously, > > what do you have between your ears? Bullshit? > > > > I hear someone muttering "Wait a minute, man, and let us explain." > > > > Explain what? > > That you are all evil and selfish? > > That you care only for yourselves? > > > > Who do you think you are talking to right now, huh? > > > > My personality is the same no matter where I go. > > > > I don't put on faces. > > > > I am me. > > On the forums. > > In the streets. > > On the mailing lists. > > In the woods. > > > > Yeah, I said it. > > > > > > > > And you find it humorous that a man in my position would go out of his > > way > > to aid and assist others before taking care of himself. > > > > I have this equipment and it will go to aiding and assisting children and > > students. > > > > I have nothing. I am homeless. I look out for others. > > And, > > All that you people do is treat me like shit because I refuse to be as > > twisted as you. > > > > I am here waiting for any of you to approach me in person. Since you were > > warned, you should know now how to act accordingly. > > You will approach me with respect because I gave it to you when you did > > not > > give it to me. > > What do I mean? > > When you attack another without consideration, that is a sign of > > disrespect. > > You made an assumption of my character. > > Did any of you ever think that if it is not written or spoken, then I did > > not mean or want you to see such? > > I thought about the whole process before and decided that it would be > > better to say, "Write legibly," instead of accusing someone of wanting > > ignorance. > > Get it? > > And then Mr. Sorrenson - and before Mr. deRaadt - went out of their way > > to > > insult me, thinking it was cute and funny. > > > > Do any of you remember the youtube piece about the tiger that attacked > > the > > two idiots who were harassing it to no end? > > You do. > > Ah, yes. > > Well. > > You have annoyed the tiger. > > > > > > > > > > > > If you are so willing to harass me and my family, then you should be > > willing to go to court for what you do. > > >