Re: Secure Boot
Dne 15.1.2017 v 3:38 Simon J. Gerraty napsal(a): > Johannes Lundberg wrote: >> https://wiki.freebsd.org/SecureBoot >> > Interested in this too - though for proprietary systems where we have > control over BIOS. The design should hopefully accommodate both. > > In particular any plan for how the loader would verify kernel and any > pre-loaded modules, and kernel verify init. > Hopefully allowing for regular update of sining keys. > To work correctly, there are requirements to use TPM 1.2, hard disk drive support Opal 2.1 standard and the Intel TXT. Shim is only part of secure boot, because can be easily defeated without the rest. https://www.kernel.org/doc/Documentation/intel_txt.txt https://software.intel.com/en-us/blogs/2012/09/25/how-to-enable-an-intel-trusted-execution-technology-capable-server http://www.intel.com/content/dam/www/public/us/en/documents/guides/intel-txt-software-development-guide.pdf http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/trusted-execution-technology-security-paper.pdf http://www.intel.com/technology/security/downloads/TrustedExec_Overview.pdf http://www.intel.com/technology/security/downloads/arch-overview.pdf signature.asc Description: OpenPGP digital signature
Re: TSC as timecounter makes system lag [-> jhb]
On 15/01/2017 10:11 AM, Jia-Shiun Li wrote: On Fri, Jan 13, 2017 at 8:26 AM, Jia-Shiun Li wrote: Hi all, since 2 or 3 weeks ago, I noticed that my old Penryn-based Intel Pentium T4200 notebook lagged a lot. System time was running a lot slower, sometimes even looked like it freezed. Keystroke repeat rate was slow too. Since system time is slow, I tried to change timecounter from default TSC to HPET. And it resumed normal immediately. Did a binary search. Turns out it was caused by r310177 "Enable EARLY_AP_STARTUP on amd64 and i386 kernels by default." r310175 does not have this issue. Removing this option from kernel config also solves it. making sure jhb notices this. -Jia-Shiun. ___ 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: vt(4) chops off the leftmost three columns
heh. As always, patches gratefully accepted. :) -adrian On 14 January 2017 at 21:07, Ernie Luzar wrote: > > You can add these things to the vt to-do list > > Change the default font to look like sc. > Add copy/paste function like sc has. > Add splash screen support like sc has. > > > > Adrian Chadd wrote: >> >> hi, >> >> no, the vt_vga backend doesn't yet do VESA. >> >> I keep meaning to sit down and fix this, but life and wifi gets in the >> way. >> >> >> -adrian >> >> >> On 14 January 2017 at 16:27, Kevin Oberman wrote: >>> >>> On Sat, Jan 14, 2017 at 2:11 PM, Adrian Chadd >>> wrote: It depends(tm). I think the VT code just does "640x480x4bpp" and lets the BIOS sort it out. A lot of things don't cope well with 640x480 these days - they try autodetecting picture edges, but a black border makes that very difficult. -adrian >>> >>> >>> Can you use vidcontrol(1) to change to something better? 1600x900, maybe? >>> (Note, I have not tried this and I know that vt does not support a lot of >>> vidcontrol functionality, but starting X sets the display to 200x56 >>> characters on my laptop.) >>> -- >>> Kevin Oberman, Part time kid herder and retired Network Engineer >>> E-mail: rkober...@gmail.com >>> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 >>> >>> On 14 January 2017 at 08:57, Matthias Andree wrote: > > Am 14.01.2017 um 00:11 schrieb Alan Somers: >> >> I take it back. The first three columns _are_ rendered, but they >> don't show up on some monitiors. It's as if those monitors require a >> minimum amount of overscan on the left side of the screen, and vt(4) >> doesn't provide enough. Can that be tuned? > > Once upon a time, I've seen similar things on Linux, but with fewer > pixels offset, when switching framebuffer drivers - back then, the > scanning-VGA-timing was an issue. Is there any way to tweak the row and > column timings, with blank periods, viewport offsets and thereabouts? > > > ___ 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: vt(4) chops off the leftmost three columns
You can add these things to the vt to-do list Change the default font to look like sc. Add copy/paste function like sc has. Add splash screen support like sc has. Adrian Chadd wrote: hi, no, the vt_vga backend doesn't yet do VESA. I keep meaning to sit down and fix this, but life and wifi gets in the way. -adrian On 14 January 2017 at 16:27, Kevin Oberman wrote: On Sat, Jan 14, 2017 at 2:11 PM, Adrian Chadd wrote: It depends(tm). I think the VT code just does "640x480x4bpp" and lets the BIOS sort it out. A lot of things don't cope well with 640x480 these days - they try autodetecting picture edges, but a black border makes that very difficult. -adrian Can you use vidcontrol(1) to change to something better? 1600x900, maybe? (Note, I have not tried this and I know that vt does not support a lot of vidcontrol functionality, but starting X sets the display to 200x56 characters on my laptop.) -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 On 14 January 2017 at 08:57, Matthias Andree wrote: Am 14.01.2017 um 00:11 schrieb Alan Somers: I take it back. The first three columns _are_ rendered, but they don't show up on some monitiors. It's as if those monitors require a minimum amount of overscan on the left side of the screen, and vt(4) doesn't provide enough. Can that be tuned? Once upon a time, I've seen similar things on Linux, but with fewer pixels offset, when switching framebuffer drivers - back then, the scanning-VGA-timing was an issue. Is there any way to tweak the row and column timings, with blank periods, viewport offsets and thereabouts? ___ 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: vt(4) chops off the leftmost three columns
hi, no, the vt_vga backend doesn't yet do VESA. I keep meaning to sit down and fix this, but life and wifi gets in the way. -adrian On 14 January 2017 at 16:27, Kevin Oberman wrote: > On Sat, Jan 14, 2017 at 2:11 PM, Adrian Chadd > wrote: >> >> It depends(tm). I think the VT code just does "640x480x4bpp" and lets >> the BIOS sort it out. A lot of things don't cope well with 640x480 >> these days - they try autodetecting picture edges, but a black border >> makes that very difficult. >> >> >> -adrian > > > Can you use vidcontrol(1) to change to something better? 1600x900, maybe? > (Note, I have not tried this and I know that vt does not support a lot of > vidcontrol functionality, but starting X sets the display to 200x56 > characters on my laptop.) > -- > Kevin Oberman, Part time kid herder and retired Network Engineer > E-mail: rkober...@gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > > >> >> On 14 January 2017 at 08:57, Matthias Andree >> wrote: >> > Am 14.01.2017 um 00:11 schrieb Alan Somers: >> >> I take it back. The first three columns _are_ rendered, but they >> >> don't show up on some monitiors. It's as if those monitors require a >> >> minimum amount of overscan on the left side of the screen, and vt(4) >> >> doesn't provide enough. Can that be tuned? >> > >> > Once upon a time, I've seen similar things on Linux, but with fewer >> > pixels offset, when switching framebuffer drivers - back then, the >> > scanning-VGA-timing was an issue. Is there any way to tweak the row and >> > column timings, with blank periods, viewport offsets and thereabouts? >> > ___ >> > 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" > > ___ 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: Secure Boot
Johannes Lundberg wrote: > https://wiki.freebsd.org/SecureBoot > Interested in this too - though for proprietary systems where we have control over BIOS. The design should hopefully accommodate both. In particular any plan for how the loader would verify kernel and any pre-loaded modules, and kernel verify init. Hopefully allowing for regular update of sining keys. ___ 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: TSC as timecounter makes system lag
On Fri, Jan 13, 2017 at 8:26 AM, Jia-Shiun Li wrote: > Hi all, > > since 2 or 3 weeks ago, I noticed that my old Penryn-based Intel Pentium > T4200 notebook lagged a lot. System time was running a lot slower, > sometimes even looked like it freezed. Keystroke repeat rate was slow too. > > Since system time is slow, I tried to change timecounter from default TSC > to HPET. And it resumed normal immediately. > > Did a binary search. Turns out it was caused by r310177 "Enable EARLY_AP_STARTUP on amd64 and i386 kernels by default." r310175 does not have this issue. Removing this option from kernel config also solves it. -Jia-Shiun. ___ 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: vt(4) chops off the leftmost three columns
On Sat, Jan 14, 2017 at 2:11 PM, Adrian Chadd wrote: > It depends(tm). I think the VT code just does "640x480x4bpp" and lets > the BIOS sort it out. A lot of things don't cope well with 640x480 > these days - they try autodetecting picture edges, but a black border > makes that very difficult. > > > -adrian > Can you use vidcontrol(1) to change to something better? 1600x900, maybe? (Note, I have not tried this and I know that vt does not support a lot of vidcontrol functionality, but starting X sets the display to 200x56 characters on my laptop.) -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > On 14 January 2017 at 08:57, Matthias Andree > wrote: > > Am 14.01.2017 um 00:11 schrieb Alan Somers: > >> I take it back. The first three columns _are_ rendered, but they > >> don't show up on some monitiors. It's as if those monitors require a > >> minimum amount of overscan on the left side of the screen, and vt(4) > >> doesn't provide enough. Can that be tuned? > > > > Once upon a time, I've seen similar things on Linux, but with fewer > > pixels offset, when switching framebuffer drivers - back then, the > > scanning-VGA-timing was an issue. Is there any way to tweak the row and > > column timings, with blank periods, viewport offsets and thereabouts? > > ___ > > 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" > ___ 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: vt(4) chops off the leftmost three columns
It depends(tm). I think the VT code just does "640x480x4bpp" and lets the BIOS sort it out. A lot of things don't cope well with 640x480 these days - they try autodetecting picture edges, but a black border makes that very difficult. -adrian On 14 January 2017 at 08:57, Matthias Andree wrote: > Am 14.01.2017 um 00:11 schrieb Alan Somers: >> I take it back. The first three columns _are_ rendered, but they >> don't show up on some monitiors. It's as if those monitors require a >> minimum amount of overscan on the left side of the screen, and vt(4) >> doesn't provide enough. Can that be tuned? > > Once upon a time, I've seen similar things on Linux, but with fewer > pixels offset, when switching framebuffer drivers - back then, the > scanning-VGA-timing was an issue. Is there any way to tweak the row and > column timings, with blank periods, viewport offsets and thereabouts? > ___ > 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"
Secure Boot
Hi It's been almost a year since the Secure Boot wiki has been updated. https://wiki.freebsd.org/SecureBoot What is the current status and roadmap? Thanks! ___ 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"
Multiple FreeBSD on same drive
Hi The most recent info I have is that the (UEFI) boot loader can only boot from the first UFS partition it finds. Has support for multiple installations been implemented? If so, how can I choose to boot from the first or second UFS partition? Thanks! ___ 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: vt(4) chops off the leftmost three columns
On Sat, Jan 14, 2017 at 4:43 AM, David Chisnall wrote: > On 13 Jan 2017, at 01:00, Ernie Luzar wrote: >> >> VT should have had better testing before becoming the default in 11.0. > > The choice was VT or no acceleration in X11, because all of the new DRI > drivers depend on KMS, which requires VT. We only got VT in a useable state > (and therefore useable accelerated X11 for most of the 10.x series) because > the Foundation funded the work. More contributions to VT are always welcome, > but the choice was not between VT or something better tested, it was between > VT and black screens. > > David I should add, BTW, that on my Haswell desktop, the only place where I care about graphics, vt(4) works great. It works better than Linux did on the same hardware. It also uses a DVI monitor, so there are no issues with the borders. -Alan ___ 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: vt(4) chops off the leftmost three columns
Am 14.01.2017 um 00:11 schrieb Alan Somers: > I take it back. The first three columns _are_ rendered, but they > don't show up on some monitiors. It's as if those monitors require a > minimum amount of overscan on the left side of the screen, and vt(4) > doesn't provide enough. Can that be tuned? Once upon a time, I've seen similar things on Linux, but with fewer pixels offset, when switching framebuffer drivers - back then, the scanning-VGA-timing was an issue. Is there any way to tweak the row and column timings, with blank periods, viewport offsets and thereabouts? ___ 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: xpt related hang on sparc64
On Fri, Jan 13, 2017 at 11:23:13PM -0700, Alan Somers wrote: > That error message can mean many different things. You need to boot > in verbose mode to get a better idea. As a test I created a netbootable image from -current the other day. All I had available to test was an X1 which booted fine. (It was just lying around anyway.) I can try one of the v210s or v215s if you continue to have trouble. mcl ___ 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: vt(4) chops off the leftmost three columns
On 13 Jan 2017, at 01:00, Ernie Luzar wrote: > > VT should have had better testing before becoming the default in 11.0. The choice was VT or no acceleration in X11, because all of the new DRI drivers depend on KMS, which requires VT. We only got VT in a useable state (and therefore useable accelerated X11 for most of the 10.x series) because the Foundation funded the work. More contributions to VT are always welcome, but the choice was not between VT or something better tested, it was between VT and black screens. David smime.p7s Description: S/MIME cryptographic signature
