Re: buildkernel ULE related breakage

[Ngie Cooper]

On Thu, Feb 18, 2016 at 2:10 PM, Michal Suszko  wrote:
>
> Hi,
> Got this error compiling GENERIC with s/4BSD/ULE/ on recent -CURRENT
> ( wrapped long lines )
>
> cc -c -O -pipe -march=pentium3 -Wall -Wredundant-decls -Wnested-externs
>   -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline
>   -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I.
>   -I/usr/src/sys -I/usr/src/sys/dev -I/usr/src/sys/contrib/dev/acpica
>   -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/dev/ath
>   -I/usr/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h
>   -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2
>   -ffreestanding -Werror /usr/src/sys/kern/sched_ule.c
> cc1: warnings being treated as errors
> /usr/src/sys/kern/sched_ule.c: In function `sched_setup':
> /usr/src/sys/kern/sched_ule.c:531: warning: unused variable `i'
> *** Error code 1
>
> Stop in /usr/obj/usr/src/sys/TEST.
> *** Error code 1
>
> Stop in /usr/src.
> *** Error code 1
>
> Stop in /usr/src.

I'm not sure what you're running, but it doesn't look like untainted CURRENT.

1. Please post `TEST` somewhere in pastebin.
2. Please note what revision you're on, whether you're forked from
another version, etc.

Thanks,
-Ngie

 526 /*
 527  * Load is maintained for all threads RUNNING and ON_RUNQ.  Add the load
 528  * for this thread to the referenced thread queue.
 529  */
 530 static void
 531 tdq_load_add(struct tdq *tdq, struct thread *td)
 532 {
 533
 534 TDQ_LOCK_ASSERT(tdq, MA_OWNED);
 535 THREAD_LOCK_ASSERT(td, MA_OWNED);
 536
 537 tdq->tdq_load++;
 538 if ((td->td_flags & TDF_NOLOAD) == 0)
 539 tdq->tdq_sysload++;
 540 KTR_COUNTER0(KTR_SCHED, "load", tdq->tdq_loadname, tdq->tdq_load);
 541 SDT_PROBE2(sched, , , load__change, (int)TDQ_ID(tdq),
tdq->tdq_load);
 542 }
___
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"

buildkernel ULE related breakage

[Michal Suszko]

Hi,
Got this error compiling GENERIC with s/4BSD/ULE/ on recent -CURRENT 
( wrapped long lines )

cc -c -O -pipe -march=pentium3 -Wall -Wredundant-decls -Wnested-externs
  -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline
  -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I.
  -I/usr/src/sys -I/usr/src/sys/dev -I/usr/src/sys/contrib/dev/acpica
  -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/dev/ath
  -I/usr/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h
  -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2
  -ffreestanding -Werror /usr/src/sys/kern/sched_ule.c
cc1: warnings being treated as errors
/usr/src/sys/kern/sched_ule.c: In function `sched_setup':
/usr/src/sys/kern/sched_ule.c:531: warning: unused variable `i'
*** Error code 1

Stop in /usr/obj/usr/src/sys/TEST.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.


Michal

___
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: HELP: Howtwo create a passwd-suitable hash for usage with psswd -H 0?

[O. Hartmann]

Am Thu, 18 Feb 2016 17:37:52 +
Gary Palmer  schrieb:

> On Thu, Feb 18, 2016 at 06:11:22PM +0100, O. Hartmann wrote:
> > Am Thu, 18 Feb 2016 09:29:26 -0700
> > Ian Lepore  schrieb:
> >   
> > > On Thu, 2016-02-18 at 16:29 +0100, O. Hartmann wrote:  
> > > > On Thu, 18 Feb 2016 14:52:44 +
> > > > RW  wrote:
> > > > 
> > > > > On Thu, 18 Feb 2016 14:16:24 +0100
> > > > > O. Hartmann wrote:
> > > > > 
> > > > > > Hello out there,
> > > > > > 
> > > > > > I run into a problem and digging for a solution didn't work out.
> > > > > > 
> > > > > > Problem: I need a string that reflects the hashed password for the
> > > > > > usage with 
> > > > > > 
> > > > > > passwd -H 0  
> > > > > 
> > > > > Did you mean -h?
> > > > 
> > > > no, I literally mean -H 0, I explain later ...
> > > > 
> > > > > 
> > > > > > I think the procedure is using 
> > > > > > 
> > > > > > sha512 -s Password
> > > > > > 
> > > > > > and using this output for further processing, but how?  
> > > > > 
> > > > > It's not as simple as that, password  hashes are usually salted and
> > > > > iterated. Salting means that the password is combined with a randomly
> > > > > generated string stored in plaintext, which means that the password
> > > > > doesn't hash to a fixed string.
> > > > > 
> > > > > I'm not sure exactly what you are trying to do, but crypt(3) may be of
> > > > > help.
> > > > 
> > > > I'm now down to a small C routine utilizing crypt(3). But this is not 
> > > > what I
> > > > intend to have, since I want to use tools from the FBSD base system.
> > > > 
> > > > I build images of a small appliance in a secure isolated environment via
> > > > NanoBSD. I do not want to have passwords in the clear around here, but 
> > > > I also
> > > > do not want to type in everytime an image is created, so the idea is to 
> > > > have
> > > > passwords prepared as hashes in a local file/in variables. Therefore, 
> > > > I'm
> > > > inclined to use the option "-H 0" of the pw(1) command to provide an 
> > > > already
> > > > and clean hash (SHA512), which is then stored in /etc/master.passwd.
> > > > 
> > > > It is really funny: passwd or pw take passwords via stdin (-h 0 with 
> > > > pw) and
> > > > they "generate" somehow the hashed password and store that in 
> > > > master.password
> > > > - but I didn't find any way to pipe out the writing of the password to 
> > > > the
> > > > standard output from that piece of software. Why? Security concerns I 
> > > > forgot to
> > > > consider?
> > > > 
> > > > I found lots of articles and howtos to use pipes producing the required
> > > > password hashes via passwd, chpasswd or pw, but they all have one 
> > > > problem: I
> > > > have to provide somehow the cleartext password in an automated 
> > > > environment.
> > > > 
> > > > Maybe there is something missing ...
> > > > 
> > > > oh
> > > 
> > > We use something like this at work (which I don't fully understand, but
> > > it works on freebsd 6.x through 10.x at least)...
> > > 
> > >  echo ${password} | openssl passwd -1 -stdin -salt VerySalty | \
> > >pw -V ${IMAGE_CHROOT_DIR}/etc useradd -n ${username} -H0 $*
> > > 
> > > I guess for your use you'd capture and save the output of openssl so
> > > you could later feed it back to pw when making images.
> > > 
> > > -- Ian  
> > 
> > The "openssl passwd -1" refers to MD5 hashes, as I understand the manpage, 
> > but I
> > require at least sha256. With this solution suggested, I'd have the 
> > password still
> > stored in cleartext somewhere - if not read -in via read or similar.
> > 
> > If you snip off the openssl portion and substitute "-H0" with "-h0", then 
> > this is the
> > way I did before - as defined/configured in login.conf (usually in
> > ${IMAGE_CHROOT_DIR}/etc) SHA512 will be used as digest algorithm and the 
> > password
> > seems "salted", prepended by the $6$ characters.
> > 
> > I'd like to have something like
> > 
> > echo ${password} | openssl passwd -sha512 -stdin -salt VerySalty
> > 
> > and store the result in a variable somewhere for use with
> > 
> > echo ${password_salted_sha512_hash} | pw -V ${IMAGE_CHROOT_DIR}/etc usermod 
> > -n\
> > ${username} -H 0  
> 
> I presume you want to generate the password manually (to eliminate the
> storage of the cleartext password) and then store the hash in a script
> somewhere to be reused?  How often do you need to generate new hashes?

Quite often - weekly and the images are numerous. The problem is that I made in 
the
initial phase mistakes - lack of concentration et cetera and several passwords 
were then
worng and the images wrecked (CD/DVD).
 
> 
> I'm wondering why you can't have a dummy user that you just change the
> password for when you need a new hash and then grab the crypted password
> out of /etc/master.passwd

Well, this idea has also come to my mind - but the efford would be more 
(scripts to
extract ...) 

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

[Kurt Jaeger]

Hi!

> > A short note on the www.freebsd.org website would probably be helpful,
> > as this case will produce a lot of noise.

> I'd like to second this! This could be some kind of use for the
> further propagation of FreeBSD!
> Many people asked me since yesterday, whether the operating system I used to
> base my appliances and work on does have the bug or not. 

There's a link in the News section now to a writeup by des.

-- 
p...@opsec.eu+49 171 3101372 4 years 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"

FreeBSD_HEAD_i386 - Build #2371 - Fixed

[jenkins-admin]

FreeBSD_HEAD_i386 - Build #2371 - Fixed:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2371/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2371/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2371/console

Change summaries:

295762 by zbb:
Fix build for i386 and arm64 after r295755

- Take bus_space_tag_t type into consideration when returning
  default, zero value.
- Include missing rman.h required by ofw_pci.h

295761 by br:
Increase kernel and user VA space.
This allows us to boot with more than 128MB of physical memory.

Sponsored by:   DARPA, AFRL
Sponsored by:   HEIF5

295760 by se:
Make WARNS=6 safe.

Tested with Clang 3.7.1, GCC 4.2.1 and GCC 4.8.5 on amd64.

___
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: Thinkpad T410: resume broken

[Adrian Chadd]

[snip]

Someone should sit me down with pizza and "help" me just modularise
the vesa/fb code so we can use it in vt.

It isn't /that/ hard, I've just been preoccupied.


-a
___
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: Thinkpad T410: resume broken

[John Baldwin]

On Thursday, February 18, 2016 10:56:29 PM Alexey Dokuchaev wrote:
> On Thu, Feb 18, 2016 at 06:55:03AM -0800, John Baldwin wrote:
> > On Thursday, February 18, 2016 08:37:38 PM Alexey Dokuchaev wrote:
> > > I've started to observe similar lines in the logs after updating to
> > > fresh -CURRENT, upon resume (on a different laptop though, not T410):
> > > 
> > >   pcib0: failed to set ACPI power state D2 on \_SB_.PCI0: AE_BAD_PARAMETER
> > >   acpi0: cleared fixed power button status
> > > 
> > > If these messages are legit, I'm wondering why I didn't see them on 8.4,
> > > and if it might affect suspend/resume sequence (broken right now)?
> > 
> > [...] Your BIOS said "please put this device in D2 during suspend" and your
> > device's capabilities said "I don't support D2".  You can confirm this by
> > looking up the _S3 method of your _SB_.PCIO device to find out what state is
> > requested during suspend and then looking at 'pciconf -lc pci0:0:0' to see
> > what D states are listed as supported.
> 
> This?:
> 
> Scope (\_SB)
> {
> Name (ECOK, 0x00)
> Device (PCI0)
> {
> Method (_S3D, 0, NotSerialized)  // _S3D: S3 Device State
> {
> Return (0x02)
> }
> ...

Yes, this says "please use D2 when going to S3".

> # pciconf -lc pci0:0:0
> hostb0@pci0:0:0:0:  class=0x06 card=0x83191033 chip=0x25908086 
> rev=0x04 hdr=0x00
> cap 09[e0] = vendor (length 9) Intel cap 2 version 1

Humm, perhaps PCI0 is not at 0:0.  Can you find the _ADR method for _SB_.PCI0?
That contains the "slot" and "function" as two words, e.g. 0x10002 would
correspond to the 'pci0:1:2' device (or possibly pci0:2:1, don't recall the
order off the top of my head).

-- 
John Baldwin
___
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: Thinkpad T410: resume broken

[John Baldwin]

On Thursday, February 18, 2016 09:47:12 PM Alexey Dokuchaev wrote:
> On Thu, Feb 18, 2016 at 06:50:34AM -0800, John Baldwin wrote:
> > On Thursday, February 18, 2016 08:13:38 PM Alexey Dokuchaev wrote:
> > vesa.ko shouldn't be working with KMS.  KMS turns off the legacy VGA
> > emulation in the hardware when it starts which prevents VESA from working
> > (VESA requires the legacy VGA interface).
> 
> Hmm, could this explain why vesa.ko can be loaded from loader.conf, but
> not via kldload(8)?  OTOH, kldload'ing it later does not seem to work
> (ir)regardless of whether i915kms.ko is loaded or not...

You might load it from loader.conf but it might then fail with an error about
failing to register in dmesg.  In that case it is effectively ignored.

> > I never have to hit the power button more than once to resume on a laptop
> > where resume works though.
> > 
> > (True on my X220 and on a T440 both with Intel or Radeon graphics (all
> > using KMS).
> 
> I'm about to try fresh -CURRENT on some HP AMD APU-based laptops, hence
> I'll ask: do aforementioned laptops suspend/resume without issues in X11
> or on the naked console as well?  (In a shop, I could only quickly test
> our X11-less memstick image.)

Once KMS is loaded they resume fine.  They require the KMS driver to turn
the LCD panel back on.  Without KMS they also "resume" but the screen is off
so you can't see anything.  However, you can type blind and run commands.
If the network is up you can ssh into the laptop, etc. after resume.

> > > Needless to say, suspend/resume worked nearly flawlessly under stable/8
> > > and stable/7 FWIW.
> > 
> > If it worked here, then this means you could try using sc(4) + the old drm
> > (not drm2).  This means your laptop is old enough to still turn the LCD 
> > panel
> > back on in its BIOS during resume like my HP netbook.  However, I don't know
> > for how much longer Xorg will support the older drm (if it even does now).
> 
> Well, technically, my laptop *does* resume with vt(4) + i915kms, just it
> takes a lot of power button hits and quite some time (up to several minutes),
> unless it dies somewhere during the process.  I'll retest it against
> GENERIC and report in a separate email.  On a related note, how does one
> configure sc(4) with old drm (vs. drm2) shall I need to try that?

On HEAD you need to set kern.vty=sc to use sc(4) instead of vt(4).  For
suspend/resume without X that should be sufficient.  You would only need
the old drm drivers for X.

> > FWIW, the HP netbook resumes fine with KMS as well for me.  One caveat
> > though is that if you are using vt(4) and haven't yet loaded KMS it won't
> > resume (due to vt(4) not having the equivalent of VESA).  With sc(4) the
> > netbook was always able to resume.
> 
> Right.  So far, I've been booting, kldloading i915kms.ko, zzz(8), resume.
> No X.Org was involved -- given how fragile suspend/resume is ATM, I'd like
> to iron out the issues with the pure console first.

Note that for the HP netbook, resume in console with vt(4) does not work
without KMS (due to vt(4) not supporting VESA).

-- 
John Baldwin
___
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: HELP: Howtwo create a passwd-suitable hash for usage with psswd -H 0?

[Gary Palmer]

On Thu, Feb 18, 2016 at 06:11:22PM +0100, O. Hartmann wrote:
> Am Thu, 18 Feb 2016 09:29:26 -0700
> Ian Lepore  schrieb:
> 
> > On Thu, 2016-02-18 at 16:29 +0100, O. Hartmann wrote:
> > > On Thu, 18 Feb 2016 14:52:44 +
> > > RW  wrote:
> > >   
> > > > On Thu, 18 Feb 2016 14:16:24 +0100
> > > > O. Hartmann wrote:
> > > >   
> > > > > Hello out there,
> > > > > 
> > > > > I run into a problem and digging for a solution didn't work out.
> > > > > 
> > > > > Problem: I need a string that reflects the hashed password for the
> > > > > usage with 
> > > > > 
> > > > > passwd -H 0
> > > > 
> > > > Did you mean -h?  
> > > 
> > > no, I literally mean -H 0, I explain later ...
> > >   
> > > >   
> > > > > I think the procedure is using 
> > > > > 
> > > > > sha512 -s Password
> > > > > 
> > > > > and using this output for further processing, but how?
> > > > 
> > > > It's not as simple as that, password  hashes are usually salted and
> > > > iterated. Salting means that the password is combined with a randomly
> > > > generated string stored in plaintext, which means that the password
> > > > doesn't hash to a fixed string.
> > > > 
> > > > I'm not sure exactly what you are trying to do, but crypt(3) may be of
> > > > help.  
> > > 
> > > I'm now down to a small C routine utilizing crypt(3). But this is not 
> > > what I
> > > intend to have, since I want to use tools from the FBSD base system.
> > > 
> > > I build images of a small appliance in a secure isolated environment via
> > > NanoBSD. I do not want to have passwords in the clear around here, but I 
> > > also
> > > do not want to type in everytime an image is created, so the idea is to 
> > > have
> > > passwords prepared as hashes in a local file/in variables. Therefore, I'm
> > > inclined to use the option "-H 0" of the pw(1) command to provide an 
> > > already
> > > and clean hash (SHA512), which is then stored in /etc/master.passwd.
> > > 
> > > It is really funny: passwd or pw take passwords via stdin (-h 0 with pw) 
> > > and
> > > they "generate" somehow the hashed password and store that in 
> > > master.password
> > > - but I didn't find any way to pipe out the writing of the password to the
> > > standard output from that piece of software. Why? Security concerns I 
> > > forgot to
> > > consider?
> > > 
> > > I found lots of articles and howtos to use pipes producing the required
> > > password hashes via passwd, chpasswd or pw, but they all have one 
> > > problem: I
> > > have to provide somehow the cleartext password in an automated 
> > > environment.
> > > 
> > > Maybe there is something missing ...
> > > 
> > > oh  
> > 
> > We use something like this at work (which I don't fully understand, but
> > it works on freebsd 6.x through 10.x at least)...
> > 
> >  echo ${password} | openssl passwd -1 -stdin -salt VerySalty | \
> >pw -V ${IMAGE_CHROOT_DIR}/etc useradd -n ${username} -H0 $*
> > 
> > I guess for your use you'd capture and save the output of openssl so
> > you could later feed it back to pw when making images.
> > 
> > -- Ian
> 
> The "openssl passwd -1" refers to MD5 hashes, as I understand the manpage, 
> but I require
> at least sha256. With this solution suggested, I'd have the password still 
> stored
> in cleartext somewhere - if not read -in via read or similar.
> 
> If you snip off the openssl portion and substitute "-H0" with "-h0", then 
> this is the way
> I did before - as defined/configured in login.conf (usually in
> ${IMAGE_CHROOT_DIR}/etc) SHA512 will be used as digest algorithm and the 
> password seems
> "salted", prepended by the $6$ characters.
> 
> I'd like to have something like
> 
> echo ${password} | openssl passwd -sha512 -stdin -salt VerySalty
> 
> and store the result in a variable somewhere for use with
> 
> echo ${password_salted_sha512_hash} | pw -V ${IMAGE_CHROOT_DIR}/etc usermod 
> -n\
> ${username} -H 0

I presume you want to generate the password manually (to eliminate the
storage of the cleartext password) and then store the hash in a script
somewhere to be reused?  How often do you need to generate new hashes?

I'm wondering why you can't have a dummy user that you just change the
password for when you need a new hash and then grab the crypted password
out of /etc/master.passwd

Thanks,

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

[O. Hartmann]

Am Wed, 17 Feb 2016 14:50:28 +0100
Kurt Jaeger  schrieb:

> Hi!
> 
> > The project that's vulnerable is called "glibc", not "libc". The BSDs
> > don't use glibc, so the phrase "nothing to see here" applies. glibc
> > isn't even available in FreeBSD's ports tree.
> > 
> > TL;DR: FreeBSD is not affected by CVE-2015-7547.  
> 
> A short note on the www.freebsd.org website would probably be helpful,
> as this case will produce a lot of noise.
> 

I'd like to second this! This could be some kind of use for the further 
propagation of
FreeBSD! Many people asked me since yesterday, whether the operating system I 
used to
base my appliances and work on does have the bug or not. 


pgpdjBObmGVsO.pgp
Description: OpenPGP digital signature

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

[O. Hartmann]

Am Wed, 17 Feb 2016 08:40:03 -0500
Shawn Webb  schrieb:

> On Wed, Feb 17, 2016 at 02:24:10PM +0100, 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.  
> 
> The project that's vulnerable is called "glibc", not "libc". The BSDs
> don't use glibc, so the phrase "nothing to see here" applies. glibc
> isn't even available in FreeBSD's ports tree.
> 
> TL;DR: FreeBSD is not affected by CVE-2015-7547.
> 
> Thanks,
> 

The article, I refere to, did only mention "libc" and they used the terminus
"Linux/UNIX", and this is usually associted by that Linux-folks with the rest 
of the
UNIX-alike world after their precious Linux.

I followed then the explanation of the CVE and that stated very clearly, that 
it is GNU
libc. So, I feel better now, but a pity of all that stuff in routers, switches, 
security
appliances utilizing Linux and the penetrated glic. :-)


pgpRNzZksOfi_.pgp
Description: OpenPGP digital signature

Re: Thinkpad T410: resume broken

[Alexey Dokuchaev]

On Thu, Feb 18, 2016 at 06:55:03AM -0800, John Baldwin wrote:
> On Thursday, February 18, 2016 08:37:38 PM Alexey Dokuchaev wrote:
> > I've started to observe similar lines in the logs after updating to
> > fresh -CURRENT, upon resume (on a different laptop though, not T410):
> > 
> >   pcib0: failed to set ACPI power state D2 on \_SB_.PCI0: AE_BAD_PARAMETER
> >   acpi0: cleared fixed power button status
> > 
> > If these messages are legit, I'm wondering why I didn't see them on 8.4,
> > and if it might affect suspend/resume sequence (broken right now)?
> 
> [...] Your BIOS said "please put this device in D2 during suspend" and your
> device's capabilities said "I don't support D2".  You can confirm this by
> looking up the _S3 method of your _SB_.PCIO device to find out what state is
> requested during suspend and then looking at 'pciconf -lc pci0:0:0' to see
> what D states are listed as supported.

This?:

Scope (\_SB)
{
Name (ECOK, 0x00)
Device (PCI0)
{
Method (_S3D, 0, NotSerialized)  // _S3D: S3 Device State
{
Return (0x02)
}
...

# pciconf -lc pci0:0:0
hostb0@pci0:0:0:0:  class=0x06 card=0x83191033 chip=0x25908086 rev=0x04 
hdr=0x00
cap 09[e0] = vendor (length 9) Intel cap 2 version 1

# pciconf -rb pci0:0:0 0xe0:0xff
09 00 09 21 02 a2 8b 90  0a 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00  00 00 05 00 10 00 00 00

> There's not much we can do if your BIOS lies to us.

As long as we can patch ACPI tables, lying BIOS should not be a problem, no?

./danfe
___
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: HELP: Howtwo create a passwd-suitable hash for usage with psswd -H 0?

[O. Hartmann]

Am Thu, 18 Feb 2016 11:20:20 -0500
Lowell Gilbert  schrieb:

> Allan Jude  writes:
> 
> > On 2016-02-18 10:29, O. Hartmann wrote:  
> 
> >> I'm now down to a small C routine utilizing crypt(3). But this is not what 
> >> I
> >> intend to have, since I want to use tools from the FBSD base system.
> >> 
> >> I build images of a small appliance in a secure isolated environment via
> >> NanoBSD. I do not want to have passwords in the clear around here, but I 
> >> also
> >> do not want to type in everytime an image is created, so the idea is to 
> >> have
> >> passwords prepared as hashes in a local file/in variables. Therefore, I'm
> >> inclined to use the option "-H 0" of the pw(1) command to provide an 
> >> already
> >> and clean hash (SHA512), which is then stored in /etc/master.passwd.
> >> 
> >> It is really funny: passwd or pw take passwords via stdin (-h 0 with pw) 
> >> and
> >> they "generate" somehow the hashed password and store that in 
> >> master.password
> >> - but I didn't find any way to pipe out the writing of the password to the
> >> standard output from that piece of software. Why? Security concerns I 
> >> forgot to
> >> consider?
> >> 
> >> I found lots of articles and howtos to use pipes producing the required
> >> password hashes via passwd, chpasswd or pw, but they all have one problem: 
> >> I
> >> have to provide somehow the cleartext password in an automated environment.
> >> 
> >> Maybe there is something missing ...
> >> 
> >> oh
> >> ___  
> >
> > pw is using crypt() to turn the raw password into the password hash you
> > see in master.passwd.
> >
> > The sha512 tool cannot do this, as that is 'sha512' (designed to be as
> > fast as possible), and what crypt() uses is 'sha512crypt' (designed to
> > be purposefully slow, does 5,000 sha512s by default, but is tunable by
> > setting rounds=1$ as a prefix to the salt when calling crypt)
> >
> > crypt("mypassword", "$6$rounds=1$usesomesillystri");
> >
> > Results in:
> >
> > $6$rounds=1$usesomesillystri$CtNyZlpTyzaFTivUi7CCBYAoRBZXxSz1qnnGOAb0tXB4irc9/ro10S1a3X2JWTNa1tsMZwIprG/H1o3TKOrDt0
> >
> > NetBSD has a command for generating hashes on the command line, pwhash(1)
> >
> > I have wanted to bring something like that over for a while, but looking
> > at the source for pwhash I decided I'd want to start from scratch.  
> 
> "openssl passwd", maybe?


As stated in an earlier response, openssl passwd  has only md5 (option -1) and 
ordinary
crypt (-crypt) as digest, I need something more stronger, at least sha256.


pgpmTlkGODcEB.pgp
Description: OpenPGP digital signature

Re: HELP: Howtwo create a passwd-suitable hash for usage with psswd -H 0?

[O. Hartmann]

Am Thu, 18 Feb 2016 10:54:27 -0500
Allan Jude  schrieb:

> On 2016-02-18 10:29, O. Hartmann wrote:
> > On Thu, 18 Feb 2016 14:52:44 +
> > RW  wrote:
> >   
> >> On Thu, 18 Feb 2016 14:16:24 +0100
> >> O. Hartmann wrote:
> >>  
> >>> Hello out there,
> >>>
> >>> I run into a problem and digging for a solution didn't work out.
> >>>
> >>> Problem: I need a string that reflects the hashed password for the
> >>> usage with 
> >>>
> >>> passwd -H 0
> >>
> >> Did you mean -h?  
> > 
> > no, I literally mean -H 0, I explain later ...
> >   
> >>  
> >>> I think the procedure is using 
> >>>
> >>> sha512 -s Password
> >>>
> >>> and using this output for further processing, but how?
> >>
> >> It's not as simple as that, password  hashes are usually salted and
> >> iterated. Salting means that the password is combined with a randomly
> >> generated string stored in plaintext, which means that the password
> >> doesn't hash to a fixed string.
> >>
> >> I'm not sure exactly what you are trying to do, but crypt(3) may be of
> >> help.  
> > 
> > I'm now down to a small C routine utilizing crypt(3). But this is not what I
> > intend to have, since I want to use tools from the FBSD base system.
> > 
> > I build images of a small appliance in a secure isolated environment via
> > NanoBSD. I do not want to have passwords in the clear around here, but I 
> > also
> > do not want to type in everytime an image is created, so the idea is to have
> > passwords prepared as hashes in a local file/in variables. Therefore, I'm
> > inclined to use the option "-H 0" of the pw(1) command to provide an already
> > and clean hash (SHA512), which is then stored in /etc/master.passwd.
> > 
> > It is really funny: passwd or pw take passwords via stdin (-h 0 with pw) and
> > they "generate" somehow the hashed password and store that in 
> > master.password
> > - but I didn't find any way to pipe out the writing of the password to the
> > standard output from that piece of software. Why? Security concerns I 
> > forgot to
> > consider?
> > 
> > I found lots of articles and howtos to use pipes producing the required
> > password hashes via passwd, chpasswd or pw, but they all have one problem: I
> > have to provide somehow the cleartext password in an automated environment.
> > 
> > Maybe there is something missing ...
> > 
> > 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"
> >   
> 
> pw is using crypt() to turn the raw password into the password hash you
> see in master.passwd.
> 
> The sha512 tool cannot do this, as that is 'sha512' (designed to be as
> fast as possible), and what crypt() uses is 'sha512crypt' (designed to
> be purposefully slow, does 5,000 sha512s by default, but is tunable by
> setting rounds=1$ as a prefix to the salt when calling crypt)
> 
> crypt("mypassword", "$6$rounds=1$usesomesillystri");
> 
> Results in:
> 
> $6$rounds=1$usesomesillystri$CtNyZlpTyzaFTivUi7CCBYAoRBZXxSz1qnnGOAb0tXB4irc9/ro10S1a3X2JWTNa1tsMZwIprG/H1o3TKOrDt0
> 
> NetBSD has a command for generating hashes on the command line, pwhash(1)
> 
> I have wanted to bring something like that over for a while, but looking
> at the source for pwhash I decided I'd want to start from scratch.
> 

Hallo Allen,

thanks for the insight in crypt. I have no information found about crypt()'s 
capability
of using rounds= - there is a slide-show floating around referring to FBSD 
10.x and
claims, that FreeBSD doesn't have this functionality yet. The manpage for 
crypt(3)
doesn't state anything. It is very hard for me to extract those informations 
from the
docs provided! It would be great, if someone could read about it in the 
manpages - did I
miss something?

And yes, please, start from scratch - I'd like to see something like pwhash() in
FreeBSD ;-)

Thank you very much and kind regards,

oh


pgpNBYYIzjZiD.pgp
Description: OpenPGP digital signature

Re: HELP: Howtwo create a passwd-suitable hash for usage with psswd -H 0?

[Allan Jude]

On 2016-02-18 11:29, Ian Lepore wrote:

On Thu, 2016-02-18 at 16:29 +0100, O. Hartmann wrote:

On Thu, 18 Feb 2016 14:52:44 +
RW  wrote:


On Thu, 18 Feb 2016 14:16:24 +0100
O. Hartmann wrote:


Hello out there,

I run into a problem and digging for a solution didn't work out.

Problem: I need a string that reflects the hashed password for the
usage with

passwd -H 0


Did you mean -h?


no, I literally mean -H 0, I explain later ...




I think the procedure is using

sha512 -s Password

and using this output for further processing, but how?


It's not as simple as that, password  hashes are usually salted and
iterated. Salting means that the password is combined with a randomly
generated string stored in plaintext, which means that the password
doesn't hash to a fixed string.

I'm not sure exactly what you are trying to do, but crypt(3) may be of
help.


I'm now down to a small C routine utilizing crypt(3). But this is not what I
intend to have, since I want to use tools from the FBSD base system.

I build images of a small appliance in a secure isolated environment via
NanoBSD. I do not want to have passwords in the clear around here, but I also
do not want to type in everytime an image is created, so the idea is to have
passwords prepared as hashes in a local file/in variables. Therefore, I'm
inclined to use the option "-H 0" of the pw(1) command to provide an already
and clean hash (SHA512), which is then stored in /etc/master.passwd.

It is really funny: passwd or pw take passwords via stdin (-h 0 with pw) and
they "generate" somehow the hashed password and store that in master.password
- but I didn't find any way to pipe out the writing of the password to the
standard output from that piece of software. Why? Security concerns I forgot to
consider?

I found lots of articles and howtos to use pipes producing the required
password hashes via passwd, chpasswd or pw, but they all have one problem: I
have to provide somehow the cleartext password in an automated environment.

Maybe there is something missing ...

oh


We use something like this at work (which I don't fully understand, but
it works on freebsd 6.x through 10.x at least)...

  echo ${password} | openssl passwd -1 -stdin -salt VerySalty | \
pw -V ${IMAGE_CHROOT_DIR}/etc useradd -n ${username} -H0 $*

I guess for your use you'd capture and save the output of openssl so
you could later feed it back to pw when making images.

-- Ian

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



`openssl passwd` only seems to support md5crypt


--
Allan Jude
___
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: HELP: Howtwo create a passwd-suitable hash for usage with psswd -H 0?

[O. Hartmann]

Am Thu, 18 Feb 2016 09:29:26 -0700
Ian Lepore  schrieb:

> On Thu, 2016-02-18 at 16:29 +0100, O. Hartmann wrote:
> > On Thu, 18 Feb 2016 14:52:44 +
> > RW  wrote:
> >   
> > > On Thu, 18 Feb 2016 14:16:24 +0100
> > > O. Hartmann wrote:
> > >   
> > > > Hello out there,
> > > > 
> > > > I run into a problem and digging for a solution didn't work out.
> > > > 
> > > > Problem: I need a string that reflects the hashed password for the
> > > > usage with 
> > > > 
> > > > passwd -H 0
> > > 
> > > Did you mean -h?  
> > 
> > no, I literally mean -H 0, I explain later ...
> >   
> > >   
> > > > I think the procedure is using 
> > > > 
> > > > sha512 -s Password
> > > > 
> > > > and using this output for further processing, but how?
> > > 
> > > It's not as simple as that, password  hashes are usually salted and
> > > iterated. Salting means that the password is combined with a randomly
> > > generated string stored in plaintext, which means that the password
> > > doesn't hash to a fixed string.
> > > 
> > > I'm not sure exactly what you are trying to do, but crypt(3) may be of
> > > help.  
> > 
> > I'm now down to a small C routine utilizing crypt(3). But this is not what I
> > intend to have, since I want to use tools from the FBSD base system.
> > 
> > I build images of a small appliance in a secure isolated environment via
> > NanoBSD. I do not want to have passwords in the clear around here, but I 
> > also
> > do not want to type in everytime an image is created, so the idea is to have
> > passwords prepared as hashes in a local file/in variables. Therefore, I'm
> > inclined to use the option "-H 0" of the pw(1) command to provide an already
> > and clean hash (SHA512), which is then stored in /etc/master.passwd.
> > 
> > It is really funny: passwd or pw take passwords via stdin (-h 0 with pw) and
> > they "generate" somehow the hashed password and store that in 
> > master.password
> > - but I didn't find any way to pipe out the writing of the password to the
> > standard output from that piece of software. Why? Security concerns I 
> > forgot to
> > consider?
> > 
> > I found lots of articles and howtos to use pipes producing the required
> > password hashes via passwd, chpasswd or pw, but they all have one problem: I
> > have to provide somehow the cleartext password in an automated environment.
> > 
> > Maybe there is something missing ...
> > 
> > oh  
> 
> We use something like this at work (which I don't fully understand, but
> it works on freebsd 6.x through 10.x at least)...
> 
>  echo ${password} | openssl passwd -1 -stdin -salt VerySalty | \
>pw -V ${IMAGE_CHROOT_DIR}/etc useradd -n ${username} -H0 $*
> 
> I guess for your use you'd capture and save the output of openssl so
> you could later feed it back to pw when making images.
> 
> -- Ian

The "openssl passwd -1" refers to MD5 hashes, as I understand the manpage, but 
I require
at least sha256. With this solution suggested, I'd have the password still 
stored
in cleartext somewhere - if not read -in via read or similar.

If you snip off the openssl portion and substitute "-H0" with "-h0", then this 
is the way
I did before - as defined/configured in login.conf (usually in
${IMAGE_CHROOT_DIR}/etc) SHA512 will be used as digest algorithm and the 
password seems
"salted", prepended by the $6$ characters.

I'd like to have something like

echo ${password} | openssl passwd -sha512 -stdin -salt VerySalty

and store the result in a variable somewhere for use with

echo ${password_salted_sha512_hash} | pw -V ${IMAGE_CHROOT_DIR}/etc usermod -n\
${username} -H 0

Thanks,

oh


pgpL6NPERlPtg.pgp
Description: OpenPGP digital signature

Re: HELP: Howtwo create a passwd-suitable hash for usage with psswd -H 0?

[Miroslav Lachman]

Lowell Gilbert wrote on 02/18/2016 17:20:

Allan Jude  writes:


On 2016-02-18 10:29, O. Hartmann wrote:



I'm now down to a small C routine utilizing crypt(3). But this is not what I
intend to have, since I want to use tools from the FBSD base system.


[...]


I have wanted to bring something like that over for a while, but looking
at the source for pwhash I decided I'd want to start from scratch.


"openssl passwd", maybe?


It is really old implementation and cannot produce any modern hash than MD5.

Miroslav Lachman

___
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: Thinkpad T410: resume broken

[Alexey Dokuchaev]

On Thu, Feb 18, 2016 at 06:50:34AM -0800, John Baldwin wrote:
> On Thursday, February 18, 2016 08:13:38 PM Alexey Dokuchaev wrote:
> > On Sat, May 17, 2014 at 08:20:03AM -0400, John Baldwin wrote:
> > > VESA needs to be removed for i915kms, but I've no idea if it needs to be
> > > removed for Nvidia.  The video reset code was reworked in 10 so that
> > > having VESA is supposed to be like using 'hw.acpi.reset_video=1' on 9,
> > > but in theory it works more often.
> > 
> > This (VESA needs to be removed for i915kms) is news to me: I don't see it
> > mentioned in UPDATING, and "options VESA" presents in -CURRENT's (post-KMS
> > era) GENERIC kernel config.  So what's the real deal here? :-)
> 
> This is an old mail you are responding to.  You no longer need to remove
> VESA for kms.

Ah OK, that would explain it, thanks.

> vesa.ko shouldn't be working with KMS.  KMS turns off the legacy VGA
> emulation in the hardware when it starts which prevents VESA from working
> (VESA requires the legacy VGA interface).

Hmm, could this explain why vesa.ko can be loaded from loader.conf, but
not via kldload(8)?  OTOH, kldload'ing it later does not seem to work
(ir)regardless of whether i915kms.ko is loaded or not...

> I never have to hit the power button more than once to resume on a laptop
> where resume works though.
> 
> (True on my X220 and on a T440 both with Intel or Radeon graphics (all
> using KMS).

I'm about to try fresh -CURRENT on some HP AMD APU-based laptops, hence
I'll ask: do aforementioned laptops suspend/resume without issues in X11
or on the naked console as well?  (In a shop, I could only quickly test
our X11-less memstick image.)

> > Needless to say, suspend/resume worked nearly flawlessly under stable/8
> > and stable/7 FWIW.
> 
> If it worked here, then this means you could try using sc(4) + the old drm
> (not drm2).  This means your laptop is old enough to still turn the LCD panel
> back on in its BIOS during resume like my HP netbook.  However, I don't know
> for how much longer Xorg will support the older drm (if it even does now).

Well, technically, my laptop *does* resume with vt(4) + i915kms, just it
takes a lot of power button hits and quite some time (up to several minutes),
unless it dies somewhere during the process.  I'll retest it against
GENERIC and report in a separate email.  On a related note, how does one
configure sc(4) with old drm (vs. drm2) shall I need to try that?

> FWIW, the HP netbook resumes fine with KMS as well for me.  One caveat
> though is that if you are using vt(4) and haven't yet loaded KMS it won't
> resume (due to vt(4) not having the equivalent of VESA).  With sc(4) the
> netbook was always able to resume.

Right.  So far, I've been booting, kldloading i915kms.ko, zzz(8), resume.
No X.Org was involved -- given how fragile suspend/resume is ATM, I'd like
to iron out the issues with the pure console first.

./danfe
___
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: HELP: Howtwo create a passwd-suitable hash for usage with psswd -H 0?

[Ian Lepore]

On Thu, 2016-02-18 at 16:29 +0100, O. Hartmann wrote:
> On Thu, 18 Feb 2016 14:52:44 +
> RW  wrote:
> 
> > On Thu, 18 Feb 2016 14:16:24 +0100
> > O. Hartmann wrote:
> > 
> > > Hello out there,
> > > 
> > > I run into a problem and digging for a solution didn't work out.
> > > 
> > > Problem: I need a string that reflects the hashed password for the
> > > usage with 
> > > 
> > > passwd -H 0  
> > 
> > Did you mean -h?
> 
> no, I literally mean -H 0, I explain later ...
> 
> > 
> > > I think the procedure is using 
> > > 
> > > sha512 -s Password
> > > 
> > > and using this output for further processing, but how?  
> > 
> > It's not as simple as that, password  hashes are usually salted and
> > iterated. Salting means that the password is combined with a randomly
> > generated string stored in plaintext, which means that the password
> > doesn't hash to a fixed string.
> > 
> > I'm not sure exactly what you are trying to do, but crypt(3) may be of
> > help.
> 
> I'm now down to a small C routine utilizing crypt(3). But this is not what I
> intend to have, since I want to use tools from the FBSD base system.
> 
> I build images of a small appliance in a secure isolated environment via
> NanoBSD. I do not want to have passwords in the clear around here, but I also
> do not want to type in everytime an image is created, so the idea is to have
> passwords prepared as hashes in a local file/in variables. Therefore, I'm
> inclined to use the option "-H 0" of the pw(1) command to provide an already
> and clean hash (SHA512), which is then stored in /etc/master.passwd.
> 
> It is really funny: passwd or pw take passwords via stdin (-h 0 with pw) and
> they "generate" somehow the hashed password and store that in master.password
> - but I didn't find any way to pipe out the writing of the password to the
> standard output from that piece of software. Why? Security concerns I forgot 
> to
> consider?
> 
> I found lots of articles and howtos to use pipes producing the required
> password hashes via passwd, chpasswd or pw, but they all have one problem: I
> have to provide somehow the cleartext password in an automated environment.
> 
> Maybe there is something missing ...
> 
> oh

We use something like this at work (which I don't fully understand, but
it works on freebsd 6.x through 10.x at least)...

 echo ${password} | openssl passwd -1 -stdin -salt VerySalty | \
   pw -V ${IMAGE_CHROOT_DIR}/etc useradd -n ${username} -H0 $*

I guess for your use you'd capture and save the output of openssl so
you could later feed it back to pw when making images.

-- Ian

___
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_HEAD_i386 - Build #2370 - Still Failing

[jenkins-admin]

FreeBSD_HEAD_i386 - Build #2370 - Still Failing:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2370/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2370/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2370/console

Change summaries:

295759 by imp:
Remove a stray else. It isn't needed (due to the return at the end of
the if statement it pairs with). While not an error today, a careless
edit in the future could cause problems (though given the nature of
this specific code, the problems quite likely would be some variation
of "most direct access SCSI storage devices won't attach," which is
unlikely to go unnoticed).

PVS-Studio: V705

295758 by br:
Use medany (Medium/Anywhere) GCC code model for RISC-V.
This will allow us to use bigger relocations and all
the 64-bit VA space.

295757 by emaste:
Remove dd xfer stats emitted during buildworld

They result in gratuitous differences when comparing build log output.



The end of the build log:

[...truncated 210759 lines...]
--- tmc18c30.o ---
ctfconvert -L VERSION -g tmc18c30.o
--- ohci.o ---
cc  -c -O -pipe  -g -nostdinc  -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt 
-D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h  -mno-mmx -mno-sse 
-msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall 
-Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes 
-Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign 
-D__printf__=__freebsd_kprintf__  -Wmissing-include-dirs 
-fdiagnostics-show-option  -Wno-unknown-pragmas  
-Wno-error-tautological-compare -Wno-error-empty-body  
-Wno-error-parentheses-equality -Wno-error-unused-function  
-Wno-error-pointer-sign -Wno-error-shift-negative-value  -mno-aes -mno-avx  
-std=iso9899:1999 -Werror  /usr/src/sys/dev/usb/controller/ohci.c
--- syscons.o ---
ctfconvert -L VERSION -g syscons.o
--- uhci.o ---
cc  -c -O -pipe  -g -nostdinc  -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt 
-D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h  -mno-mmx -mno-sse 
-msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall 
-Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes 
-Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign 
-D__printf__=__freebsd_kprintf__  -Wmissing-include-dirs 
-fdiagnostics-show-option  -Wno-unknown-pragmas  
-Wno-error-tautological-compare -Wno-error-empty-body  
-Wno-error-parentheses-equality -Wno-error-unused-function  
-Wno-error-pointer-sign -Wno-error-shift-negative-value  -mno-aes -mno-avx  
-std=iso9899:1999 -Werror  /usr/src/sys/dev/usb/controller/uhci.c
--- ohci.o ---
ctfconvert -L VERSION -g ohci.o
--- xhci.o ---
cc  -c -O -pipe  -g -nostdinc  -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt 
-D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h  -mno-mmx -mno-sse 
-msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall 
-Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes 
-Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign 
-D__printf__=__freebsd_kprintf__  -Wmissing-include-dirs 
-fdiagnostics-show-option  -Wno-unknown-pragmas  
-Wno-error-tautological-compare -Wno-error-empty-body  
-Wno-error-parentheses-equality -Wno-error-unused-function  
-Wno-error-pointer-sign -Wno-error-shift-negative-value  -mno-aes -mno-avx  
-std=iso9899:1999 -Werror  /usr/src/sys/dev/usb/controller/xhci.c
--- rt2860.o ---
ctfconvert -L VERSION -g rt2860.o
--- usb_busdma.o ---
cc  -c -O -pipe  -g -nostdinc  -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt 
-D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h  -mno-mmx -mno-sse 
-msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall 
-Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes 
-Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign 
-D__printf__=__freebsd_kprintf__  -Wmissing-include-dirs 
-fdiagnostics-show-option  -Wno-unknown-pragmas  
-Wno-error-tautological-compare -Wno-error-empty-body  
-Wno-error-parentheses-equality -Wno-error-unused-function  
-Wno-error-pointer-sign -Wno-error-shift-negative-value  -mno-aes -mno-avx  
-std=iso9899:1999 -Werror  /usr/src/sys/dev/usb/usb_busdma.c
--- ehci.o ---
ctfconvert -L VERSION -g ehci.o
--- usb_core.o ---
cc  -c -O -pipe  -g -nostdinc  -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt 
-D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h  -mno-mmx -mno-sse 
-msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall 
-Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes 
-Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign 
-D__printf__=__freebsd_kprintf__  -Wmissing-include-dirs 
-fdiagnostics-show-option  -Wno-unknown-pragmas  
-Wno-error-tautological-compare -Wno-error-empty-body  
-Wno-error-parentheses-equality -Wno-error-unused-function  
-Wno-error-pointer-sign 

Re: HELP: Howtwo create a passwd-suitable hash for usage with psswd -H 0?

[Lowell Gilbert]

Allan Jude  writes:

> On 2016-02-18 10:29, O. Hartmann wrote:

>> I'm now down to a small C routine utilizing crypt(3). But this is not what I
>> intend to have, since I want to use tools from the FBSD base system.
>> 
>> I build images of a small appliance in a secure isolated environment via
>> NanoBSD. I do not want to have passwords in the clear around here, but I also
>> do not want to type in everytime an image is created, so the idea is to have
>> passwords prepared as hashes in a local file/in variables. Therefore, I'm
>> inclined to use the option "-H 0" of the pw(1) command to provide an already
>> and clean hash (SHA512), which is then stored in /etc/master.passwd.
>> 
>> It is really funny: passwd or pw take passwords via stdin (-h 0 with pw) and
>> they "generate" somehow the hashed password and store that in master.password
>> - but I didn't find any way to pipe out the writing of the password to the
>> standard output from that piece of software. Why? Security concerns I forgot 
>> to
>> consider?
>> 
>> I found lots of articles and howtos to use pipes producing the required
>> password hashes via passwd, chpasswd or pw, but they all have one problem: I
>> have to provide somehow the cleartext password in an automated environment.
>> 
>> Maybe there is something missing ...
>> 
>> oh
>> ___
>
> pw is using crypt() to turn the raw password into the password hash you
> see in master.passwd.
>
> The sha512 tool cannot do this, as that is 'sha512' (designed to be as
> fast as possible), and what crypt() uses is 'sha512crypt' (designed to
> be purposefully slow, does 5,000 sha512s by default, but is tunable by
> setting rounds=1$ as a prefix to the salt when calling crypt)
>
> crypt("mypassword", "$6$rounds=1$usesomesillystri");
>
> Results in:
>
> $6$rounds=1$usesomesillystri$CtNyZlpTyzaFTivUi7CCBYAoRBZXxSz1qnnGOAb0tXB4irc9/ro10S1a3X2JWTNa1tsMZwIprG/H1o3TKOrDt0
>
> NetBSD has a command for generating hashes on the command line, pwhash(1)
>
> I have wanted to bring something like that over for a while, but looking
> at the source for pwhash I decided I'd want to start from scratch.

"openssl passwd", maybe?
___
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: HELP: Howtwo create a passwd-suitable hash for usage with psswd -H 0?

[Allan Jude]

On 2016-02-18 10:29, O. Hartmann wrote:
> On Thu, 18 Feb 2016 14:52:44 +
> RW  wrote:
> 
>> On Thu, 18 Feb 2016 14:16:24 +0100
>> O. Hartmann wrote:
>>
>>> Hello out there,
>>>
>>> I run into a problem and digging for a solution didn't work out.
>>>
>>> Problem: I need a string that reflects the hashed password for the
>>> usage with 
>>>
>>> passwd -H 0  
>>
>> Did you mean -h?
> 
> no, I literally mean -H 0, I explain later ...
> 
>>
>>> I think the procedure is using 
>>>
>>> sha512 -s Password
>>>
>>> and using this output for further processing, but how?  
>>
>> It's not as simple as that, password  hashes are usually salted and
>> iterated. Salting means that the password is combined with a randomly
>> generated string stored in plaintext, which means that the password
>> doesn't hash to a fixed string.
>>
>> I'm not sure exactly what you are trying to do, but crypt(3) may be of
>> help.
> 
> I'm now down to a small C routine utilizing crypt(3). But this is not what I
> intend to have, since I want to use tools from the FBSD base system.
> 
> I build images of a small appliance in a secure isolated environment via
> NanoBSD. I do not want to have passwords in the clear around here, but I also
> do not want to type in everytime an image is created, so the idea is to have
> passwords prepared as hashes in a local file/in variables. Therefore, I'm
> inclined to use the option "-H 0" of the pw(1) command to provide an already
> and clean hash (SHA512), which is then stored in /etc/master.passwd.
> 
> It is really funny: passwd or pw take passwords via stdin (-h 0 with pw) and
> they "generate" somehow the hashed password and store that in master.password
> - but I didn't find any way to pipe out the writing of the password to the
> standard output from that piece of software. Why? Security concerns I forgot 
> to
> consider?
> 
> I found lots of articles and howtos to use pipes producing the required
> password hashes via passwd, chpasswd or pw, but they all have one problem: I
> have to provide somehow the cleartext password in an automated environment.
> 
> Maybe there is something missing ...
> 
> 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"
> 

pw is using crypt() to turn the raw password into the password hash you
see in master.passwd.

The sha512 tool cannot do this, as that is 'sha512' (designed to be as
fast as possible), and what crypt() uses is 'sha512crypt' (designed to
be purposefully slow, does 5,000 sha512s by default, but is tunable by
setting rounds=1$ as a prefix to the salt when calling crypt)

crypt("mypassword", "$6$rounds=1$usesomesillystri");

Results in:

$6$rounds=1$usesomesillystri$CtNyZlpTyzaFTivUi7CCBYAoRBZXxSz1qnnGOAb0tXB4irc9/ro10S1a3X2JWTNa1tsMZwIprG/H1o3TKOrDt0

NetBSD has a command for generating hashes on the command line, pwhash(1)

I have wanted to bring something like that over for a while, but looking
at the source for pwhash I decided I'd want to start from scratch.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature

Re: HELP: Howtwo create a passwd-suitable hash for usage with psswd -H 0?

[O. Hartmann]

On Thu, 18 Feb 2016 14:52:44 +
RW  wrote:

> On Thu, 18 Feb 2016 14:16:24 +0100
> O. Hartmann wrote:
> 
> > Hello out there,
> > 
> > I run into a problem and digging for a solution didn't work out.
> > 
> > Problem: I need a string that reflects the hashed password for the
> > usage with 
> > 
> > passwd -H 0  
> 
> Did you mean -h?

no, I literally mean -H 0, I explain later ...

> 
> > I think the procedure is using 
> > 
> > sha512 -s Password
> > 
> > and using this output for further processing, but how?  
> 
> It's not as simple as that, password  hashes are usually salted and
> iterated. Salting means that the password is combined with a randomly
> generated string stored in plaintext, which means that the password
> doesn't hash to a fixed string.
> 
> I'm not sure exactly what you are trying to do, but crypt(3) may be of
> help.

I'm now down to a small C routine utilizing crypt(3). But this is not what I
intend to have, since I want to use tools from the FBSD base system.

I build images of a small appliance in a secure isolated environment via
NanoBSD. I do not want to have passwords in the clear around here, but I also
do not want to type in everytime an image is created, so the idea is to have
passwords prepared as hashes in a local file/in variables. Therefore, I'm
inclined to use the option "-H 0" of the pw(1) command to provide an already
and clean hash (SHA512), which is then stored in /etc/master.passwd.

It is really funny: passwd or pw take passwords via stdin (-h 0 with pw) and
they "generate" somehow the hashed password and store that in master.password
- but I didn't find any way to pipe out the writing of the password to the
standard output from that piece of software. Why? Security concerns I forgot to
consider?

I found lots of articles and howtos to use pipes producing the required
password hashes via passwd, chpasswd or pw, but they all have one problem: I
have to provide somehow the cleartext password in an automated environment.

Maybe there is something missing ...

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"

Re: Thinkpad T410: resume broken

[Alexey Dokuchaev]

On Fri, May 23, 2014 at 10:00:30AM -0400, John Baldwin wrote:
> On Wednesday, May 21, 2014 3:43:49 pm Jan Henrik Sylvester wrote:
> > Looking through dmesg, it seems that other USB devices (build-in) are
> > reappearing (Qualcomm Gobi 2000, Broadcom Bluetooth Device) after
> > resume, just not the mouse.
> > 
> > Are these lines likely related?
> > 
> > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.PEG_:
> > AE_BAD_PARAMETER
> > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP1:
> > AE_BAD_PARAMETER
> > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP2:
> > AE_BAD_PARAMETER
> > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP4:
> > AE_BAD_PARAMETER
> > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP5:
> > AE_BAD_PARAMETER
> 
> These are probably not related.  These man that your BIOS explicitly told
> the OS to power down these devices (PEG_ is probably your GPU, and EXP[1-5]
> are probably PCI-PCI bridges that represent the downstream ports of your
> PCI-e root complex) in the D2 state when suspending, but the devices don't
> actually support D2 (most PCI devices only support D0 (full on) and D3
> (full off)).

I've started to observe similar lines in the logs after updating to fresh
-CURRENT, upon resume (on a different laptop though, not T410):

  pcib0: failed to set ACPI power state D2 on \_SB_.PCI0: AE_BAD_PARAMETER
  acpi0: cleared fixed power button status

If these messages are legit, I'm wondering why I didn't see them on 8.4,
and if it might affect suspend/resume sequence (broken right now)?  Thanks,

./danfe
___
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: Memory modified after free in "MAP ENTRY" zone (vm_map_entry_t->read_ahead)

[Konstantin Belousov]

On Mon, Feb 15, 2016 at 11:07:11AM +0200, Andriy Gapon wrote:
> On 15/02/2016 00:27, Alan Cox wrote:
> > 
> > On Sun, Feb 14, 2016 at 8:09 AM, Andriy Gapon  > > wrote:
> > 
> > On 10/02/2016 23:28, Andriy Gapon wrote:
> > >
> > > Over a span of approximately 3 weeks I have got two slightly 
> > different panics of
> > > the same kind.   The affected system is a several months old amd64 
> > head.
> > 
> > I added a small assertion and it got tripped:
> [snip]
> > 
> > So, it seems that the code allows modification of read_ahead field of 
> > an entry
> > without holding a map lock.  I'd guess that that should be mostly 
> > harmless as
> > read_ahead value is not critical, but it is still not nice.
> > 
> > Not intentionally.  The nearby code to the read_ahead assignment expects 
> > the map
> > to be locked, so I wouldn't categorize this as mostly harmless.
> > 
> > In general, you shouldn't get to the read_ahead assignment without the map 
> > being
> > locked, and almost all of the code paths that unlock the map jump to 
> > RetryFault
> > shortly thereafter, so it's hard to imagine how the map lock wouldn't be
> > reacquired.  I speculate that the root cause of your panic is a case where
> > vm_pager_get_pages() fails, and in such a case we might loop around, 
> > descending
> > to the next backing object without reacquiring the map lock.  In other 
> > words,
> > your above assertion failure is happening on the next iteration after an 
> > initial
> > vm_pager_get_pages() failure, and we're about to do another 
> > vm_pager_get_pages()
> > call on a different object.
> > 
> > In summary, I have no trouble believing that the code that handles a 
> > failure by
> > vm_pager_get_pages() in vm_fault() is not quite right, and I think that's 
> > what's
> > biting you.
> 
> Alan,
> 
> thank you very much for the very insightful analysis.
> Indeed, I see that in this case the object chain is default -> swap -> swap.  
> I
> am not sure how such chain was created.  It seems that going default -> swap 
> is
> not a problem as the map lock is not dropped in this case.  But going swap ->
> swap the way you described (pager error, e.g. the page is just not found) has
> exactly the problem that you suggested.
> 

So this is arguably a fallout from r188331.
The following is somewhat non-insistent attempt to fix the problem.

diff --git a/sys/vm/vm_fault.c b/sys/vm/vm_fault.c
index a7e3d37..cddf1eb 100644
--- a/sys/vm/vm_fault.c
+++ b/sys/vm/vm_fault.c
@@ -291,7 +291,8 @@ vm_fault_hold(vm_map_t map, vm_offset_t vaddr, vm_prot_t 
fault_type,
struct faultstate fs;
struct vnode *vp;
vm_page_t m;
-   int ahead, behind, cluster_offset, error, locked;
+   int ahead, behind, cluster_offset, error, locked, rv;
+   u_char behavior;
 
hardfault = 0;
growstack = TRUE;
@@ -550,9 +551,18 @@ readrest:
 * zero-filled pages.
 */
if (fs.object->type != OBJT_DEFAULT) {
-   int rv;
-   u_char behavior = vm_map_entry_behavior(fs.entry);
-
+   if (!fs.lookup_still_valid) {
+   locked = vm_map_trylock_read(fs.map);
+   if (locked)
+   fs.lookup_still_valid = TRUE;
+   if (!locked || fs.map->timestamp !=
+   map_generation) {
+   release_page();
+   unlock_and_deallocate();
+   goto RetryFault;
+   }
+   }
+   behavior = vm_map_entry_behavior(fs.entry);
era = fs.entry->read_ahead;
if (behavior == MAP_ENTRY_BEHAV_RANDOM ||
P_KILLED(curproc)) {
@@ -603,6 +613,7 @@ readrest:
}
ahead = ulmin(ahead, atop(fs.entry->end - vaddr) - 1);
if (era != nera)
+   /* XXX only read-lock on map */
fs.entry->read_ahead = nera;
 
/*
___
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: HELP: Howtwo create a passwd-suitable hash for usage with psswd -H 0?

[RW]

On Thu, 18 Feb 2016 14:16:24 +0100
O. Hartmann wrote:

> Hello out there,
> 
> I run into a problem and digging for a solution didn't work out.
> 
> Problem: I need a string that reflects the hashed password for the
> usage with 
> 
> passwd -H 0

Did you mean -h?

> I think the procedure is using 
> 
> sha512 -s Password
> 
> and using this output for further processing, but how?

It's not as simple as that, password  hashes are usually salted and
iterated. Salting means that the password is combined with a randomly
generated string stored in plaintext, which means that the password
doesn't hash to a fixed string.

I'm not sure exactly what you are trying to do, but crypt(3) may be of
help.
___
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: Thinkpad T410: resume broken

[John Baldwin]

On Thursday, February 18, 2016 08:13:38 PM Alexey Dokuchaev wrote:
> On Sat, May 17, 2014 at 08:20:03AM -0400, John Baldwin wrote:
> > VESA needs to be removed for i915kms, but I've no idea if it needs to be
> > removed for Nvidia.  The video reset code was reworked in 10 so that
> > having VESA is supposed to be like using 'hw.acpi.reset_video=1' on 9,
> > but in theory it works more often.
> 
> This (VESA needs to be removed for i915kms) is news to me: I don't see it
> mentioned in UPDATING, and "options VESA" presents in -CURRENT's (post-KMS
> era) GENERIC kernel config.  So what's the real deal here? :-)

This is an old mail you are responding to.  You no longer need to remove VESA
for kms.

> If "having VESA is supposed to be like using 'hw.acpi.reset_video=1' on
> 9", it should not hurt (I recall having to hw.acpi.reset_video=1 in early
> stable/[67] days, but no longer for quite a long time with stable/8).
> 
> Admittedly, the whole situation with i915kms, vesa.ko, et al. looks quite
> confusing, while suspend/resume works *worse* than with stable/8 and pre-
> KMS.  Table of known laptops on wiki page [1] is hardly helpful unless it
> has your laptop of interest; IMHO it would benefit a lot more from listing
> common symptoms and mitigation/fixes for them (including VESA, sysctl vars,
> kernel options, etc).

The value of "worse" depends on your laptop.  I have an older i386 HP
netbook for which resume works fine using sc(4) and the older DRM drivers
because the video BIOS turns the LCD back on during resume without requiring
the OS to do so.  However, the recent GPU chipsets from Intel do not do that
and the only bit of code in the tree that knows how to turn the LCD panel
back on is the KMS driver.  However, note that KMS is not related to
NVidia GPUs.  If your laptop is using one of those then the nvidia driver is
what has to turn the LCD panel back on.

> > ACPI_PM setting to the kernel module along with removing VESA would seem
> > like your best bet, but I see in follow-ups that that wasn't completely
> > reliable.  However, you can try using ACPI_PM with syscons, no need to
> > use vt.
> 
> What are indications for use of ACPI_PM option?  As for removing VESA,
> I've found that my laptop resumes more willingly with i915kms.ko *and*
> vesa.ko than without vesa.ko (could only? be loaded from loader.conf):
> with both modules loaded it takes only three presses of power button to
> get back from suspend, while without vesa.ko it's a lottery, and often
> power-cycling is required to get things back to working -- any ideas on
> why would that be?

vesa.ko shouldn't be working with KMS.  KMS turns off the legacy VGA
emulation in the hardware when it starts which prevents VESA from working
(VESA requires the legacy VGA interface).  I never have to hit the power
button more than once to resume on a laptop where resume works though.

(True on my X220 and on a T440 both with Intel or Radeon graphics (all
using KMS).

> Needless to say, suspend/resume worked nearly flawlessly under stable/8
> and stable/7 FWIW.

If it worked here, then this means you could try using sc(4) + the old drm
(not drm2).  This means your laptop is old enough to still turn the LCD panel
back on in its BIOS during resume like my HP netbook.  However, I don't know
for how much longer Xorg will support the older drm (if it even does now).

FWIW, the HP netbook resumes fine with KMS as well for me.  One caveat
though is that if you are using vt(4) and haven't yet loaded KMS it won't
resume (due to vt(4) not having the equivalent of VESA).  With sc(4) the
netbook was always able to resume.

-- 
John Baldwin
___
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: Thinkpad T410: resume broken

[John Baldwin]

On Thursday, February 18, 2016 08:37:38 PM Alexey Dokuchaev wrote:
> On Fri, May 23, 2014 at 10:00:30AM -0400, John Baldwin wrote:
> > On Wednesday, May 21, 2014 3:43:49 pm Jan Henrik Sylvester wrote:
> > > Looking through dmesg, it seems that other USB devices (build-in) are
> > > reappearing (Qualcomm Gobi 2000, Broadcom Bluetooth Device) after
> > > resume, just not the mouse.
> > > 
> > > Are these lines likely related?
> > > 
> > > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.PEG_:
> > > AE_BAD_PARAMETER
> > > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP1:
> > > AE_BAD_PARAMETER
> > > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP2:
> > > AE_BAD_PARAMETER
> > > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP4:
> > > AE_BAD_PARAMETER
> > > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP5:
> > > AE_BAD_PARAMETER
> > 
> > These are probably not related.  These man that your BIOS explicitly told
> > the OS to power down these devices (PEG_ is probably your GPU, and EXP[1-5]
> > are probably PCI-PCI bridges that represent the downstream ports of your
> > PCI-e root complex) in the D2 state when suspending, but the devices don't
> > actually support D2 (most PCI devices only support D0 (full on) and D3
> > (full off)).
> 
> I've started to observe similar lines in the logs after updating to fresh
> -CURRENT, upon resume (on a different laptop though, not T410):
> 
>   pcib0: failed to set ACPI power state D2 on \_SB_.PCI0: AE_BAD_PARAMETER
>   acpi0: cleared fixed power button status
> 
> If these messages are legit, I'm wondering why I didn't see them on 8.4,
> and if it might affect suspend/resume sequence (broken right now)?  Thanks,

8.4 has a bug fixed only in HEAD where we tried to power down the wrong
devices during suspend (or used the _Sx hint from the wrong device to decide
which Dx state to use when powering down, I can't recall which).  For this
reason, 11 is going to use different Dx states on different devices.  The
reason for the message remains the same (though it should now be correct on
11).  Your BIOS said "please put this device in D2 during suspend" and your
device's capabilites said "I don't support D2".  You can confirm this by
looking up the _S3 method of your _SB_.PCIO device to find out what state is
requested during suspend and then looking at 'pciconf -lc pci0:0:0' to see
what D states are listed as supported.  There's not much we can do if your
BIOS lies to us.

-- 
John Baldwin
___
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

[Dan Mack]

On Thu, 18 Feb 2016, Joe Holden wrote:


On 17/02/2016 14:07, Daniel Kalchev wrote:



On 17.02.2016 ?., at 15:40, Shawn Webb  wrote:

TL;DR: FreeBSD is not affected by CVE-2015-7547.



Unless you use Linux applications under emulation.

Daniel

Which is supported by ports so at most it should be a ports advisory and 
not a FreeBSD (base) SA and therefore not on the website.


Just my 2p ;)


Documenting and putting out security advisiories for other operating
systems seems like a bad precedent in general.  The same could be said
for runniing java applications, windows under bhyve, etc. - *sigh* -
if the cross over use is common via a port, then have the port maybe
remind users to consult their distribution specific security
vulnerabilites prior to running it maybe - which is what they should
be doing anyway.

That's my two insignificant cents :-)

Dan

___
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_HEAD_i386 - Build #2369 - Failure

[jenkins-admin]

FreeBSD_HEAD_i386 - Build #2369 - Failure:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2369/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2369/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2369/console

Change summaries:

295756 by zbb:
Extract common code from PowerPC's ofw_pci

Import portions of the PowerPC OF PCI implementation into
new file "ofw_pci.c", common for other platforms. The files ofw_pci.c and
ofw_pci.h from sys/powerpc/ofw no longer exist. All required declarations
are moved to sys/dev/ofw/ofw_pci.h.

This creates a new ofw_pci_write_ivar() function and modifies
ofw_pci_nranges(), ofw_pci_read_ivar(), ofw_pci_route_interrupt() methods.
Most functions contain existing ppc implementations in the majority
unchanged. Now there is no need to have multiple identical copies
of methods for various architectures.

Submitted by:  Marcin Mazurek 
Obtained from: Semihalf
Sponsored by:  Annapurna Labs
Reviewed by:   jhibbits, mmel
Differential Revision: https://reviews.freebsd.org/D4879

295755 by zbb:
Introduce bus_get_bus_tag() method

Provide bus_get_bus_tag() for sparc64, powerpc, arm, arm64 and mips
nexus and its children in order to return a platform specific default tag.

This is required to ensure generic correctness of the bus_space tag.
It is especially needed for arches where child bus tag does not match
the parent bus tag. This solves the problem with ppc architecture
where the PCI bus tag differs from parent bus tag which is big-endian.

This commit is a part of the following patch:
https://reviews.freebsd.org/D4879

Submitted by:  Marcin Mazurek 
Obtained from: Semihalf
Sponsored by:  Annapurna Labs
Reviewed by:   jhibbits, mmel
Differential Revision: https://reviews.freebsd.org/D4879

295754 by zbb:
Fix bug in ofwbus_release_resource() for non-ofwbus descendants

Resource list for devices that are not ofwbus descendants, but
got to ofwbus method via bus_generic_release_resource() call chain,
cannot be found using BUS_GET_RESOURCE_LIST() used by ofwbus.
In that case, changing device's resource list should be avoided
(will not contain resource list prepared by ofw or simplebus).

Pointy-hat to: zbb
Reviewed by:   wma
Obtained from: Semihalf
Sponsored by:  Cavium
Differential Revision: https://reviews.freebsd.org/D5304

295753 by wma:
Fix ThunderX external PEM bus offset

Obtained from: Semihalf
Sponsored by:  Cavium
Approved by:   cognet (mentor)
Reviewed by:   zbb
Differential revision: https://reviews.freebsd.org/D5293



The end of the build log:

[...truncated 209624 lines...]
--- uart_dbg.o ---
cc  -c -O -pipe  -g -nostdinc  -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt 
-D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h  -mno-mmx -mno-sse 
-msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall 
-Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes 
-Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign 
-D__printf__=__freebsd_kprintf__  -Wmissing-include-dirs 
-fdiagnostics-show-option  -Wno-unknown-pragmas  
-Wno-error-tautological-compare -Wno-error-empty-body  
-Wno-error-parentheses-equality -Wno-error-unused-function  
-Wno-error-pointer-sign -Wno-error-shift-negative-value  -mno-aes -mno-avx  
-std=iso9899:1999 -Werror  /usr/src/sys/dev/uart/uart_dbg.c
ctfconvert -L VERSION -g uart_dbg.o
--- uart_subr.o ---
cc  -c -O -pipe  -g -nostdinc  -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt 
-D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h  -mno-mmx -mno-sse 
-msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall 
-Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes 
-Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign 
-D__printf__=__freebsd_kprintf__  -Wmissing-include-dirs 
-fdiagnostics-show-option  -Wno-unknown-pragmas  
-Wno-error-tautological-compare -Wno-error-empty-body  
-Wno-error-parentheses-equality -Wno-error-unused-function  
-Wno-error-pointer-sign -Wno-error-shift-negative-value  -mno-aes -mno-avx  
-std=iso9899:1999 -Werror  /usr/src/sys/dev/uart/uart_subr.c
ctfconvert -L VERSION -g uart_subr.o
--- tmc18c30.o ---
ctfconvert -L VERSION -g tmc18c30.o
--- ehci.o ---
cc  -c -O -pipe  -g -nostdinc  -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt 
-D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h  -mno-mmx -mno-sse 
-msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall 
-Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes 
-Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign 
-D__printf__=__freebsd_kprintf__  -Wmissing-include-dirs 
-fdiagnostics-show-option  -Wno-unknown-pragmas  
-Wno-error-tautological-compare -Wno-error-empty-body  
-Wno-error-parentheses-equality -Wno-error-unused-function  
-Wno-error-pointer-sign 

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

[Joe Holden]

On 17/02/2016 14:07, Daniel Kalchev wrote:



On 17.02.2016 г., at 15:40, Shawn Webb  wrote:

TL;DR: FreeBSD is not affected by CVE-2015-7547.



Unless you use Linux applications under emulation.

Daniel

Which is supported by ports so at most it should be a ports advisory and 
not a FreeBSD (base) SA and therefore not on the website.


Just my 2p ;)
___
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"

HELP: Howtwo create a passwd-suitable hash for usage with psswd -H 0?

[O. Hartmann]

Hello out there,

I run into a problem and digging for a solution didn't work out.

Problem: I need a string that reflects the hashed password for the usage with 

passwd -H 0

I think the procedure is using 

sha512 -s Password

and using this output for further processing, but how?

I looked for a possibility to emmit the hash created by passwd to be used, but
I couldn't find anything useful.

It is crucial that we use utilities available in the base system of FreeBSD, so
no fancy Python or Perl scripts.

I might have overlooked something in my desperate quest, so I'm sorry if the
task is trivial and already standard.

Kind regards and than you very much in advance,

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"

Unable to kldload vesa.ko (but works from loader.conf)

[Alexey Dokuchaev]

Hi there,

I've decided to give -CURRENT a try on my i386 laptop with a 915GM video
(supported by i915kms.ko) @ r295286; minimal kernel with most of the stuff
loaded from /boot/loader.conf.

While debugging suspend/resume issues, I've found out that loading vesa.ko
now apparently only works from /boot/loader.conf: doing it manually from
the command line after logging in gives me this error in dmesg(8):

module_register_init: MOD_LOAD (vesa, 0x, 0) error 19

Some scattered reports on the net did not shed the light on whether this
is expected behavior these days (which is a bit unexpected for a stable/8
user) or a regression due to lack of testing of standalone vesa.ko since
VESA is a default option in GENERIC.  Shall I file a PR?

./danfe
___
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"