Re: GELI with UEFI supporting Boot Environments goes to HEAD when?

[Tommi Pernila]

On Fri, 3 Aug 2018 at 20.17, Warner Losh  wrote:

> On Fri, Aug 3, 2018, 5:58 PM Ian Lepore  wrote:
>
> > On Fri, 2018-08-03 at 19:54 +0300, Tommi Pernila wrote:
> > > On Tue, 10 Jul 2018 at 1.05, Warner Losh  wrote:
> > >
> > > >
> > > > I have this in my tree already...
> > > >
> > > > Warner
> > > >
> > > > On Mon, Jul 9, 2018, 10:28 AM Allan Jude 
> > > > wrote:
> > > >
> > > > >
> > > > > I will look at updating the rootgen.sh script this evening, to
> > > > > support
> > > > > creating more flexible ESP partitions, so we can drop the
> > > > > loader.efi
> > > > > into an msdosfs directly.
> > > > >
> > > > > On 07/08/2018 15:31, Ian Lepore wrote:
> > > > > >
> > > > > > On Sun, 2018-07-08 at 21:08 +0200, Oliver Pinter wrote:
> > > > > > >
> > > > > > > Hi!
> > > > > > >
> > > > > > > Have you or Warner any update on this code?
> > > > > > >
> > > > > > > On Thursday, April 12, 2018, Eric McCorkle  > > > > > > net>
> > > > > > > wrote:
> > > > > > >
> > > > > > Are you aware of https://reviews.freebsd.org/D15743 ?
> > > > > >
> > > > > > That's my changes to add geli support to loader(8) in an
> > > > > > architecture-
> > > > > > agnostic way, so that "it just works" for all platforms and
> > > > > > flavors of
> > > > > > loader. It has been succesfully tested on armv6/7 (ubldr) and
> > > > > > on x86
> > > > > > using qemu.  The x86 tests cover ufs and zfs, legacy bios and
> > > > > > uefi. The
> > > > > > only variations that aren't tested yet are the uefi flavors,
> > > > > > because
> > > > > > the current rootgen.sh script for assembling test images is
> > > > > > still using
> > > > > > boot1.efi and I don't know enough about efi myself to update
> > > > > > the script
> > > > > > to make it assemble images the new way Warner envisions.
> > > > > >
> > > > > > -- Ian
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > I'm in the middle of moving to a new apartment right
> > > > > > > > now.  It's
> > > > > > > > going to
> > > > > > > > be a bit before I can get to this.
> > > > > > > >
> > > > > > > > On 04/11/2018 20:31, Warner Losh wrote:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > OK. I've pushed in the main part of it. The additional
> > > > > > > > > work I
> > > > > > > > > have
> > > > > > > > > shouldn't affect any of this stuff.  I was going to look
> > > > > > > > > at what
> > > > > > > > > part(s)
> > > > > > > > > of your open reviewed needed to be redone tomorrow and
> > > > > > > > > send you
> > > > > > > > > feedback, but if you wanted to get a start before then,
> > > > > > > > > I'm happy
> > > > > > > > > to
> > > > > > > > > answer questions. All the rest of my work is going to be
> > > > > > > > > selecting the
> > > > > > > > > root partition when we're told to us a specific
> > > > > > > > > partition, so
> > > > > > > > > will be
> > > > > > > > > very constrained.
> > > > > > > > >
> > > > > > > > > Warner
> > > > > > > > >
> > > > > > > > > On Wed, Apr 11, 2018 at 6:02 PM, Eric McCorkle  > > > > > > > > icspace.
> > > > > > > > > net
> > > > > > > > > <mailto:e...@metricspace.net>> wrote:
> > > > > > > > >
> > > > > > > > >  I think

Re: GELI with UEFI supporting Boot Environments goes to HEAD when?

[Tommi Pernila]

On Tue, 10 Jul 2018 at 1.05, Warner Losh  wrote:

> I have this in my tree already...
>
> Warner
>
> On Mon, Jul 9, 2018, 10:28 AM Allan Jude  wrote:
>
>> I will look at updating the rootgen.sh script this evening, to support
>> creating more flexible ESP partitions, so we can drop the loader.efi
>> into an msdosfs directly.
>>
>> On 07/08/2018 15:31, Ian Lepore wrote:
>> > On Sun, 2018-07-08 at 21:08 +0200, Oliver Pinter wrote:
>> >> Hi!
>> >>
>> >> Have you or Warner any update on this code?
>> >>
>> >> On Thursday, April 12, 2018, Eric McCorkle 
>> >> wrote:
>> >>
>> >
>> > Are you aware of https://reviews.freebsd.org/D15743 ?
>> >
>> > That's my changes to add geli support to loader(8) in an architecture-
>> > agnostic way, so that "it just works" for all platforms and flavors of
>> > loader. It has been succesfully tested on armv6/7 (ubldr) and on x86
>> > using qemu.  The x86 tests cover ufs and zfs, legacy bios and uefi. The
>> > only variations that aren't tested yet are the uefi flavors, because
>> > the current rootgen.sh script for assembling test images is still using
>> > boot1.efi and I don't know enough about efi myself to update the script
>> > to make it assemble images the new way Warner envisions.
>> >
>> > -- Ian
>> >
>> >>>
>> >>> I'm in the middle of moving to a new apartment right now.  It's
>> >>> going to
>> >>> be a bit before I can get to this.
>> >>>
>> >>> On 04/11/2018 20:31, Warner Losh wrote:
>> >>>>
>> >>>> OK. I've pushed in the main part of it. The additional work I
>> >>>> have
>> >>>> shouldn't affect any of this stuff.  I was going to look at what
>> >>>> part(s)
>> >>>> of your open reviewed needed to be redone tomorrow and send you
>> >>>> feedback, but if you wanted to get a start before then, I'm happy
>> >>>> to
>> >>>> answer questions. All the rest of my work is going to be
>> >>>> selecting the
>> >>>> root partition when we're told to us a specific partition, so
>> >>>> will be
>> >>>> very constrained.
>> >>>>
>> >>>> Warner
>> >>>>
>> >>>> On Wed, Apr 11, 2018 at 6:02 PM, Eric McCorkle > >>>> net
>> >>>> <mailto:e...@metricspace.net>> wrote:
>> >>>>
>> >>>>  I think the thing to do at this point is to wait for the
>> >>>> current
>> >>> work on
>> >>>>
>> >>>>  loader.efi to land, then adapt my patches to apply against
>> >>>> that work.
>> >>>>
>> >>>>  On 04/11/2018 15:06, Warner Losh wrote:
>> >>>>  > Still reviewing the code. I'm worried it's too i386
>> >>>> specific and it
>> >>>>  > conflicts with some work I'm doing. I'll have a list of
>> >>>> actionable
>> >>>>  > critiques this week.
>> >>>>  >
>> >>>>  > Warner
>> >>>>  >
>> >>>>  > On Wed, Apr 11, 2018 at 1:03 PM, Oliver Pinter
>> >>>>  > > >>>>  <mailto:oliver.pin...@hardenedbsd.org>
>> >>>>  <mailto:oliver.pin...@hardenedbsd.org
>> >>>>  <mailto:oliver.pin...@hardenedbsd.org>>>
>> >>>>  > wrote:
>> >>>>  >
>> >>>>  > Hi!
>> >>>>  >
>> >>>>  > Is there any update regarding the rebase or the
>> >>>> inclusion to
>> >>> base
>> >>>>
>> >>>>  > system?
>> >>>>  > On 3/28/18, Eric McCorkle > >>>> > >>> e...@metricspace.net>
>> >>>>
>> >>>>  > <mailto:e...@metricspace.net <mailto:eric@metricspace.n
>> >>>> et>>>
>> >>> wrote:
>> >>>>
>> >>>>  > > I'll do another rebase from head just to be sure
>> >>>>  > >
>> >>>>  > 

Re: Nvidia issue with CURRENT

[Tommi Pernila]

Hi,

are you running which version of CURRENT?
E.g. Some snapshot or did you compile from source?

-Tommi

On Sun, 22 Apr 2018 at 13.47, Mariusz Zaborski  wrote:

> Hello,
>
> I upgraded my FreeBSD to CURRENT and nvidia-drvier-390.48. But it's
> stop working.
> I tried also nvidia-driver-390.25 without luck as well.
>
> I have loaded nvidia-modeset.ko .
>
> While I'm rebooting my machine its also core dumping:
> https://people.freebsd.org/~oshogbo/nvidia-mail.png .
> I'm attaching also Xorg log.
>
> Is this a known issue?
>
> Thanks,
> Mariusz
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: GELI with UEFI supporting Boot Environments goes to HEAD when?

[Tommi Pernila]

excellent, thanks again for all your work.

On Wed, 28 Mar 2018 at 22.25, Eric McCorkle <e...@metricspace.net> wrote:

> I'll do another rebase from head just to be sure
>
> On March 28, 2018 3:23:23 PM EDT, Warner Losh <i...@bsdimp.com> wrote:
>>
>> It's on my list for nexr, finally. I have an alternate patch for
>> loader.efi from ESP, but i don't think it will affect the GELI stuff. I
>> have some time slotted for integration issues though.
>>
>> I am quite mindful of the freeze dates I  have some uefi boot loader
>> protocol changes that I need to get in.
>>
>> Warner
>>
>> On Feb 21, 2018 11:18 PM, "Tommi Pernila" <tommi.pern...@iki.fi> wrote:
>>
>>> Awesome, thanks for the update and the work that you have done!
>>>
>>> Now we just need some more reviewers eyes on the code :)
>>>
>>> Br,
>>>
>>> Tommi
>>>
>>> On Thu, 22 Feb 2018 at 2.03, Eric McCorkle <e...@metricspace.net> wrote:
>>>
>>>> FYI, I just IFC'ed everything, and the current patches are still fine.
>>>>
>>>> Also, the full GELI + standalone loader has been deployed on one of my
>>>> laptops for some time now.
>>>>
>>>> On 02/21/2018 18:15, Eric McCorkle wrote:
>>>> > The GELI work could be merged at this point, though it won't be usable
>>>> > without an additional patch to enable loader-only operation.  The
>>>> > patches are currently up for review:
>>>> >
>>>> > This is the order in which they'd need to be merged:
>>>> >
>>>> >
>>>> > https://reviews.freebsd.org/D12732
>>>> >
>>>> > This one changes the efipart device.  Toomas Soome identified some
>>>> > problems, which I have addressed.  He has not re-reviewed it, however.
>>>> >
>>>> >
>>>> > https://reviews.freebsd.org/D12692
>>>> >
>>>> > This adds some crypto code needed for GELI.  It simply adds new code,
>>>> > and doesn't conflict with anything.
>>>> >
>>>> >
>>>> > https://reviews.freebsd.org/D12698
>>>> >
>>>> > This adds the EFI KMS interface code, and has the EFI loader pass keys
>>>> > into the keybuf interface.
>>>> >
>>>> >
>>>> > I can't post the main GELI driver until those get merged, as it
>>>> depends
>>>> > on them.  It can be found on the geli branch on my github freebsd
>>>> > repository, however.
>>>> >
>>>> >
>>>> > Additionally, you need this patch, which allows loader.efi to function
>>>> > when installed directly to the ESP:
>>>> >
>>>> > https://reviews.freebsd.org/D13497
>>>> >
>>>> > On 02/20/2018 22:56, Tommi Pernila wrote:
>>>> >> Hi Eric,
>>>> >>
>>>> >> could you provide a brief update how the work is going?
>>>> >>
>>>> >>
>>>> >> Br,
>>>> >>
>>>> >> Tommi
>>>> >>
>>>> >>
>>>> >> On Nov 16, 2017 04:29, "Eric McCorkle" <e...@metricspace.net
>>>> >> <mailto:e...@metricspace.net>> wrote:
>>>> >>
>>>> >> Right, so basically, the remaining GELI patches are against
>>>> loader, and
>>>> >> most of them can go in independently of the work on removing
>>>> boot1.
>>>> >> There's a unanimous consensus on getting rid of boot1 which
>>>> includes its
>>>> >> original author, so that's going to happen.
>>>> >>
>>>> >>
>>>> >> For GELI, we have the following (not necessarily in order):
>>>> >>
>>>> >> a) Adding the KMS interfaces, pseudo-device, and kernel keybuf
>>>> >> interactions
>>>> >> b) Modifications to the efipart driver
>>>> >> c) boot crypto
>>>> >> d) GELI partition types (not strictly necessary)
>>>> >>
>>>> >> Then there's the GELI driver itself.  (a) and (c) are good to
>>>> land, (b)
>>>> >> needs some more work after Toomas Soome pointed out a legitimate
>>>> >> problem, and (d) actually needs a good bit more code (but again,
>>>> it's
>>>> >> more cosmetic).  Additionally, the GELI driver will need further
>>>> mods to
>>>> >> efipart to be written (nothing too big).  But we could go ahead
>>>> with (a)
>>>> >> and (c), as they've already been proven to work.
>>>> >>
>>>> >> I'd wanted to have this stuff shaped up sooner, but I'm
>>>> preoccupied with
>>>> >> the 7th RISC-V workshop at the end of the month.
>>>> >>
>>>> >> Once this stuff is all in, loader should handle any GELI volumes
>>>> it
>>>> >> finds, and it should Just Work once boot1 is gone.
>>>> >>
>>>> >>
>>>> > ___
>>>> > freebsd-current@freebsd.org mailing list
>>>> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>>> > To unsubscribe, send any mail to "
>>>> freebsd-current-unsubscr...@freebsd.org"
>>>> >
>>>>
>>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: GELI with UEFI supporting Boot Environments goes to HEAD when?

[Tommi Pernila]

Hi all,

is there any chance that this would make it to 11.2 RELEASE ?

 stable/11 slush: April 20, 2018
 stable/11 freeze:May 4, 2018

Br,

Tommi


On Thu, Feb 22, 2018 at 8:18 AM, Tommi Pernila <tommi.pern...@iki.fi> wrote:

> Awesome, thanks for the update and the work that you have done!
>
> Now we just need some more reviewers eyes on the code :)
>
> Br,
>
> Tommi
>
> On Thu, 22 Feb 2018 at 2.03, Eric McCorkle <e...@metricspace.net> wrote:
>
>> FYI, I just IFC'ed everything, and the current patches are still fine.
>>
>> Also, the full GELI + standalone loader has been deployed on one of my
>> laptops for some time now.
>>
>> On 02/21/2018 18:15, Eric McCorkle wrote:
>> > The GELI work could be merged at this point, though it won't be usable
>> > without an additional patch to enable loader-only operation.  The
>> > patches are currently up for review:
>> >
>> > This is the order in which they'd need to be merged:
>> >
>> >
>> > https://reviews.freebsd.org/D12732
>> >
>> > This one changes the efipart device.  Toomas Soome identified some
>> > problems, which I have addressed.  He has not re-reviewed it, however.
>> >
>> >
>> > https://reviews.freebsd.org/D12692
>> >
>> > This adds some crypto code needed for GELI.  It simply adds new code,
>> > and doesn't conflict with anything.
>> >
>> >
>> > https://reviews.freebsd.org/D12698
>> >
>> > This adds the EFI KMS interface code, and has the EFI loader pass keys
>> > into the keybuf interface.
>> >
>> >
>> > I can't post the main GELI driver until those get merged, as it depends
>> > on them.  It can be found on the geli branch on my github freebsd
>> > repository, however.
>> >
>> >
>> > Additionally, you need this patch, which allows loader.efi to function
>> > when installed directly to the ESP:
>> >
>> > https://reviews.freebsd.org/D13497
>> >
>> > On 02/20/2018 22:56, Tommi Pernila wrote:
>> >> Hi Eric,
>> >>
>> >> could you provide a brief update how the work is going?
>> >>
>> >>
>> >> Br,
>> >>
>> >> Tommi
>> >>
>> >>
>> >> On Nov 16, 2017 04:29, "Eric McCorkle" <e...@metricspace.net
>> >> <mailto:e...@metricspace.net>> wrote:
>> >>
>> >> Right, so basically, the remaining GELI patches are against
>> loader, and
>> >> most of them can go in independently of the work on removing boot1.
>> >> There's a unanimous consensus on getting rid of boot1 which
>> includes its
>> >> original author, so that's going to happen.
>> >>
>> >>
>> >> For GELI, we have the following (not necessarily in order):
>> >>
>> >> a) Adding the KMS interfaces, pseudo-device, and kernel keybuf
>> >> interactions
>> >> b) Modifications to the efipart driver
>> >> c) boot crypto
>> >> d) GELI partition types (not strictly necessary)
>> >>
>> >> Then there's the GELI driver itself.  (a) and (c) are good to
>> land, (b)
>> >> needs some more work after Toomas Soome pointed out a legitimate
>> >> problem, and (d) actually needs a good bit more code (but again,
>> it's
>> >> more cosmetic).  Additionally, the GELI driver will need further
>> mods to
>> >> efipart to be written (nothing too big).  But we could go ahead
>> with (a)
>> >> and (c), as they've already been proven to work.
>> >>
>> >> I'd wanted to have this stuff shaped up sooner, but I'm
>> preoccupied with
>> >> the 7th RISC-V workshop at the end of the month.
>> >>
>> >> Once this stuff is all in, loader should handle any GELI volumes it
>> >> finds, and it should Just Work once boot1 is gone.
>> >>
>> >>
>> > ___
>> > freebsd-current@freebsd.org mailing list
>> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@
>> freebsd.org"
>> >
>>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: GELI with UEFI supporting Boot Environments goes to HEAD when?

[Tommi Pernila]

Awesome, thanks for the update and the work that you have done!

Now we just need some more reviewers eyes on the code :)

Br,

Tommi

On Thu, 22 Feb 2018 at 2.03, Eric McCorkle <e...@metricspace.net> wrote:

> FYI, I just IFC'ed everything, and the current patches are still fine.
>
> Also, the full GELI + standalone loader has been deployed on one of my
> laptops for some time now.
>
> On 02/21/2018 18:15, Eric McCorkle wrote:
> > The GELI work could be merged at this point, though it won't be usable
> > without an additional patch to enable loader-only operation.  The
> > patches are currently up for review:
> >
> > This is the order in which they'd need to be merged:
> >
> >
> > https://reviews.freebsd.org/D12732
> >
> > This one changes the efipart device.  Toomas Soome identified some
> > problems, which I have addressed.  He has not re-reviewed it, however.
> >
> >
> > https://reviews.freebsd.org/D12692
> >
> > This adds some crypto code needed for GELI.  It simply adds new code,
> > and doesn't conflict with anything.
> >
> >
> > https://reviews.freebsd.org/D12698
> >
> > This adds the EFI KMS interface code, and has the EFI loader pass keys
> > into the keybuf interface.
> >
> >
> > I can't post the main GELI driver until those get merged, as it depends
> > on them.  It can be found on the geli branch on my github freebsd
> > repository, however.
> >
> >
> > Additionally, you need this patch, which allows loader.efi to function
> > when installed directly to the ESP:
> >
> > https://reviews.freebsd.org/D13497
> >
> > On 02/20/2018 22:56, Tommi Pernila wrote:
> >> Hi Eric,
> >>
> >> could you provide a brief update how the work is going?
> >>
> >>
> >> Br,
> >>
> >> Tommi
> >>
> >>
> >> On Nov 16, 2017 04:29, "Eric McCorkle" <e...@metricspace.net
> >> <mailto:e...@metricspace.net>> wrote:
> >>
> >> Right, so basically, the remaining GELI patches are against loader,
> and
> >> most of them can go in independently of the work on removing boot1.
> >> There's a unanimous consensus on getting rid of boot1 which
> includes its
> >> original author, so that's going to happen.
> >>
> >>
> >> For GELI, we have the following (not necessarily in order):
> >>
> >> a) Adding the KMS interfaces, pseudo-device, and kernel keybuf
> >> interactions
> >> b) Modifications to the efipart driver
> >> c) boot crypto
> >> d) GELI partition types (not strictly necessary)
> >>
> >> Then there's the GELI driver itself.  (a) and (c) are good to land,
> (b)
> >> needs some more work after Toomas Soome pointed out a legitimate
> >> problem, and (d) actually needs a good bit more code (but again,
> it's
> >> more cosmetic).  Additionally, the GELI driver will need further
> mods to
> >> efipart to be written (nothing too big).  But we could go ahead
> with (a)
> >> and (c), as they've already been proven to work.
> >>
> >> I'd wanted to have this stuff shaped up sooner, but I'm preoccupied
> with
> >> the 7th RISC-V workshop at the end of the month.
> >>
> >> Once this stuff is all in, loader should handle any GELI volumes it
> >> finds, and it should Just Work once boot1 is gone.
> >>
> >>
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "
> freebsd-current-unsubscr...@freebsd.org"
> >
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: GELI with UEFI supporting Boot Environments goes to HEAD when?

[Tommi Pernila]

Hi Eric,

could you provide a brief update how the work is going?


Br,

Tommi


On Nov 16, 2017 04:29, "Eric McCorkle"  wrote:

Right, so basically, the remaining GELI patches are against loader, and
most of them can go in independently of the work on removing boot1.
There's a unanimous consensus on getting rid of boot1 which includes its
original author, so that's going to happen.


For GELI, we have the following (not necessarily in order):

a) Adding the KMS interfaces, pseudo-device, and kernel keybuf interactions
b) Modifications to the efipart driver
c) boot crypto
d) GELI partition types (not strictly necessary)

Then there's the GELI driver itself.  (a) and (c) are good to land, (b)
needs some more work after Toomas Soome pointed out a legitimate
problem, and (d) actually needs a good bit more code (but again, it's
more cosmetic).  Additionally, the GELI driver will need further mods to
efipart to be written (nothing too big).  But we could go ahead with (a)
and (c), as they've already been proven to work.

I'd wanted to have this stuff shaped up sooner, but I'm preoccupied with
the 7th RISC-V workshop at the end of the month.

Once this stuff is all in, loader should handle any GELI volumes it
finds, and it should Just Work once boot1 is gone.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: GELI with UEFI supporting Boot Environments goes to HEAD when?

[Tommi Pernila]

On Wed, 15 Nov 2017 at 16.47, Warner Losh <i...@bsdimp.com> wrote:

> On Wed, Nov 15, 2017 at 3:28 AM, Tommi Pernila <tommi.pern...@gmail.com>
> wrote:
>
>> Hi All,
>>
>> Anyone have an idea when the GELI with UEFI supporting Boot
>> Environments goes to HEAD?
>>
>> The Phabricator reviews for this seem to done.
>> Also recently I have seen quite a few commits done by @imp which touch
>> GELI,
>> Are these related to this feature or something else?
>>
>> So it could be that this feature is already in HEAD, or are still some
>> parts pending?
>>
>
> It will be available once we move to loader.efi and ditch boot1.efi, which
> is some weeks away.
>
> Warner
>

Ok.

Thanks Warner and Eric for all of your work :)


-Tommi



>
>> Below a clip from Allan describing the feature i'm looking for:
>>
>>
>> On Tue, 11 Jul 2017 at 18.31, Allan Jude <allanj...@freebsd.org> wrote:
>>
>>>
>>> Boot environments with a bootpool do not work. Support for GELI with
>>> UEFI is coming soon. This will allow you to move /boot into the GELI
>>> encrypted pool, and get rid of the bootpool, and properly use boot
>>> environments.
>>>
>>> --
>>> Allan Jude
>>
>>
>>
>> Br,
>>
>> Tommi
>>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

GELI with UEFI supporting Boot Environments goes to HEAD when?

[Tommi Pernila]

Hi All,

Anyone have an idea when the GELI with UEFI supporting Boot
Environments goes to HEAD?

The Phabricator reviews for this seem to done.
Also recently I have seen quite a few commits done by @imp which touch GELI,
Are these related to this feature or something else?

So it could be that this feature is already in HEAD, or are still some
parts pending?

Below a clip from Allan describing the feature i'm looking for:


On Tue, 11 Jul 2017 at 18.31, Allan Jude  wrote:

>
> Boot environments with a bootpool do not work. Support for GELI with
> UEFI is coming soon. This will allow you to move /boot into the GELI
> encrypted pool, and get rid of the bootpool, and properly use boot
> environments.
>
> --
> Allan Jude



Br,

Tommi
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: latest iwm patches don't work with my 8265 chip

[Tommi Pernila]

Hi,

Thanks for the info Pete.

I also have no idea about the correctness of the patch, but i'll also test
it on my 8265 card.


Br,

Tommi

On Tue, 10 Oct 2017 at 5.12, Pete Wright  wrote:

>
>
> On 10/09/2017 16:02, Pete Wright wrote:
> > hey there - i was really excited to see GNN's recent commits to add
> > support to the 8265 Intel WiFi devices:
> >
> > https://svnweb.freebsd.org/base?view=revision=324434
> >
> > unfortunately this does not seem to work on my system.  after building
> > and rebooting dmesg reports this:
> >
> > iwm0:  mem 0xdf00-0xdf001fff
> > at device 0.0 on pci2
> > iwm8265fw: could not load firmware image, error 2
> > iwm0: could not read firmware iwm8265fw (error 0)
> > iwm0: SecBoot CPU1 Status: 0x1, CPU2 Status: 0x3
> > iwm0: Failed to start INIT ucode: 35
> >
> > here's the output from pciconf for my device:
> >
> > iwm0@pci0:3:0:0:class=0x028000 card=0x10108086 chip=0x24fd8086
> > rev=0x78 hdr=0x00
> > vendor = 'Intel Corporation'
> > device = 'Wireless 8265 / 8275'
> > class  = network
> >
> >
> > interestingly enough the patches imported from dragonfly worked great:
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220229
> >
>
> not sure if this is the correct way to get things working, but this diff
> fixes things up on my end (allows the firmware to load):
>
> diff --git a/sys/modules/iwmfw/Makefile b/sys/modules/iwmfw/Makefile
> index d38f5424153..73e401b3ea9 100644
> --- a/sys/modules/iwmfw/Makefile
> +++ b/sys/modules/iwmfw/Makefile
> @@ -1,5 +1,5 @@
>   # $FreeBSD$
>
> -SUBDIR=iwm3160fw iwm7260fw iwm7265fw iwm8000Cfw iwm7265Dfw
> +SUBDIR=iwm3160fw iwm7260fw iwm7265fw iwm8000Cfw iwm8265fw
> iwm7265Dfw
>
>   .include 
>
>
> w/o the diff the iwm8265fw doesn't get built afaict.
>
> cheers,
> -pete
>
> --
> Pete Wright
> p...@nomadlogic.org
> @nomadlogicLA
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Cannot install FreeBSD 12.0 on HP Compaq DC5850

[Tommi Pernila]

Hi Elena,

Thanks for the details.
I'm also forwarding this to the Current mailing list as it has more devs
following.

Br,

Tommi


On Thu, 28 Sep 2017 at 10.45, Elena Mihailescu <elenamihailesc...@gmail.com>
wrote:

> Hi Tommi,
>
>
> 2017-09-27 21:28 GMT+03:00 Tommi Pernila <tommi.pern...@iki.fi>:
> > Hi Elena,
> >
> > If you can send more details from the hardware, the troubleshooting will
> be
> > faster.
> > E.g. sending a dmesg output (even a screenshot) from the OS.
> >
>
> At the moment, there is no OS on this PC. When I try to install FreeBSD,
> this is the only output which is displayed and everything hangs [1].
>
> I took a picture of system information from BIOS [2]. Please tell me if
> there is any other information from the hardware which I should provide.
>
>
>
> > Have you tried booting FreeBSD 11.1-Release?
> >
> > Also when you mention FreeBSD 12.0-Current, is it how old? Or do you know
> > the release version?
>
> I downloaded FreeBSD-12.0-CURRENT-amd64-20170814-r322508-disc1.iso from
> here [3]. I will try the latest version, which is
> FreeBSD-12.0-CURRENT-amd64-20170925-r323985-disc1.iso and also, I will try
> FreeBSD 11.1-Release.
>
> Thanks,
> Elena
>
>
> [1] https://drive.google.com/open?id=0B8qXIRloK7xeRDZMdnJBTWRCXzA
> [2] https://drive.google.com/open?id=0B8qXIRloK7xeRU03R3p4OGdnYlU
> [3]
> https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/12.0/
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

PVS-Studio Analyzer Spots Bugs In the FreeBSD 2017 edition

[Tommi Pernila]

Hi all,

just a heads up if you haven't yet seen this blog post from Andrey Karpov
from PVS-Studio.
It's a quite a long read.
https://www.viva64.com/en/b/0496/

Here's a few highlights (with some paraphrasing).

>PVS-Studio fixed errors where it's clear how to fix them without digging
deep into the algorithms.
>That's why FreeBSD authors should really do a deeper analysis themselves,
>not just review that limited number of errors that we presented.

>Andrey Karpov is ready to provide a temporary license key and also help to
eliminate false positives that may hinder their work.

Anyone up for this task?


>FreeBSD code is regularly checked by Coverity (which is now a part of
Synopsys).
>Still, it didn't prevent me from finding 56 potential vulnerabilities and
10 more real bugs in one evening by running PVS-Studio on this code.


Br,

Tommi
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD 11.0 RC1 kernel panic with iwm firmware

[Tommi Pernila]

Here is a link to the Fatal trap image
http://imgur.com/gallery/NjoEF

Br,

Tommi

On Aug 23, 2016 20:26, "Tommi Pernila" <tommi.pern...@iki.fi> wrote:
>
> Hi all,
>
> just installed RC1 on my T540 Thinkpad.
> I installed some tools did a few reboots, then added the laptops wireless
Intel 7260 firmware to /boot/loader.conf
>
> iwm7260fw_load="YES"
> if_iwm_load="YES"
>
> (think i put them i this order, shouldn't matter?)
>
> after a reboot unlocked my Geli and selected the default boot options.
>
> Next i see the usual text scrolling by, see a glimpse of iwm driver.
> Then
>
> Fatal trap 12: page fault while in kernel mode
> (with more info... )
>
> then the machine reboots.
>
> Next tried single user mode and safe mode, with the same results.
>
> I managed to take a picture of the last lines before a reboot.
> I'll send a link to it in a minute.
>
>
> How to remove these kernel modules from a Geli encrypted harddisk?
>
> Or what other method should be used to correct the situation?
>
> I can re-install the machine, just trying to learn new tricks.
>
> Br,
>
> Tommi
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

FreeBSD 11.0 RC1 kernel panic with iwm firmware

[Tommi Pernila]

Hi all,

just installed RC1 on my T540 Thinkpad.
I installed some tools did a few reboots, then added the laptops wireless
Intel 7260 firmware to /boot/loader.conf

iwm7260fw_load="YES"
if_iwm_load="YES"

(think i put them i this order, shouldn't matter?)

after a reboot unlocked my Geli and selected the default boot options.

Next i see the usual text scrolling by, see a glimpse of iwm driver.
Then

Fatal trap 12: page fault while in kernel mode
(with more info... )

then the machine reboots.

Next tried single user mode and safe mode, with the same results.

I managed to take a picture of the last lines before a reboot.
I'll send a link to it in a minute.


How to remove these kernel modules from a Geli encrypted harddisk?

Or what other method should be used to correct the situation?

I can re-install the machine, just trying to learn new tricks.

Br,

Tommi
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Samsung SSD TRIM [Was: Heads up]

[Tommi Pernila]

Hi,

On Friday, 15 April 2016, Steven Hartland  wrote:

> On 15/04/2016 09:11, Kurt Jaeger wrote:
>
>> Hi!
>>
>> avg wrote:
>>
>>> For what it's worth, I have been using the following SSDs since
>>> September of 2015 :
>>>
>>> ada2:  ACS-2 ATA SATA 3.x device
>>> ada3:  ACS-2 ATA SATA 3.x device
>>>
>> I have one in use with zfs and trim:
>>
>> ada1:  ACS-2 ATA SATA 3.x device
>>
>> Works as my ports build hosts, and is fine as far as I can see.
>>
>> Prior to Warners commit there was no NCQ TRIM support in FreeBSD, so
> while it was working with standard non-NCQ TRIM (and I can corroborate that
> as we use the 840's and 850's all over with ZFS with TRIM enabled) its
> possible that it could cause issues when NCQ TRIM comes into play.
>
> From what I read when this issue first came to light, I believe the actual
> issue was a Linux kernel bug not a FW bug in Samsung drives that caused the
> corruption. This is the thread which details said issue:
> http://www.spinics.net/lists/raid/msg49440.html
>
>
Here is a link to the commit that fixed the Linux kernel bug.
https://git.
kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f3f5da624e0a891c34d8cd513c57f1d9b0c7dadc

Mounting a Samsung SSD with a linux kernel with trim enabled without this
commit can cause issues.

Br,

Tommi


> Regards
> Steve
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CVE-2015-7547: critical bug in libc

[Tommi Pernila]

Hi,

as Shawn types faster then me...

the libc issue has been found from glibc which is not used in the BSD
family.
This is the affected libc
https://en.wikipedia.org/wiki/GNU_C_Library

What FreeBSD uses:
https://en.wikipedia.org/wiki/BSD_libc

-Tommi


On Wed, Feb 17, 2016 at 3:24 PM, O. Hartmann 
wrote:

> It is around now in the media also for non-OS developers: CVE-2015-7547
> describes a bug in libc which is supposed to affects all Linux versions.
>
> big price question: is FreeBSD > 9.3 also affected?
>
> Some reporters tell us that Linux/UNIX is affected, so sometimes this
> terminus
> is used to prevent the "Linux-nailed" view, but sometimes it also referes
> to
> everything else those people can not imagine but consider them Linux-like.
> So
> I'm a bit puzzled, since there is no report about *BSD is affected, too.
>
> Thanks in advance for shedding light onto CVE-2015-7547.
>
> Regards,
>
> oh
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CURRENT, X11 on i5-4200M Haswell and iGPU graphics HD4600: Status?

[Tommi Pernila]

Hi Oliver,

The Current branch does not yet include the latest intel drivers with the
Haswell support.
To test the latest code follow the directions on this website:
https://wiki.freebsd.org/Graphics/Update%20i915%20GPU%20driver%20to%20Linux%203.8

Br,

Tommi

> On Dec 15, 2015 17:09, "O. Hartmann"  wrote:
> >
> > I have a Lenovo ThinkPad E540 with an i5-4200M CPU and HD4600 iGPU and
> > nVidia GT740M. I tried CURRENT (FreeBSD 11.0-CURRENT #3 r292258: Tue
> > Dec 15 13:22:31 CET 2015 amd64) with most recent X11 (xorg-7.7_2,
> > xorg-drivers-7.7_3, xorg-server-1.17.4,1). kldstats reports
> >
> > Id Refs AddressSize Name
> >  1   26 0x8020 1245288  kernel
> >  22 0x81447000 7b328drm2.ko
> >  31 0x814c3000 c98c8i915kms.ko
> >
> > so I suppose KMS-capable kernel module for detecting HD4600 iGGPU is up
> > and running. The notebook has a HD4600/Optimus nVidia GT740M
> > combination, there is also a firmware switch to select between
> > "Integrated" (supposedly HD4600) and "Accerlerated" (nVidia Optimus
> > GT740M).
> >
> > I'm not able to have a graphical screen either with "intel" or "nvidia"
> > set in /usr/local/etc/X11/xorg.conf.d/xorg.conf. The Xorg.log reports
> > about " no device found".
> >
> > This incident is announced earlier due to the fact I use a vt() based
> > kernel, UEFI boot and on all systems (with IvyBridge or older) this
> > method finds the iGPU, reports some properties of the possible ports
> > available due to i915kms and then switches into a higher resolution
> > mode instead remaining in that clumsy 640x400 resolution.
> >
> > Either way what is configured in the firmware (using "Integrated" right
> > now) I'm incapable of getting any graphical screen or any indication
> > that the iGPU or the nVidia addemdum GT740M exists.
> >
> > I read about successfully installed graphical screens on recent
> > CURRENT with Haswell iGPU graphics - so am I lost with that Optimus
> > hardware? Or is CURRENT still not handling all Haswell chips?
> >
> > Kind regards,
> >
> > Oliver
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "
freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"