Re: FreeBSD and Coreboot

2019-05-27 Thread Warner Losh
On Mon, May 27, 2019, 10:44 PM Nathan Whitehorn 
wrote:

>
>
> On 2019-05-27 19:14, Warner Losh wrote:
> > On Mon, May 27, 2019, 7:18 PM Nathan Whitehorn 
> > wrote:
> >
> >>
> >> On 2019-05-27 15:50, Eric McCorkle wrote:
> >>> On 5/27/19 5:53 PM, Edward Napierala wrote:
>  On Mon, 27 May 2019 at 16:14, Eric McCorkle 
> >> wrote:
>  [..]
> 
> > My plan is roughly this:
> >
> > * Refurbish the GRUB port, get it working again in QEMU (possibly on
> >> one
> > of my machines), also possibly push a patch to GRUB to use the
> keybufs
> > mechanism to pass in GELI keys.
> >
> > * Get coreboot with GRUB/Seabios booting FreeBSD in QEMU
> >
> > * Possibly create a coreboot port (uncertain how this would work,
> since
> > Coreboot has its own extensive config menu)
> >
> > * Hold my breath and test it out on real hardware (I have a Librem 13
> >> r1
> > for this purpose)
> >
> > * Possibly try getting the FreeBSD kernel to work as a coreboot
> >> payload.
>  Out of curiosity - why the kernel and not loader(8)?
> 
> >>> If I understand coreboot correctly, loader would have to directly
> >>> manipulate devices _without a BIOS_.  That is, it would have to have an
> >>> entire device detection/interface layer, which I don't believe is the
> >>> case today.
> >>>
> >>> At least in the EFI case, loader is talking through the system's EFI
> >>> implementation, which takes care of all that for you.  BIOS works in a
> >>> similar way.  My sense is getting loader to the point where it could be
> >>> a coreboot (without Seabios/GRUB/Tianocore) would be quite an
> >> undertaking.
> >> On IBM PowerNV systems, which also don't provide interfaces to a
> >> second-stage loader, we just abandoned loader(8). It's way too much
> work.
> >>
> > How do you use tunables and loadable modules?
> >
> > Warner
> >
>
> The firmware on PowerNV has a way to write tunables to the device-tree,
> which we rehydrate into something that looks like it came from loader.
>
> We don't usefully support loadable modules at the moment. The firmware
> can optionally load exactly one file from the boot filesystem and pass
> it to the kernel (for Linux, the initrd). There are a couple of ways to
> imagine exploiting this for kernel modules, but all of them are kind of
> crummy.
>

Now that the loader supports a ram disk, we are almost to something
useful... but yea, almost and crummy often go hand in hand.

Warner

>
___
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 and Coreboot

2019-05-27 Thread Nathan Whitehorn



On 2019-05-27 19:14, Warner Losh wrote:
> On Mon, May 27, 2019, 7:18 PM Nathan Whitehorn 
> wrote:
>
>>
>> On 2019-05-27 15:50, Eric McCorkle wrote:
>>> On 5/27/19 5:53 PM, Edward Napierala wrote:
 On Mon, 27 May 2019 at 16:14, Eric McCorkle 
>> wrote:
 [..]

> My plan is roughly this:
>
> * Refurbish the GRUB port, get it working again in QEMU (possibly on
>> one
> of my machines), also possibly push a patch to GRUB to use the keybufs
> mechanism to pass in GELI keys.
>
> * Get coreboot with GRUB/Seabios booting FreeBSD in QEMU
>
> * Possibly create a coreboot port (uncertain how this would work, since
> Coreboot has its own extensive config menu)
>
> * Hold my breath and test it out on real hardware (I have a Librem 13
>> r1
> for this purpose)
>
> * Possibly try getting the FreeBSD kernel to work as a coreboot
>> payload.
 Out of curiosity - why the kernel and not loader(8)?

>>> If I understand coreboot correctly, loader would have to directly
>>> manipulate devices _without a BIOS_.  That is, it would have to have an
>>> entire device detection/interface layer, which I don't believe is the
>>> case today.
>>>
>>> At least in the EFI case, loader is talking through the system's EFI
>>> implementation, which takes care of all that for you.  BIOS works in a
>>> similar way.  My sense is getting loader to the point where it could be
>>> a coreboot (without Seabios/GRUB/Tianocore) would be quite an
>> undertaking.
>> On IBM PowerNV systems, which also don't provide interfaces to a
>> second-stage loader, we just abandoned loader(8). It's way too much work.
>>
> How do you use tunables and loadable modules?
>
> Warner
>

The firmware on PowerNV has a way to write tunables to the device-tree,
which we rehydrate into something that looks like it came from loader.

We don't usefully support loadable modules at the moment. The firmware
can optionally load exactly one file from the boot filesystem and pass
it to the kernel (for Linux, the initrd). There are a couple of ways to
imagine exploiting this for kernel modules, but all of them are kind of
crummy.
-Nathan
___
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: Disabling COMPAT_FREEBSD4/5/6/7/9 as a default kernel option

2019-05-27 Thread Warner Losh
On Mon, May 27, 2019, 8:23 PM Enji Cooper  wrote:

>
> On May 27, 2019, at 7:20 PM, Warner Losh  wrote:
>
> On Mon, May 27, 2019, 6:49 PM Enji Cooper  wrote:
>
>>
>> > On May 27, 2019, at 08:27, rai...@ultra-secure.de wrote:
>> >
>> > Am 2019-05-27 17:05, schrieb Conrad Meyer:
>> >> Hi Rainier,
>> >> On Mon, May 27, 2019 at 7:47 AM  wrote:
>> >>> I have a 32bit FreeBSD 6 binary that I'll need for a bit until the
>> >>> department who is technically responsible for the service gets around
>> >>> redoing that service.
>> >> Even if this proposal is approved, it would only affect 13+.  You
>> >> could still run your FreeBSD 6 binary in a 32-bit 12 VM in a 13+
>> >> Bhyve.  But do consider lighting a fire under whatever department
>> >> thinks it's ok to deploy like that :-).
>> >> Take care,
>> >> Conrad
>> >
>> >
>> > I thought so, too.
>> >
>> > I don't really want to run the abandonware of a RADIUS-server any
>> longer than necessary (as absurd as that sounds).
>> >
>> > It's also running a recursive nameserver (previously also
>> authoritative) that is still hard-coded in CPE and computers behind
>> firewalls.
>> >
>> > I first wanted to virtualize it (it's not a big problem) - but this way
>> the problem is just dragged out: "But it still works, does it and we have
>> no time".
>> >
>> > Everybody now knows that the clock is ticking, literally.
>> >
>> > Oh, I also remember George Neville-Neil talking about a - what -
>> FreeBSD 4 binary that a certain search-engine had lost the sources for and
>> was running on FreeBSD 7 with compat4.
>> > (We also have a client who literally begged us to leave a decade-old
>> Solaris box running through 2019 and half of 2020 so they could continue to
>> do their bookkeeping on a home-grown java-app that I suspect they, too have
>> lost the sources to...). It's running jdk15 and getting that thing to run
>> under anything semi-decent doesn't seem to have worked-out too well.
>> > So, people pray for the best and don't prepare for the worst.
>> >
>> >
>> > Other stuff I can think of:
>> > - very old Netbackup-Clients (like 5-series), though I doubt they still
>> work on recent releases, because 7.71 (last official version and intended
>> for FreeBSD 11) stopped working on FreeBSD12, sadly)
>> > - certain pre-compiled VMWare Tools Modules? Pre open-source-tools (I
>> can never make up my mind if it's VMWare-open-Tools or Open-VMWare-Tools or
>> something different)
>> >
>> >
>> > What ever people do with COMPAT4-9 - it's bordering the pathological.
>>
>> I’ll counter the OP’s suggestion a bit:
>>
>> It would be nice if the compat options were modularized and printed out
>> an EOS warning when loaded, so the user was aware that the modules are not
>> supported by FreeBSD, in terms of security and whatnot.
>>
>
> How is that relevant? They just control system calls, not any userland
> libraries that might or might not have a security exposure. Plus, if not
> done right you either startle the horses for no reason, or you run the risk
> of a console DoS if you print something on each system call…
>
>
> My point was to suggest basically controlling the syscall table (like
> linux does for instance). If a compat module was loaded, it would print out
> the warning. Not on each syscall entry. That would be insanity as far as
> performance degradation would be concerned :/.
>

Except it would take a lot of work to make the compat options a module.
Also, we need them for the upgrade path... I'm still not convinced a
warning would be more beneficial than the concern it would generates...

Warner
___
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: Disabling COMPAT_FREEBSD4/5/6/7/9 as a default kernel option

2019-05-27 Thread Enji Cooper

> On May 27, 2019, at 7:20 PM, Warner Losh  wrote:
> 
> On Mon, May 27, 2019, 6:49 PM Enji Cooper  > wrote:
> 
> > On May 27, 2019, at 08:27, rai...@ultra-secure.de 
> >  wrote:
> > 
> > Am 2019-05-27 17:05, schrieb Conrad Meyer:
> >> Hi Rainier,
> >> On Mon, May 27, 2019 at 7:47 AM  >> > wrote:
> >>> I have a 32bit FreeBSD 6 binary that I'll need for a bit until the
> >>> department who is technically responsible for the service gets around
> >>> redoing that service.
> >> Even if this proposal is approved, it would only affect 13+.  You
> >> could still run your FreeBSD 6 binary in a 32-bit 12 VM in a 13+
> >> Bhyve.  But do consider lighting a fire under whatever department
> >> thinks it's ok to deploy like that :-).
> >> Take care,
> >> Conrad
> > 
> > 
> > I thought so, too.
> > 
> > I don't really want to run the abandonware of a RADIUS-server any longer 
> > than necessary (as absurd as that sounds).
> > 
> > It's also running a recursive nameserver (previously also authoritative) 
> > that is still hard-coded in CPE and computers behind firewalls.
> > 
> > I first wanted to virtualize it (it's not a big problem) - but this way the 
> > problem is just dragged out: "But it still works, does it and we have no 
> > time".
> > 
> > Everybody now knows that the clock is ticking, literally.
> > 
> > Oh, I also remember George Neville-Neil talking about a - what - FreeBSD 4 
> > binary that a certain search-engine had lost the sources for and was 
> > running on FreeBSD 7 with compat4.
> > (We also have a client who literally begged us to leave a decade-old 
> > Solaris box running through 2019 and half of 2020 so they could continue to 
> > do their bookkeeping on a home-grown java-app that I suspect they, too have 
> > lost the sources to...). It's running jdk15 and getting that thing to run 
> > under anything semi-decent doesn't seem to have worked-out too well.
> > So, people pray for the best and don't prepare for the worst.
> > 
> > 
> > Other stuff I can think of:
> > - very old Netbackup-Clients (like 5-series), though I doubt they still 
> > work on recent releases, because 7.71 (last official version and intended 
> > for FreeBSD 11) stopped working on FreeBSD12, sadly)
> > - certain pre-compiled VMWare Tools Modules? Pre open-source-tools (I can 
> > never make up my mind if it's VMWare-open-Tools or Open-VMWare-Tools or 
> > something different)
> > 
> > 
> > What ever people do with COMPAT4-9 - it's bordering the pathological.
> 
> I’ll counter the OP’s suggestion a bit:
> 
> It would be nice if the compat options were modularized and printed out an 
> EOS warning when loaded, so the user was aware that the modules are not 
> supported by FreeBSD, in terms of security and whatnot.
> 
> How is that relevant? They just control system calls, not any userland 
> libraries that might or might not have a security exposure. Plus, if not done 
> right you either startle the horses for no reason, or you run the risk of a 
> console DoS if you print something on each system call…

My point was to suggest basically controlling the syscall table (like linux 
does for instance). If a compat module was loaded, it would print out the 
warning. Not on each syscall entry. That would be insanity as far as 
performance degradation would be concerned :/.
-Enji

___
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: Disabling COMPAT_FREEBSD4/5/6/7/9 as a default kernel option

2019-05-27 Thread Warner Losh
On Mon, May 27, 2019, 6:49 PM Enji Cooper  wrote:

>
> > On May 27, 2019, at 08:27, rai...@ultra-secure.de wrote:
> >
> > Am 2019-05-27 17:05, schrieb Conrad Meyer:
> >> Hi Rainier,
> >> On Mon, May 27, 2019 at 7:47 AM  wrote:
> >>> I have a 32bit FreeBSD 6 binary that I'll need for a bit until the
> >>> department who is technically responsible for the service gets around
> >>> redoing that service.
> >> Even if this proposal is approved, it would only affect 13+.  You
> >> could still run your FreeBSD 6 binary in a 32-bit 12 VM in a 13+
> >> Bhyve.  But do consider lighting a fire under whatever department
> >> thinks it's ok to deploy like that :-).
> >> Take care,
> >> Conrad
> >
> >
> > I thought so, too.
> >
> > I don't really want to run the abandonware of a RADIUS-server any longer
> than necessary (as absurd as that sounds).
> >
> > It's also running a recursive nameserver (previously also authoritative)
> that is still hard-coded in CPE and computers behind firewalls.
> >
> > I first wanted to virtualize it (it's not a big problem) - but this way
> the problem is just dragged out: "But it still works, does it and we have
> no time".
> >
> > Everybody now knows that the clock is ticking, literally.
> >
> > Oh, I also remember George Neville-Neil talking about a - what - FreeBSD
> 4 binary that a certain search-engine had lost the sources for and was
> running on FreeBSD 7 with compat4.
> > (We also have a client who literally begged us to leave a decade-old
> Solaris box running through 2019 and half of 2020 so they could continue to
> do their bookkeeping on a home-grown java-app that I suspect they, too have
> lost the sources to...). It's running jdk15 and getting that thing to run
> under anything semi-decent doesn't seem to have worked-out too well.
> > So, people pray for the best and don't prepare for the worst.
> >
> >
> > Other stuff I can think of:
> > - very old Netbackup-Clients (like 5-series), though I doubt they still
> work on recent releases, because 7.71 (last official version and intended
> for FreeBSD 11) stopped working on FreeBSD12, sadly)
> > - certain pre-compiled VMWare Tools Modules? Pre open-source-tools (I
> can never make up my mind if it's VMWare-open-Tools or Open-VMWare-Tools or
> something different)
> >
> >
> > What ever people do with COMPAT4-9 - it's bordering the pathological.
>
> I’ll counter the OP’s suggestion a bit:
>
> It would be nice if the compat options were modularized and printed out an
> EOS warning when loaded, so the user was aware that the modules are not
> supported by FreeBSD, in terms of security and whatnot.
>

How is that relevant? They just control system calls, not any userland
libraries that might or might not have a security exposure. Plus, if not
done right you either startle the horses for no reason, or you run the risk
of a console DoS if you print something on each system call...

Warner

Thanks!
> -Enji
> ___
> 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: FreeBSD and Coreboot

2019-05-27 Thread Warner Losh
On Mon, May 27, 2019, 7:18 PM Nathan Whitehorn 
wrote:

>
>
> On 2019-05-27 15:50, Eric McCorkle wrote:
> > On 5/27/19 5:53 PM, Edward Napierala wrote:
> >> On Mon, 27 May 2019 at 16:14, Eric McCorkle 
> wrote:
> >>
> >> [..]
> >>
> >>> My plan is roughly this:
> >>>
> >>> * Refurbish the GRUB port, get it working again in QEMU (possibly on
> one
> >>> of my machines), also possibly push a patch to GRUB to use the keybufs
> >>> mechanism to pass in GELI keys.
> >>>
> >>> * Get coreboot with GRUB/Seabios booting FreeBSD in QEMU
> >>>
> >>> * Possibly create a coreboot port (uncertain how this would work, since
> >>> Coreboot has its own extensive config menu)
> >>>
> >>> * Hold my breath and test it out on real hardware (I have a Librem 13
> r1
> >>> for this purpose)
> >>>
> >>> * Possibly try getting the FreeBSD kernel to work as a coreboot
> payload.
> >> Out of curiosity - why the kernel and not loader(8)?
> >>
> > If I understand coreboot correctly, loader would have to directly
> > manipulate devices _without a BIOS_.  That is, it would have to have an
> > entire device detection/interface layer, which I don't believe is the
> > case today.
> >
> > At least in the EFI case, loader is talking through the system's EFI
> > implementation, which takes care of all that for you.  BIOS works in a
> > similar way.  My sense is getting loader to the point where it could be
> > a coreboot (without Seabios/GRUB/Tianocore) would be quite an
> undertaking.
> >
>
> On IBM PowerNV systems, which also don't provide interfaces to a
> second-stage loader, we just abandoned loader(8). It's way too much work.
>

How do you use tunables and loadable modules?

Warner

>
___
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 and Coreboot

2019-05-27 Thread Nathan Whitehorn


On 2019-05-27 15:50, Eric McCorkle wrote:
> On 5/27/19 5:53 PM, Edward Napierala wrote:
>> On Mon, 27 May 2019 at 16:14, Eric McCorkle  wrote:
>>
>> [..]
>>
>>> My plan is roughly this:
>>>
>>> * Refurbish the GRUB port, get it working again in QEMU (possibly on one
>>> of my machines), also possibly push a patch to GRUB to use the keybufs
>>> mechanism to pass in GELI keys.
>>>
>>> * Get coreboot with GRUB/Seabios booting FreeBSD in QEMU
>>>
>>> * Possibly create a coreboot port (uncertain how this would work, since
>>> Coreboot has its own extensive config menu)
>>>
>>> * Hold my breath and test it out on real hardware (I have a Librem 13 r1
>>> for this purpose)
>>>
>>> * Possibly try getting the FreeBSD kernel to work as a coreboot payload.
>> Out of curiosity - why the kernel and not loader(8)?
>>
> If I understand coreboot correctly, loader would have to directly
> manipulate devices _without a BIOS_.  That is, it would have to have an
> entire device detection/interface layer, which I don't believe is the
> case today.
>
> At least in the EFI case, loader is talking through the system's EFI
> implementation, which takes care of all that for you.  BIOS works in a
> similar way.  My sense is getting loader to the point where it could be
> a coreboot (without Seabios/GRUB/Tianocore) would be quite an undertaking.
>

On IBM PowerNV systems, which also don't provide interfaces to a
second-stage loader, we just abandoned loader(8). It's way too much work.
-Nathan



signature.asc
Description: OpenPGP digital signature


Re: FreeBSD and Coreboot

2019-05-27 Thread Eric McCorkle
On 5/27/19 11:13 AM, Eric McCorkle wrote:

> My plan is roughly this:
> 
> * Refurbish the GRUB port, get it working again in QEMU (possibly on one
> of my machines), also possibly push a patch to GRUB to use the keybufs
> mechanism to pass in GELI keys.

I managed to get the grub2 port compiling against 2.02 (latest release)
in an afternoon's worth of work.  Note: the --force-label flag on
grub-install isn't presently implemented; I'll need to dig deeper into
the code to get that working.

I haven't tried to see if it works yet.  You can follow my work on the
grub2 branch of my freebsd-ports fork:

https://github.com/emc2/freebsd-ports/tree/grub2

Also, I am potentially willing to take over maintenance of the port,
assuming the volume of work isn't too high.



signature.asc
Description: OpenPGP digital signature


Re: Disabling COMPAT_FREEBSD4/5/6/7/9 as a default kernel option

2019-05-27 Thread Enji Cooper

> On May 27, 2019, at 08:27, rai...@ultra-secure.de wrote:
> 
> Am 2019-05-27 17:05, schrieb Conrad Meyer:
>> Hi Rainier,
>> On Mon, May 27, 2019 at 7:47 AM  wrote:
>>> I have a 32bit FreeBSD 6 binary that I'll need for a bit until the
>>> department who is technically responsible for the service gets around
>>> redoing that service.
>> Even if this proposal is approved, it would only affect 13+.  You
>> could still run your FreeBSD 6 binary in a 32-bit 12 VM in a 13+
>> Bhyve.  But do consider lighting a fire under whatever department
>> thinks it's ok to deploy like that :-).
>> Take care,
>> Conrad
> 
> 
> I thought so, too.
> 
> I don't really want to run the abandonware of a RADIUS-server any longer than 
> necessary (as absurd as that sounds).
> 
> It's also running a recursive nameserver (previously also authoritative) that 
> is still hard-coded in CPE and computers behind firewalls.
> 
> I first wanted to virtualize it (it's not a big problem) - but this way the 
> problem is just dragged out: "But it still works, does it and we have no 
> time".
> 
> Everybody now knows that the clock is ticking, literally.
> 
> Oh, I also remember George Neville-Neil talking about a - what - FreeBSD 4 
> binary that a certain search-engine had lost the sources for and was running 
> on FreeBSD 7 with compat4.
> (We also have a client who literally begged us to leave a decade-old Solaris 
> box running through 2019 and half of 2020 so they could continue to do their 
> bookkeeping on a home-grown java-app that I suspect they, too have lost the 
> sources to...). It's running jdk15 and getting that thing to run under 
> anything semi-decent doesn't seem to have worked-out too well.
> So, people pray for the best and don't prepare for the worst.
> 
> 
> Other stuff I can think of:
> - very old Netbackup-Clients (like 5-series), though I doubt they still work 
> on recent releases, because 7.71 (last official version and intended for 
> FreeBSD 11) stopped working on FreeBSD12, sadly)
> - certain pre-compiled VMWare Tools Modules? Pre open-source-tools (I can 
> never make up my mind if it's VMWare-open-Tools or Open-VMWare-Tools or 
> something different)
> 
> 
> What ever people do with COMPAT4-9 - it's bordering the pathological.

I’ll counter the OP’s suggestion a bit:

It would be nice if the compat options were modularized and printed out an EOS 
warning when loaded, so the user was aware that the modules are not supported 
by FreeBSD, in terms of security and whatnot.

Thanks!
-Enji
___
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 and Coreboot

2019-05-27 Thread Eric McCorkle
On 5/27/19 5:53 PM, Edward Napierala wrote:
> On Mon, 27 May 2019 at 16:14, Eric McCorkle  wrote:
> 
> [..]
> 
>> My plan is roughly this:
>>
>> * Refurbish the GRUB port, get it working again in QEMU (possibly on one
>> of my machines), also possibly push a patch to GRUB to use the keybufs
>> mechanism to pass in GELI keys.
>>
>> * Get coreboot with GRUB/Seabios booting FreeBSD in QEMU
>>
>> * Possibly create a coreboot port (uncertain how this would work, since
>> Coreboot has its own extensive config menu)
>>
>> * Hold my breath and test it out on real hardware (I have a Librem 13 r1
>> for this purpose)
>>
>> * Possibly try getting the FreeBSD kernel to work as a coreboot payload.
> 
> Out of curiosity - why the kernel and not loader(8)?
> 

If I understand coreboot correctly, loader would have to directly
manipulate devices _without a BIOS_.  That is, it would have to have an
entire device detection/interface layer, which I don't believe is the
case today.

At least in the EFI case, loader is talking through the system's EFI
implementation, which takes care of all that for you.  BIOS works in a
similar way.  My sense is getting loader to the point where it could be
a coreboot (without Seabios/GRUB/Tianocore) would be quite an undertaking.



signature.asc
Description: OpenPGP digital signature


Re: FreeBSD and Coreboot

2019-05-27 Thread Edward Napierala
On Mon, 27 May 2019 at 16:14, Eric McCorkle  wrote:

[..]

> My plan is roughly this:
>
> * Refurbish the GRUB port, get it working again in QEMU (possibly on one
> of my machines), also possibly push a patch to GRUB to use the keybufs
> mechanism to pass in GELI keys.
>
> * Get coreboot with GRUB/Seabios booting FreeBSD in QEMU
>
> * Possibly create a coreboot port (uncertain how this would work, since
> Coreboot has its own extensive config menu)
>
> * Hold my breath and test it out on real hardware (I have a Librem 13 r1
> for this purpose)
>
> * Possibly try getting the FreeBSD kernel to work as a coreboot payload.

Out of curiosity - why the kernel and not loader(8)?
___
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 CI Weekly Report 2019-05-26

2019-05-27 Thread Li-Wen Hsu
(Please send the followup discussions to freebsd-testing@ list.)

FreeBSD CI Weekly Report 2019-05-26
===

Here is a summary of the FreeBSD Continuous Integration results for
the period from 2019-05-20 to 2019-05-26.

During this period, we have:

* 2273 builds (97% passed, 3% failed) were executed on aarch64, amd64,
armv6, armv7, i386, mips, mips64, powerpc, powerpc64, powerpcspe,
riscv64, sparc64 architectures for head, stable/12, stable/11
branches.
* test runs (% passed, % unstable, % exception) were executed on
amd64, i386, riscv64 architectures for head, stable/12, stable/11
branches.
* 21 doc builds (100% passed)

(The statistics from experimental jobs are omitted)

If any of the issues found by CI are in your area of interest or
expertise please investigate the PRs listed below.

The latest web version of this report is available at
https://hackmd.io/s/HyiX1HETN and archive is available at
http://hackfoldr.org/freebsd-ci-report/, any help is welcome.

## Failing Tests

* https://ci.freebsd.org/job/FreeBSD-head-amd64-test/
* sys.geom.class.eli.init_test.init
* sys.geom.class.eli.init_test.init_a
* sys.geom.class.eli.init_test.init_alias
* sys.geom.class.eli.integrity_test.copy
* sys.geom.class.eli.integrity_test.data
* sys.geom.class.eli.integrity_test.hmac
  Those geli(8) test cases are failing because some algorithms are
deprecated in r348206 and the return value and output are changed.
The fix to the test cases are under development.
* sys.netinet.socket_afinet.socket_afinet_bind_zero
  Affected by mac_portacl(4), which is loaded by MAC tests. Need
to specify AF_INET to workaround and fix is being discussed.

* https://ci.freebsd.org/job/FreeBSD-head-i386-test/
* i386 test is current suffering from loading ipsec(4) kernel
module, which is needed after
https://svnweb.freebsd.org/changeset/base/347410 ,  causes kernel
panic.
For more information, see:
* https://bugs.freebsd.org/238012
* https://bugs.freebsd.org/230857
* https://reviews.freebsd.org/D17512
* Same as amd64:
* sys.geom.class.eli.init_test.init
* sys.geom.class.eli.init_test.init_a
* sys.geom.class.eli.init_test.init_alias
* sys.geom.class.eli.integrity_test.copy
* sys.geom.class.eli.integrity_test.data
* sys.geom.class.eli.integrity_test.hmac
* sys.netinet.socket_afinet.socket_afinet_bind_zero
* Others:
* sys.netpfil.pf.forward.v6
* sys.netpfil.pf.forward.v4
* sys.netpfil.pf.set_tos.v4
* sys.opencrypto.runtests.main

* https://ci.freebsd.org/job/FreeBSD-stable-12-i386-test/
* sys.netpfil.pf.forward.v6
* sys.netpfil.pf.forward.v4
* sys.netpfil.pf.set_tos.v4
* lib.libc.regex.exhaust_test.regcomp_too_big
* lib.libregex.exhaust_test.regcomp_too_big
* sys.opencrypto.runtests.main
  Failed with:
  ```
File "/usr/tests/sys/opencrypto/cryptodev.py", line 179, in __init__
  ioctl(_cryptodev, CIOCGSESSION2, s, 1)
  IOError: [Errno 22] Invalid argument
  ```

* https://ci.freebsd.org/job/FreeBSD-stable-11-i386-test/
* local.kyua.* (31 cases)
* local.lutok.* (3 cases)

## Failing and Flaky Tests (from experimental jobs)

* https://ci.freebsd.org/job/FreeBSD-head-amd64-dtrace_test/
* There are ~980 test cases failure with message:
`dtrace: failed to compile script err.D_AGG_SCALAR.maxnoarg.d:
[D_UNKNOWN] "/usr/lib/dtrace/mbuf.d", line 114: failed to copy type of
'm_data': Type information is in parent and unavailable`
* Flakey test case: common.misc.t_dtrace_contrib.tst_dynopt_d
  https://bugs.freebsd.org/237641

* https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/
* This job is currently suffering from timeout because of
https://bugs.freebsd.org/237652
* There are ~60 failing cases, including flakey ones, see
https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/lastCompletedBuild/testReport/
for more details

## Disabled Tests

* lib.libc.sys.mmap_test.mmap_truncate_signal
  https://bugs.freebsd.org/211924
* sys.fs.tmpfs.mount_test.large
  https://bugs.freebsd.org/212862
* sys.fs.tmpfs.link_test.kqueue
  https://bugs.freebsd.org/213662
* sys.kqueue.libkqueue.kqueue_test.main
  https://bugs.freebsd.org/233586
* usr.bin.procstat.procstat_test.command_loogle.com/ine_arguments
  https://bugs.freebsd.org/233587
* usr.bin.procstat.procstat_test.environment
  https://bugs.freebsd.org/233588

## Open Issues

* https://bugs.freebsd.org/237077 possible race in build:
/usr/src/sys/amd64/linux/linux_support.s:38:2: error: expected
relocatable expression
* https://bugs.freebsd.org/237403 Tests in sys/opencrypto should be
converted to Python3
* https://bugs.freebsd.org/237641 Flakey test case:
common.misc.t_dtrace_contrib.tst_dynopt_d
* https://bugs.freebsd.org/237652
tests.hotspare.hotspare_test.hotspare_snapshot_001_pos timeout since
somewhere in (r346814, r 346845]
* 

Re: FreeBSD and Coreboot

2019-05-27 Thread Matthias Apitz
El día Monday, May 27, 2019 a las 11:13:46AM -0400, Eric McCorkle escribió:

> Hello everyone,
> 
> I'm through enough of my job change that I can start working on FreeBSD
> again.  One thing I've had on my list to examine is using FreeBSD with
> coreboot, so I wanted to put out a call for anyone who has done work on
> this, or knows anything about it.

Hello Eric,

I don't know if this is something which has to do with your project.
Since 2015 I use an Acer C720 Chromebook with FreeBSD (CURRENT) this has
AFAIK coreboot with SeaBIOS and works just fine.

Just to let you know.

matthias

-- 
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
May, 9: Спаси́бо освободители! Thank you very much, Russian liberators!
___
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 and Coreboot

2019-05-27 Thread Kurt Jaeger
Hi!

> * The PC Engines boards evidently use coreboot, and I've heard multiple
> reports of them running FreeBSD systems without a problem.

I have approx. 130 of the PC Engines APUs in varius
versions up until the most recent, running with FreeBSD just fine.

No special setup, just the generic coreboot firmware.
Well, they had some issues with 12.0-REL booting from USB sticks
Booting 11.2 sticks, installing and upgrading works fine.
Did not test more recent firmware.

This worked to reflash the BIOS to their most recent versions:

Source of the BIOS:

https://pcengines.github.io/

I used 

flashrom -w apu4_v4.9.0.5.rom  --programmer internal

to upgrade:

Found Winbond flash chip "W25Q64.V" (8192 kB, SPI) mapped at physical address 
0xff80.

/usr/local/bin/flashrom was installed by package flashrom-1.0_1

-- 
p...@opsec.eu+49 171 3101372One year to go !
___
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 and Coreboot

2019-05-27 Thread Karl Denninger
On 5/27/2019 10:13, Eric McCorkle wrote:
> Hello everyone,
>
> I'm through enough of my job change that I can start working on FreeBSD
> again.  One thing I've had on my list to examine is using FreeBSD with
> coreboot, so I wanted to put out a call for anyone who has done work on
> this, or knows anything about it.
>
> Here is what I know:
>
> * Coreboot _can_ boot kernels directly, but this requires two things: 1)
> you must flash your BIOS every time you update a kernel, 2) the kernel
> must be able to work without the usual device initialization that the
> BIOS does.
>
> * Coreboot has two significant payload options beyond a kernel: Seabios
> and GRUB (supposedly Tianocore EFI is an option, but it apparently
> doesn't really work).
>
> * Scrounging the coreboot wiki seems to produce some conflicting
> information.  One page claims that the FreeBSD kernel can boot directly
> as a coreboot payload; another claims GRUB or Seabios to be the only
> options.
>
> * The PC Engines boards evidently use coreboot, and I've heard multiple
> reports of them running FreeBSD systems without a problem.  I don't know
> whether they use GRUB or Seabios.  (Aside: I'm thinking about ordering
> some of these boards for my own use, so I'm generally interested in how
> well they function with FreeBSD)
>
PCEngines machines run just fine with FreeBSD; I use and support a bunch
of them around here for various purposes, mostly as edge firewall and
gateway devices.
-- 
Karl Denninger
k...@denninger.net 
/The Market Ticker/
/[S/MIME encrypted email preferred]/


smime.p7s
Description: S/MIME Cryptographic Signature


Re: Disabling COMPAT_FREEBSD4/5/6/7/9 as a default kernel option

2019-05-27 Thread rainer

Am 2019-05-27 17:05, schrieb Conrad Meyer:

Hi Rainier,

On Mon, May 27, 2019 at 7:47 AM  wrote:

I have a 32bit FreeBSD 6 binary that I'll need for a bit until the
department who is technically responsible for the service gets around
redoing that service.


Even if this proposal is approved, it would only affect 13+.  You
could still run your FreeBSD 6 binary in a 32-bit 12 VM in a 13+
Bhyve.  But do consider lighting a fire under whatever department
thinks it's ok to deploy like that :-).

Take care,
Conrad



I thought so, too.

I don't really want to run the abandonware of a RADIUS-server any longer 
than necessary (as absurd as that sounds).


It's also running a recursive nameserver (previously also authoritative) 
that is still hard-coded in CPE and computers behind firewalls.


I first wanted to virtualize it (it's not a big problem) - but this way 
the problem is just dragged out: "But it still works, does it and we 
have no time".


Everybody now knows that the clock is ticking, literally.

Oh, I also remember George Neville-Neil talking about a - what - FreeBSD 
4 binary that a certain search-engine had lost the sources for and was 
running on FreeBSD 7 with compat4.
(We also have a client who literally begged us to leave a decade-old 
Solaris box running through 2019 and half of 2020 so they could continue 
to do their bookkeeping on a home-grown java-app that I suspect they, 
too have lost the sources to...). It's running jdk15 and getting that 
thing to run under anything semi-decent doesn't seem to have worked-out 
too well.

So, people pray for the best and don't prepare for the worst.


Other stuff I can think of:
 - very old Netbackup-Clients (like 5-series), though I doubt they still 
work on recent releases, because 7.71 (last official version and 
intended for FreeBSD 11) stopped working on FreeBSD12, sadly)
 - certain pre-compiled VMWare Tools Modules? Pre open-source-tools (I 
can never make up my mind if it's VMWare-open-Tools or Open-VMWare-Tools 
or something different)



What ever people do with COMPAT4-9 - it's bordering the pathological.




___
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 and Coreboot

2019-05-27 Thread Shawn Webb
Hey Eric,

My response is inline.

On Mon, May 27, 2019 at 11:13:46AM -0400, Eric McCorkle wrote:
> Hello everyone,
> 
> I'm through enough of my job change that I can start working on FreeBSD
> again.  One thing I've had on my list to examine is using FreeBSD with
> coreboot, so I wanted to put out a call for anyone who has done work on
> this, or knows anything about it.
> 
> Here is what I know:
> 
> * Coreboot _can_ boot kernels directly, but this requires two things: 1)
> you must flash your BIOS every time you update a kernel, 2) the kernel
> must be able to work without the usual device initialization that the
> BIOS does.
> 
> * Coreboot has two significant payload options beyond a kernel: Seabios
> and GRUB (supposedly Tianocore EFI is an option, but it apparently
> doesn't really work).
> 
> * Scrounging the coreboot wiki seems to produce some conflicting
> information.  One page claims that the FreeBSD kernel can boot directly
> as a coreboot payload; another claims GRUB or Seabios to be the only
> options.
> 
> * The PC Engines boards evidently use coreboot, and I've heard multiple
> reports of them running FreeBSD systems without a problem.  I don't know
> whether they use GRUB or Seabios.  (Aside: I'm thinking about ordering
> some of these boards for my own use, so I'm generally interested in how
> well they function with FreeBSD)

I own several PC Engines APU boards. They definitely use Coreboot as
maintained by these peeps: https://twitter.com/3mdeb_com

The Coreboot for the APU boards uses Seabios.

> 
> 
> My plan is roughly this:
> 
> * Refurbish the GRUB port, get it working again in QEMU (possibly on one
> of my machines), also possibly push a patch to GRUB to use the keybufs
> mechanism to pass in GELI keys.
> 
> * Get coreboot with GRUB/Seabios booting FreeBSD in QEMU
> 
> * Possibly create a coreboot port (uncertain how this would work, since
> Coreboot has its own extensive config menu)
> 
> * Hold my breath and test it out on real hardware (I have a Librem 13 r1
> for this purpose)
> 
> * Possibly try getting the FreeBSD kernel to work as a coreboot payload.
> 
> 
> Here's what I don't know/what would be useful knowledge for me:
> 
> * Anyone else who's been experimenting/working on coreboot support, and
> what they found
> 
> * Any working examples of using Coreboot with FreeBSD
> 
> * Down the road, anything about adapting the FreeBSD kernel to work with
> a new boot platform (ie. low level details about how to set it up in
> memory on a bare-metal system and start execution)
> 

Reach out to 3mdeb (feel free to CC me, if you'd like). See what
they'd like help with. There's certainly a lot more work that could be
done.

Thanks,

-- 
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

Tor-ified Signal:+1 443-546-8752
Tor+XMPP+OTR:latt...@is.a.hacker.sx
GPG Key ID:  0xFF2E67A277F8E1FA
GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9  3633 C85B 0AF8 AB23 0FB2


signature.asc
Description: PGP signature


FreeBSD and Coreboot

2019-05-27 Thread Eric McCorkle
Hello everyone,

I'm through enough of my job change that I can start working on FreeBSD
again.  One thing I've had on my list to examine is using FreeBSD with
coreboot, so I wanted to put out a call for anyone who has done work on
this, or knows anything about it.

Here is what I know:

* Coreboot _can_ boot kernels directly, but this requires two things: 1)
you must flash your BIOS every time you update a kernel, 2) the kernel
must be able to work without the usual device initialization that the
BIOS does.

* Coreboot has two significant payload options beyond a kernel: Seabios
and GRUB (supposedly Tianocore EFI is an option, but it apparently
doesn't really work).

* Scrounging the coreboot wiki seems to produce some conflicting
information.  One page claims that the FreeBSD kernel can boot directly
as a coreboot payload; another claims GRUB or Seabios to be the only
options.

* The PC Engines boards evidently use coreboot, and I've heard multiple
reports of them running FreeBSD systems without a problem.  I don't know
whether they use GRUB or Seabios.  (Aside: I'm thinking about ordering
some of these boards for my own use, so I'm generally interested in how
well they function with FreeBSD)


My plan is roughly this:

* Refurbish the GRUB port, get it working again in QEMU (possibly on one
of my machines), also possibly push a patch to GRUB to use the keybufs
mechanism to pass in GELI keys.

* Get coreboot with GRUB/Seabios booting FreeBSD in QEMU

* Possibly create a coreboot port (uncertain how this would work, since
Coreboot has its own extensive config menu)

* Hold my breath and test it out on real hardware (I have a Librem 13 r1
for this purpose)

* Possibly try getting the FreeBSD kernel to work as a coreboot payload.


Here's what I don't know/what would be useful knowledge for me:

* Anyone else who's been experimenting/working on coreboot support, and
what they found

* Any working examples of using Coreboot with FreeBSD

* Down the road, anything about adapting the FreeBSD kernel to work with
a new boot platform (ie. low level details about how to set it up in
memory on a bare-metal system and start execution)



signature.asc
Description: OpenPGP digital signature


Re: Disabling COMPAT_FREEBSD4/5/6/7/9 as a default kernel option

2019-05-27 Thread Konstantin Belousov
On Mon, May 27, 2019 at 03:55:21PM +0200, voida...@420blaze.it wrote:
> Hello,
> I wanted to discuss about bug 231768 a bit: it is about keeping 
> COMPAT_FREEBSD4/5/6/7/9 on by default in the kernel configs.
What problem are you trying to solve ?

> 
> The patch attached for the bug is for disabling these options by 
> default, following a few reasons which I'm going to list here:
>  - Keeping support for deprecated libraries isn't exactly the best we 
> could do to avoid security issues (if there are any) as I'm sure nobody 
> wants to spend that much time maintaining such stuff (it's enough to 
> think about misc/compat4x in the ports tree: that version of FreeBSD was 
> released on March 2000 and keeping 19 years old libraries around isn't 
> ideal)
>  - Devs should get track of time and realize that developing software 
> using unsupported libraries is NOT something that you should do
This is nonsense.  These options are not for developing new software.

>  - Only a tiny fraction of the ports need COMPAT_FREEBSD9 or older: 
> if the software won't compile without the legacy components (and has a 
> replacement of some kind), considering removal wouldn't be a bad idea
And that options are usually not about ports.

>  - This is on by default: most users don't care or don't use binaries 
> that old
This is I am really interesting about.  How do you know ?  The method
you came to this conclusion should allow us to solve many other old
issues, I hope.

> 
> I don't see any practical reason to keep these options on by default, 
> but I do appreciate any sort of input regarding this issue.

___
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: Disabling COMPAT_FREEBSD4/5/6/7/9 as a default kernel option

2019-05-27 Thread Conrad Meyer
Hi Rainier,

On Mon, May 27, 2019 at 7:47 AM  wrote:
> I have a 32bit FreeBSD 6 binary that I'll need for a bit until the
> department who is technically responsible for the service gets around
> redoing that service.

Even if this proposal is approved, it would only affect 13+.  You
could still run your FreeBSD 6 binary in a 32-bit 12 VM in a 13+
Bhyve.  But do consider lighting a fire under whatever department
thinks it's ok to deploy like that :-).

Take care,
Conrad
___
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: Disabling COMPAT_FREEBSD4/5/6/7/9 as a default kernel option

2019-05-27 Thread rainer

Am 2019-05-27 15:55, schrieb voida...@420blaze.it:

Hello,
I wanted to discuss about bug 231768 a bit: it is about keeping
COMPAT_FREEBSD4/5/6/7/9 on by default in the kernel configs.

The patch attached for the bug is for disabling these options by
default, following a few reasons which I'm going to list here:
- Keeping support for deprecated libraries isn't exactly the best
we could do to avoid security issues (if there are any) as I'm sure
nobody wants to spend that much time maintaining such stuff (it's
enough to think about misc/compat4x in the ports tree: that version of
FreeBSD was released on March 2000 and keeping 19 years old libraries
around isn't ideal)
- Devs should get track of time and realize that developing
software using unsupported libraries is NOT something that you should
do
- Only a tiny fraction of the ports need COMPAT_FREEBSD9 or older:
if the software won't compile without the legacy components (and has a
replacement of some kind), considering removal wouldn't be a bad idea
- This is on by default: most users don't care or don't use
binaries that old

I don't see any practical reason to keep these options on by default,
but I do appreciate any sort of input regarding this issue.



I have a 32bit FreeBSD 6 binary that I'll need for a bit until the 
department who is technically responsible for the service gets around 
redoing that service.



___
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"


Disabling COMPAT_FREEBSD4/5/6/7/9 as a default kernel option

2019-05-27 Thread voidanix

Hello,
I wanted to discuss about bug 231768 a bit: it is about keeping 
COMPAT_FREEBSD4/5/6/7/9 on by default in the kernel configs.


The patch attached for the bug is for disabling these options by 
default, following a few reasons which I'm going to list here:
- Keeping support for deprecated libraries isn't exactly the best we 
could do to avoid security issues (if there are any) as I'm sure nobody 
wants to spend that much time maintaining such stuff (it's enough to 
think about misc/compat4x in the ports tree: that version of FreeBSD was 
released on March 2000 and keeping 19 years old libraries around isn't 
ideal)
- Devs should get track of time and realize that developing software 
using unsupported libraries is NOT something that you should do
- Only a tiny fraction of the ports need COMPAT_FREEBSD9 or older: 
if the software won't compile without the legacy components (and has a 
replacement of some kind), considering removal wouldn't be a bad idea
- This is on by default: most users don't care or don't use binaries 
that old


I don't see any practical reason to keep these options on by default, 
but I do appreciate any sort of input regarding this issue.


- voidanix
___
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"