Re: lots of security advisories rehashed

[Bob Bishop]

Hi,

> On 12 Aug 2016, at 13:16, Matthew Seaman  wrote:
> 
> […]
> Note that these are capturing the last several years worth of security
> advisories for the base system into VuXML.  This allows you to say, for
> instance:
> 
>   pkg audit FreeBSD-10.3_2
> 
> which will tell you about a number of security advisories which have
> come out since 10.3-RELEASE-p2.  This is in anticipation of the base
> system being packaged, which is due to come in with 11.1-RELEASE.
> 
> See Mark Felder's announcement on questions@:

Why is this hiding out on questions@ ?

> https://lists.freebsd.org/pipermail/freebsd-questions/2016-August/273034.html
> 
> As Mark says, this is not guaranteed to be either accurate or complete,
> but it should be helpful in managing system upgrades.
> 
>   Cheers,
> 
>   Matthew
> 
> 

--
Bob Bishop
r...@gid.co.uk




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

Re: lots of security advisories rehashed

[Mark Felder]

On Mon, Aug 15, 2016, at 05:27, Bob Bishop wrote:
> 
> Why is this hiding out on questions@ ?
> 

I wanted to reach a broader audience.

-- 
  Mark Felder
  ports-secteam member
  f...@freebsd.org
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: fsck_ufs dumps core

[Dmitry Sivachenko]

> On 12 Aug 2016, at 08:51, Konstantin Belousov  wrote:
> 
> On Wed, Aug 10, 2016 at 06:11:39PM +0300, Dmitry Sivachenko wrote:
>> 
>>> On 10 Aug 2016, at 17:55, Konstantin Belousov  wrote:
>>> 
>>> On Wed, Aug 10, 2016 at 05:29:31PM +0300, Dmitry Sivachenko wrote:
 Hello,
 
 I am running FreeBSD 10.3-STABLE #0 r299261M
 
 After unclean reboot I am unable to fsck my UFS filesystem:
 
 # fsck  /dev/mfid0p1
 ** /dev/mfid0p1
 ** Last Mounted on /opt
 ** Phase 1 - Check Blocks and Sizes
 fsck: /dev/mfid0p1: Segmentation fault
 
 pid 482 (fsck_ufs), uid 0: exited on signal 11 (core dumped)
 
 # gdb -c fsck_ufs.482 /sbin/fsck_ufs 
 GNU gdb 6.1.1 [FreeBSD]
 Copyright 2004 Free Software Foundation, Inc.
 GDB is free software, covered by the GNU General Public License, and you 
 are
 welcome to change it and/or distribute copies of it under certain 
 conditions.
 Type "show copying" to see the conditions.
 There is absolutely no warranty for GDB.  Type "show warranty" for details.
 This GDB was configured as "amd64-marcel-freebsd"...
 Core was generated by `fsck_ufs'.
 Program terminated with signal 11, Segmentation fault.
 Reading symbols from /lib/libufs.so.6...done.
 Loaded symbols for /lib/libufs.so.6
 Reading symbols from /lib/libc.so.7...done.
 Loaded symbols for /lib/libc.so.7
 Reading symbols from /libexec/ld-elf.so.1...done.
 Loaded symbols for /libexec/ld-elf.so.1
 #0  0x00409a8b in pass1 () at 
 /place/WRK/src/sbin/fsck_ffs/pass1.c:83
 83  setbmap(i);
 (gdb) bt
 #0  0x00409a8b in pass1 () at 
 /place/WRK/src/sbin/fsck_ffs/pass1.c:83
 #1  0x00409050 in main (argc=, 
   argv=) at /place/WRK/src/sbin/fsck_ffs/main.c:447
 Current language:  auto; currently minimal
 (gdb) 
 
>>> 
>>> Try to use alternative superblock (-b switch).  You can get the list of
>>> the possible values for -b by 'newfs -N' invocation, but you have to know
>>> the parameters which were used for formatting.
>> 
>> 
>> Yes, I tried several different backup superblocks, with the same result.  (I 
>> created this FS few years ago so I can't be 100% sure about the parameters, 
>> but I usually only use larger -i NN for big filesystems, and I can guess the 
>> exact value examining df -ik).
>> 
>> 
>> BTW I just noticed that when I use larger values for backup superblock, it 
>> reports an error which looks like overflow:
>> 
>> # fsck_ufs -b 7437746112 /dev/mfid0p1
>> Alternate super block location: -1152188480
>> ** /dev/mfid0p1
>> 
>> CANNOT SEEK BLK: -1152188480
>> CONTINUE? [yn] 
> 
> Well, it seems that your beginning of the volume got obliterated.
> Fsck_ffs cannot convert random sequence of bytes into the valid FFS
> volume.
> 
> The only other way to try is to restore content of the cylinder groups
> which are farther away from the start.  Create a scratch volume of the
> same size, newfs it with the same parameters.  Then dd from the broken
> volume to the new one, with some offset.  Offset should be large enough
> to not include initial superblock, and if the zero cg is damaged, skip
> it as well.  You should use seek=n skip=n (i.e. the same initial offsets
> both for input and output).


Okay, then it was simpler for me to backup vital data from this volume and do 
newfs on it (rather that dd 145TB of data).

But fsck_ufs -b still does not work (after fresh newfs):

# fsck_ufs -b 343748128704 /dev/mfid0p1 
Alternate super block location: 150745024
** /dev/mfid0p1
150745024 is not a file system superblock


343748128704 was taken from freshly made newfs.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Very odd behavior with RC2

[Karl Denninger]

FreeBSD 11.0-PRERELEASE #2 r304166: Mon Aug 15 13:17:09 CDT 2016
k...@newfs.denninger.net:/usr/obj/usr/src/sys/KSD-SMP

Symptoms:

This machine is on a SuperMicro board with the integrated KVM.

After updating to this from the previous Alpha release this morning
(built circa July 15th) the emulated keyboard disappeared intermittently
(!) and would not register keypresses.  There appears to have been
something that has changed quite-materially in the loader and/or the
kernel in this regard.  Screen display was unaffected.

Toggling the mouse mode would restore the keyboard; this causes a detach
and reattach of the virtual keyboard to the system, and it would then work.

Just a heads-up as this was wildly unexpected and needless to say caused
me quite a bit of heartburn trying to perform the upgrade and mergemaster!

-- 
Karl Denninger
k...@denninger.net 
/The Market Ticker/
/[S/MIME encrypted email preferred]/


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Very odd behavior with RC2

[Karl Denninger]

On 8/15/2016 15:52, Karl Denninger wrote:
> FreeBSD 11.0-PRERELEASE #2 r304166: Mon Aug 15 13:17:09 CDT 2016
> k...@newfs.denninger.net:/usr/obj/usr/src/sys/KSD-SMP
>
> Symptoms:
>
> This machine is on a SuperMicro board with the integrated KVM.
>
> After updating to this from the previous Alpha release this morning
> (built circa July 15th) the emulated keyboard disappeared intermittently
> (!) and would not register keypresses.  There appears to have been
> something that has changed quite-materially in the loader and/or the
> kernel in this regard.  Screen display was unaffected.
>
> Toggling the mouse mode would restore the keyboard; this causes a detach
> and reattach of the virtual keyboard to the system, and it would then work.
>
> Just a heads-up as this was wildly unexpected and needless to say caused
> me quite a bit of heartburn trying to perform the upgrade and mergemaster!
>
From the PR I filed on this...

Scanning back through recent commits I am wondering if this one is
related; the problem occurs after the kernel is loaded (I can use the
keyboard on the KVM perfectly well in the BIOS, etc) and once the system
is fully up and running it works as well.  It is only if/when geli wants
a password *during the boot process* that the keyboard is hosed.

r304124 | hselasky | 2016-08-15 03:58:55 -0500 (Mon, 15 Aug 2016) | 7 lines

MFC r303765:
Keep a reference count on USB keyboard polling to allow recursive
cngrab() during a panic for example, similar to what the AT-keyboard
driver is doing.

Found by:   Bruce Evans 

The reason this looks possibly-related is that the KVM attaches as a USB
keyboard and a plugged-in USB keyboard also exhibits the problem
during the boot-time process, as shown here from the boot log on one of
the impacted machines

Enter passphrase for da8p4:
ugen1.2:  at usbus1
ukbd0:  on usbus1
kbd2 at ukbd0

And...

uhid0:  on usbus4

Hmmm.

-- 
Karl Denninger
k...@denninger.net 
/The Market Ticker/
/[S/MIME encrypted email preferred]/


smime.p7s
Description: S/MIME Cryptographic Signature