Re: more fallout from removal of lint

[Mark Millard]

[I need to be more careful about identifying
the context I'm referring to.]

On 2018-Jan-4, at 7:13 PM, Mark Millard  wrote:

> Mark Heily mark at heily.com wrote on
> Thu Jan 4 14:06:18 UTC 2018 :
> 
>> the build system for CURRENT can be changed in
>> ways that make it incompatible with building STABLE. This is normal and
>> expected behavior for a development branch. It has never been a *supported*
>> option to mix and match source code from different branches on a single
>> host.

The original material below was tied to
buildworld buildkernel activity of itself.

This is somewhat different than having
COMPAT_FREEBSD*'s in the live kernel and
running an already correctly built, older
world in a jail based on such a newer
kernel and world.

> If I understand right, at the transition from
> stable/11 to release/12.0 and stable/12,
> stable/11 is supposed to be able to build 12
> as part of a source based upgrade. (Normally
> the most recent release/11.? should be able
> to as well? The oldest supported release/11.?
> as well?)
> 
> So at certain times one direction of mixing
> seems to be supported for specific versions
> in order to allow progressing forward.
> 
> That does not mean that the other direction
> is supported.

This can have implications for poudriere,
needing to use "pre-built distribution
options" instead of "build from source
options". There would be source around
that "will not be built from" but for
which the source tree is used in the
jail, at least to build ports that
contain modules. (This is another
case of having sources from multiple
branches on a single host. But
the usage is not for buildworld
buildkernel in this context.)

For custom configurations, one might
have to use, say, stable/11/ to build
a world that is then to be put in a
head/ context for use in poudriere.
This avoids building stable/11/
from a head/ context.

More direct jail use may be similar.
(I've only used jails via poudriere.)

Unlike for, say, stable/11/ vs.
stable/10/ there could be temporary
periods for head/ for which some
COMPAT_FREEBSD*'s might not work,
even if such is normally avoided.
This is a risk vs., say, stable/11/
running a jail that has a
stable/10/ world.

> On Thu, Jan 4, 2018 at 6:17 AM, O. Hartmann  wrote:
>> On Tue, 2 Jan 2018 09:33:08 -0500
>> Shawn Webb  wrote:
>> 
>>> On Mon, Jan 01, 2018 at 05:14:00PM -0800, Don Lewis wrote:
 Since lint was removed from 12.0-CURRENT, it is not possible to build
 11.1-STABLE on a 12.0-CURRENT host
> 

The below is tied to buildworld buildkernel
activity of itself.

> It does seem to me that having a head/ based
> system set up to do the stable/?? builds is
> backwards generally under the normal principles
> of operation. The other direction seems to be
> the general intent.
> 
> Even having stable/11 try to build, say,
> stable/10 would seem to be backwards on
> the general principles if I've understood
> right. head/ is not actually essential to
> the issue.

===
Mark Millard
markmi at dsl-only.net


___
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: Intel CPU design flaw - FreeBSD affected?

[Mark Millard]

Darren Reed darrenr at freebsd.org wrote on
Thu Jan 4 11:56:29 UTC 2018 :

> Most people are only talking about meltdown which doesn't hit AMD.
> spectre impacts *both* Intel and AMD.
> 
> SuSE are making available a microcode patch for AMD 17h processors that
> disables branch prediction:
> 
> 
> https://lists.opensuse.org/opensuse-security-announce/2018-01/msg4.html

https://www.amd.com/en/corporate/speculative-execution

reports. . .

For the Bounds Check Bypass Spectre variant (#1):

Resolved by software / OS updates to be made available
by system vendors and manufacturers. Negligible performance
impact expected.

For the Branch Target Injection Spectre variant (#2):

Differences in AMD architecture mean there is a near zero
risk of exploitation of this variant. Vulnerability to
Variant 2 has not been demonstrated on AMD processors to
date.

For the Rogue Data Cache Load Meltdown variant (#3):

Zero AMD vulnerability due to AMD architecture differences.



How long #2 will have a "has not been demonstrated" status
is yet to be seen.

===
Mark Millard
markmi at dsl-only.net

___
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: more fallout from removal of lint

[Mark Millard]

Mark Heily mark at heily.com wrote on
Thu Jan 4 14:06:18 UTC 2018 :

> the build system for CURRENT can be changed in
> ways that make it incompatible with building STABLE. This is normal and
> expected behavior for a development branch. It has never been a *supported*
> option to mix and match source code from different branches on a single
> host.

If I understand right, at the transition from
stable/11 to release/12.0 and stable/12,
stable/11 is supposed to be able to build 12
as part of a source based upgrade. (Normally
the most recent release/11.? should be able
to as well? The oldest supported release/11.?
as well?)

So at certain times one direction of mixing
seems to be supported for specific versions
in order to allow progressing forward.

That does not mean that the other direction
is supported.


On Thu, Jan 4, 2018 at 6:17 AM, O. Hartmann  wrote:
> On Tue, 2 Jan 2018 09:33:08 -0500
> Shawn Webb  wrote:
>
> > On Mon, Jan 01, 2018 at 05:14:00PM -0800, Don Lewis wrote:
> > > Since lint was removed from 12.0-CURRENT, it is not possible to build
> > > 11.1-STABLE on a 12.0-CURRENT host

It does seem to me that having a head/ based
system set up to do the stable/?? builds is
backwards generally under the normal principles
of operation. The other direction seems to be
the general intent.

Even having stable/11 try to build, say,
stable/10 would seem to be backwards on
the general principles if I've understood
right. head/ is not actually essential to
the issue.

===
Mark Millard
markmi at dsl-only.net

___
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: Intel CPU design flaw - FreeBSD affected? Information from Arm

[Jon Brawn]

Wotcha!

My employer, Arm, have made the following website available to help with 
deciding what to do about this security issue.

http://www.arm.com/security-update 

Note: I am not writing here as a representative of Arm, and cannot provide 
further information about this issue. I would encourage you to read all the 
pages and the white paper thoroughly to best understand this issue as it 
relates to working with Arm processors.

Jon.

smime.p7s
Description: S/MIME cryptographic signature

Re: Programmatically cache line

[Jon Brawn]

> On Jan 4, 2018, at 4:03 AM, David Chisnall  wrote:
> 
> On 3 Jan 2018, at 22:12, Nathan Whitehorn  wrote:
>> 
>> On 01/03/18 13:37, Ed Schouten wrote:
>>> 2018-01-01 11:36 GMT+01:00 Konstantin Belousov :
>>> On x86, the CPUID instruction leaf 0x1 returns the information in
>>> %ebx register.
>> Hm, weird. Why don't we extend sysctl to include this info?
 For the same reason we do not provide a sysctl to add two integers.
>>> I strongly agree with Kostik on this one. Why add stuff to the kernel,
>>> if userspace is already capable of extracting this? Adding that stuff
>>> to sysctl has the downside that it will effectively introduce yet
>>> another FreeBSDism, whereas something generic already exists.
>>> 
>> 
>> Well, kind of. The userspace version is platform-dependent and not always 
>> available: for example, on PPC, you can't do this from userland and we 
>> provide a sysctl machdep.cacheline_size to userland. It would be nice to 
>> have an MI API.
> 
> On ARMv8, similarly, sometimes the kernel needs to advertise the wrong size.  
> A few big.LITTLE cores have 64-byte cache lines on one cluster and 32-byte on 
> the other.  If you query the size from userspace while running on a 64-byte 
> cluster, then issue the zero-cache-line instruction while migrated to the 
> 32-byte cluster, you only clear half the size.  Linux works around this by 
> trapping and emulating the instruction to query the cache size and always 
> reporting the size for the smallest cache lines.  ARM tells people not to 
> build systems like this, but it doesn’t always stop them.  Trapping and 
> emulating is much slower than just providing the information in a shared 
> page, elf aux args vector, or even (often) a system call.
> 
> To give another example, Linux provides a very cheap way for a userspace 
> process to enquire which core it’s running on.  Some more recent 
> high-performance mallocs use this to have a second-layer per-core cache after 
> the per-thread cache for free blocks.  Unlike the per-thread cache, the 
> per-core cache does need a lock, but it’s very unlikely to be contended (it 
> will only be contended if either a thread is migrated in between checking and 
> locking, so acquires the wrong CPU’s lock, or if a thread is preempted in the 
> middle of middle of the very brief fill operation).  The author of the 
> SuperMalloc paper tried doing this with CPUID and found that it was slower by 
> a sufficient margin to almost entirely offset the benefits of the extra layer 
> of caching.  
> 
> Just because userspace can get at the information directly from the hardware 
> doesn’t mean that this is the most efficient or best way for userspace to get 
> at it.
> 
> Oh, and some of these things are useful in portable code, so having to write 
> some assembly for every target to get information that the kernel already 
> knows is wasteful.
> 
> David

This idea of Arm big.LITTLE systems having cache lines of different lengths 
really, really bothers me - how on earth is the cache coherency supposed to 
work in such a system? I doubt the usual cache coherency protocols would work - 
probably need a really MESSY protocol to deal with this config :-)

Jon.

smime.p7s
Description: S/MIME cryptographic signature

Re: To which list should I submit a patch?

[Conrad Meyer]

IMO, either is fine.  I think documentation may refer to docs outside
of the src tree, whereas this is in the src tree.  Thanks for the
submission.

Best,
Conrad

On Thu, Jan 4, 2018 at 12:42 PM, Leonardo Fogel
 wrote:
>
>
> Hi,
> I have written a short patch that replaces the legacy interface make_dev(9) 
> with the newer one make_dev_s(9) in the DEV_MODULE(9) man page and in an 
> example that is included in the base. I do not know if I should submit it as 
> a PR to "Base System" (since they are in the base tree) or to "Documentation".
> Please, could you kindly give me some suggestion?
> Thank you for your time.
>
> Index: src/share/examples/kld/cdev/module/cdevmod.c
> ===
> --- src/share/examples/kld/cdev/module/cdevmod.c(revision 327530)
> +++ src/share/examples/kld/cdev/module/cdevmod.c(working copy)
> @@ -109,6 +109,7 @@
>  cdev_load(module_t mod, int cmd, void *arg)
>  {
>  int  err = 0;
> +struct make_dev_args mda;
>
>  switch (cmd) {
>  case MOD_LOAD:
> @@ -120,9 +121,15 @@
> printf("Copyright (c) 1998\n");
> printf("Rajesh Vaidheeswarran\n");
> printf("All rights reserved\n");
> -   sdev = make_dev(_devsw, 0, UID_ROOT, GID_WHEEL, 0600, "cdev");
> -   break;  /* Success*/
>
> +   make_dev_args_init();
> +   mda.mda_devsw = _devsw;
> +   mda.mda_uid = UID_ROOT;
> +   mda.mda_gid = GID_WHEEL;
> +   mda.mda_mode = 0600;
> +   err = make_dev_s(, , "cdev");
> +   break;
> +
>  case MOD_UNLOAD:
> printf("Unloaded kld character device driver\n");
> destroy_dev(sdev);
> Index: src/share/man/man9/DEV_MODULE.9
> ===
> --- src/share/man/man9/DEV_MODULE.9 (revision 327530)
> +++ src/share/man/man9/DEV_MODULE.9 (working copy)
> @@ -58,11 +58,13 @@
>  .Xr DECLARE_MODULE 9
>  for more information).
>  The event handler is supposed to create the device with
> -.Fn make_dev
> +.Fn make_dev_s
>  on load and to destroy it when it is unloaded using
>  .Fn destroy_dev .
>  .Sh EXAMPLES
>  .Bd -literal
> +#include 
> +#include 
>  #include 
>  #include 
>
> @@ -74,11 +76,17 @@
>  foo_load(module_t mod, int cmd, void *arg)
>  {
>  int err = 0;
> +struct make_dev_args mda;
>
>  switch (cmd) {
>  case MOD_LOAD:
> -sdev = make_dev(_devsw, 0, UID_ROOT, GID_WHEEL, 0600, "foo");
> -break;  /* Success*/
> +   make_dev_args_init();
> +   mda.mda_devsw = _devsw;
> +   mda.mda_uid = UID_ROOT;
> +   mda.mda_gid = GID_WHEEL;
> +   mda.mda_mode = 0600;
> +   err = make_dev_s(, , "foo");
> +   break;
>
>  case MOD_UNLOAD:
>  case MOD_SHUTDOWN:
> ___
> 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: Intel CPU design flaw - FreeBSD affected? // disabling LDTSC

[Conrad Meyer]

Possibly because Xeon 5400 dates to 2007 — it may have less advanced
speculative / out-of-order execution and may not have the same branch
prediction algorithm as Haswell.

On Thu, Jan 4, 2018 at 1:07 PM, Michael Butler
 wrote:
> On 01/04/18 14:59, Klaus P. Ohrhallinger wrote:
>> On 04.01.2018 19:51, Jan Kokemüller wrote:
>>
>>> It is possible to emulate a high resolution counter with a thread that
>>> continuously increments a variable [1]. This is the reason why browser
>>> vendors are currently disabling the SharedArrayBuffer feature [2].
>>>
>>> [1]: 
>>> https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9e3d4bb6#gistcomment-2311156
>>> [2]: 
>>> https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/
>>
>> I tried the phtread example from [1] but even with some tweaking is does
>> not work at all.
>>
>> This is a multiprocessor system, with moderate load.
>>
>> As far as I understand the matter, it can only work if both threads
>> share the same cpu cache, otherwise the counter variable is either never
>> up-to-date, or has to be fetched and stored from/to memory, which is way
>> too slow for this purpose.
>>
>> Any suggestions ?
>>
>> ---
>>
>> CPU: Intel(R) Xeon(R) CPU   E5420  @ 2.50GHz (2500.14-MHz
>> K8-class CPU)
>> FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
>> FreeBSD/SMP: 2 package(s) x 4 core(s)
>
> Interestingly, the Xeon 5400 series is not listed as vulnerable in the
> Intel documentation where the 5500 and 5600s are; I checked as I have a
> bunch of E5440s in service.
>
> https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00088=en-fr
>
> imb
>
> ___
> 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"

To which list should I submit a patch?

[Leonardo Fogel]

Hi,
I have written a short patch that replaces the legacy interface make_dev(9) 
with the newer one make_dev_s(9) in the DEV_MODULE(9) man page and in an 
example that is included in the base. I do not know if I should submit it as a 
PR to "Base System" (since they are in the base tree) or to "Documentation".
Please, could you kindly give me some suggestion?
Thank you for your time.

Index: src/share/examples/kld/cdev/module/cdevmod.c
===
--- src/share/examples/kld/cdev/module/cdevmod.c(revision 327530)
+++ src/share/examples/kld/cdev/module/cdevmod.c(working copy)
@@ -109,6 +109,7 @@
 cdev_load(module_t mod, int cmd, void *arg)
 {
 int  err = 0;
+struct make_dev_args mda;

 switch (cmd) {
 case MOD_LOAD:
@@ -120,9 +121,15 @@
printf("Copyright (c) 1998\n");
printf("Rajesh Vaidheeswarran\n");
printf("All rights reserved\n");
-   sdev = make_dev(_devsw, 0, UID_ROOT, GID_WHEEL, 0600, "cdev");
-   break;  /* Success*/

+   make_dev_args_init();
+   mda.mda_devsw = _devsw;
+   mda.mda_uid = UID_ROOT;
+   mda.mda_gid = GID_WHEEL;
+   mda.mda_mode = 0600;
+   err = make_dev_s(, , "cdev");
+   break;
+
 case MOD_UNLOAD:
printf("Unloaded kld character device driver\n");
destroy_dev(sdev);
Index: src/share/man/man9/DEV_MODULE.9
===
--- src/share/man/man9/DEV_MODULE.9 (revision 327530)
+++ src/share/man/man9/DEV_MODULE.9 (working copy)
@@ -58,11 +58,13 @@
 .Xr DECLARE_MODULE 9
 for more information).
 The event handler is supposed to create the device with
-.Fn make_dev
+.Fn make_dev_s
 on load and to destroy it when it is unloaded using
 .Fn destroy_dev .
 .Sh EXAMPLES
 .Bd -literal
+#include 
+#include 
 #include 
 #include 

@@ -74,11 +76,17 @@
 foo_load(module_t mod, int cmd, void *arg)
 {
 int err = 0;
+struct make_dev_args mda;

 switch (cmd) {
 case MOD_LOAD:
-sdev = make_dev(_devsw, 0, UID_ROOT, GID_WHEEL, 0600, "foo");
-break;  /* Success*/
+   make_dev_args_init();
+   mda.mda_devsw = _devsw;
+   mda.mda_uid = UID_ROOT;
+   mda.mda_gid = GID_WHEEL;
+   mda.mda_mode = 0600;
+   err = make_dev_s(, , "foo");
+   break;

 case MOD_UNLOAD:
 case MOD_SHUTDOWN:
___
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: Intel CPU design flaw - FreeBSD affected? // disabling LDTSC

[Michael Butler]

On 01/04/18 14:59, Klaus P. Ohrhallinger wrote:
> On 04.01.2018 19:51, Jan Kokemüller wrote:
> 
>> It is possible to emulate a high resolution counter with a thread that
>> continuously increments a variable [1]. This is the reason why browser
>> vendors are currently disabling the SharedArrayBuffer feature [2].
>>
>> [1]: 
>> https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9e3d4bb6#gistcomment-2311156
>> [2]: 
>> https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/
> 
> I tried the phtread example from [1] but even with some tweaking is does
> not work at all.
> 
> This is a multiprocessor system, with moderate load.
> 
> As far as I understand the matter, it can only work if both threads
> share the same cpu cache, otherwise the counter variable is either never
> up-to-date, or has to be fetched and stored from/to memory, which is way
> too slow for this purpose.
> 
> Any suggestions ?
> 
> ---
> 
> CPU: Intel(R) Xeon(R) CPU   E5420  @ 2.50GHz (2500.14-MHz
> K8-class CPU)
> FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
> FreeBSD/SMP: 2 package(s) x 4 core(s)

Interestingly, the Xeon 5400 series is not listed as vulnerable in the
Intel documentation where the 5500 and 5600s are; I checked as I have a
bunch of E5440s in service.

https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00088=en-fr

imb

___
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: Intel CPU design flaw - FreeBSD affected? // disabling LDTSC

[Klaus P. Ohrhallinger]

On 04.01.2018 19:51, Jan Kokemüller wrote:

> It is possible to emulate a high resolution counter with a thread that
> continuously increments a variable [1]. This is the reason why browser
> vendors are currently disabling the SharedArrayBuffer feature [2].
> 
> [1]: 
> https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9e3d4bb6#gistcomment-2311156
> [2]: 
> https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/

I tried the phtread example from [1] but even with some tweaking is does
not work at all.

This is a multiprocessor system, with moderate load.

As far as I understand the matter, it can only work if both threads
share the same cpu cache, otherwise the counter variable is either never
up-to-date, or has to be fetched and stored from/to memory, which is way
too slow for this purpose.

Any suggestions ?

---

CPU: Intel(R) Xeon(R) CPU   E5420  @ 2.50GHz (2500.14-MHz
K8-class CPU)
FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
FreeBSD/SMP: 2 package(s) x 4 core(s)
___
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: r327359: cylinder checksum failed: cg0, cgp: 0x4515d2a3 != bp: 0xd9fba319 Dec 30 23:29:24 <0.2>

[Michael Tuexen]

> On 4. Jan 2018, at 12:14, O. Hartmann  wrote:
> 
> On Thu, 4 Jan 2018 09:10:37 +0100
> Michael Tuexen  wrote:
> 
>>> On 31. Dec 2017, at 02:45, Warner Losh  wrote:
>>> 
>>> On Sat, Dec 30, 2017 at 4:41 PM, O. Hartmann  wrote:
>>> 
 On most recent CURRENT I face the error shwon below on /tmp filesystem
 (UFS2) residing
 on a Samsung 850 Pro SSD:
 
 UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3 !=
 bp: 0xd9fba319
 handle_workitem_freefile: got error 5 while accessing filesystem
 UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3
 != bp: 0xd9fba319
 handle_workitem_freefile: got error 5 while accessing filesystem
 UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3
 != bp: 0xd9fba319
 handle_workitem_freefile: got error 5 while accessing filesystem
 UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3
 != bp: 0xd9fba319
 handle_workitem_freefile: got error 5 while accessing filesystem
 UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3
 != bp: 0xd9fba319
 handle_workitem_freefile: got error 5 while accessing filesystem
 
 I've already formatted the /tmp filesystem, but obviously without any
 success.
 
 Since I face such strange errors also on NanoBSD images dd'ed to SD cards,
 I guess there
 is something fishy ...  
>>> 
>>> 
>>> It indicates a problem. We've seen these 'corruptions' on data in motion at
>>> work, but I hacked fsck to report checksum mismatches (it silently corrects
>>> them today) and we've not seen any mismatch when we unmount and fsck the
>>> filesystem.  
>> Not sure this helps: But we have seen this also after system panics
>> when having soft update journaling enabled. Having soft update journaling
>> disabled, we do not observed this after several panics.
>> Just to be clear: The panics are not related to this issue,
>> but to other network development we do.
>> 
>> You can check using tunefs -p devname if soft update journaling is enabled or
>> not.
> 
> In all cases I reported in earlier and now, softupdates ARE ENABLED on all
> partitions in question (always GPT, in my cases also all on flash based
> devices, SD card and/or SSD).
OK. That seems to be consistent. Here is the config I'm using on m-SATA SSDs
and I'm NOT experiencing the problem:

tunefs: POSIX.1e ACLs: (-a)disabled
tunefs: NFSv4 ACLs: (-N)   disabled
tunefs: MAC multilabel: (-l)   disabled
tunefs: soft updates: (-n) enabled
tunefs: soft update journaling: (-j)   disabled
tunefs: gjournal: (-J) disabled
tunefs: trim: (-t) enabled
tunefs: maximum blocks per file in a cylinder group: (-e)  4096
tunefs: average file size: (-f)16384
tunefs: average number of files in a directory: (-s)   64
tunefs: minimum percentage of free space: (-m) 8%
tunefs: space to hold for metadata blocks: (-k)6408
tunefs: optimization preference: (-o)  time
tunefs: volume label: (-L) 

This was the config I was experiencing the problem:

tunefs: POSIX.1e ACLs: (-a)disabled
tunefs: NFSv4 ACLs: (-N)   disabled
tunefs: MAC multilabel: (-l)   disabled
tunefs: soft updates: (-n) enabled
tunefs: soft update journaling: (-j)   enabled
tunefs: gjournal: (-J) disabled
tunefs: trim: (-t) enabled
tunefs: maximum blocks per file in a cylinder group: (-e)  4096
tunefs: average file size: (-f)16384
tunefs: average number of files in a directory: (-s)   64
tunefs: minimum percentage of free space: (-m) 8%
tunefs: space to hold for metadata blocks: (-k)6408
tunefs: optimization preference: (-o)  time
tunefs: volume label: (-L) 

So "soft updates" are enabled on both configs, but "soft update journaling" is 
different.

Maybe this helps in nailing down the problem.

Best regards
Michael

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

Re: Intel CPU design flaw - FreeBSD affected? // disabling LDTSC

[Jan Kokemüller]

On 04.01.2018 19:23, Klaus P. Ohrhallinger wrote:
> All PoC code I have seen today relies on those instructions.
> Is there any other way to measure the memory/cache access times ?

It is possible to emulate a high resolution counter with a thread that
continuously increments a variable [1]. This is the reason why browser
vendors are currently disabling the SharedArrayBuffer feature [2].

[1]: 
https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9e3d4bb6#gistcomment-2311156
[2]: 
https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/
___
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: Programmatically cache line

[blubee blubeeme]

On Fri, Jan 5, 2018 at 2:29 AM, Konstantin Belousov 
wrote:

> On Thu, Jan 04, 2018 at 10:03:32AM +, David Chisnall wrote:
> > On 3 Jan 2018, at 22:12, Nathan Whitehorn 
> wrote:
> > >
> > > On 01/03/18 13:37, Ed Schouten wrote:
> > >> 2018-01-01 11:36 GMT+01:00 Konstantin Belousov :
> > >> On x86, the CPUID instruction leaf 0x1 returns the information in
> > >> %ebx register.
> > > Hm, weird. Why don't we extend sysctl to include this info?
> > >>> For the same reason we do not provide a sysctl to add two integers.
> > >> I strongly agree with Kostik on this one. Why add stuff to the kernel,
> > >> if userspace is already capable of extracting this? Adding that stuff
> > >> to sysctl has the downside that it will effectively introduce yet
> > >> another FreeBSDism, whereas something generic already exists.
> > >>
> > >
> > > Well, kind of. The userspace version is platform-dependent and not
> always available: for example, on PPC, you can't do this from userland and
> we provide a sysctl machdep.cacheline_size to userland. It would be nice to
> have an MI API.
> >
> > On ARMv8, similarly, sometimes the kernel needs to advertise the wrong
> size.  A few big.LITTLE cores have 64-byte cache lines on one cluster and
> 32-byte on the other.  If you query the size from userspace while running
> on a 64-byte cluster, then issue the zero-cache-line instruction while
> migrated to the 32-byte cluster, you only clear half the size.  Linux works
> around this by trapping and emulating the instruction to query the cache
> size and always reporting the size for the smallest cache lines.  ARM tells
> people not to build systems like this, but it doesn???t always stop them.
> Trapping and emulating is much slower than just providing the information
> in a shared page, elf aux args vector, or even (often) a system call.
>
> Of course MD way is the best way to get such information, just because the
> meaning of the 'cache line size' exists only in context of the given CPU
> (micro)architecture.  For instance, on PowerPC and ARM you are often
> concerned
> with the granularity of the instruction cache flush, but also you might be
> concerned with the DMA, and these are different concepts of cache.
>
> Even on x86, you may care about alignment to avoid false sharing or
> about CLFLUSH granularity, and these can be different legitimately.
> Which one to report as 'cache line' ?
>
> And you cannot bail out with the max among all constants, because sometimes
> you really need the min size (for CLFLUSH), and sometime max size (for
> false sharing).
>
> >
> > To give another example, Linux provides a very cheap way for a userspace
> process to enquire which core it???s running on.  Some more recent
> high-performance mallocs use this to have a second-layer per-core cache
> after the per-thread cache for free blocks.  Unlike the per-thread cache,
> the per-core cache does need a lock, but it???s very unlikely to be
> contended (it will only be contended if either a thread is migrated in
> between checking and locking, so acquires the wrong CPU???s lock, or if a
> thread is preempted in the middle of middle of the very brief fill
> operation).  The author of the SuperMalloc paper tried doing this with
> CPUID and found that it was slower by a sufficient margin to almost
> entirely offset the benefits of the extra layer of caching.
>
> There, RDTSCP is the intended way to get cpu id in userspace, but the use
> of this instruction requires some minimal OS support.  It should be faster
> than CPUID, since it is not fully serializing.  We do not support it only
> because nobody asked so far.
>
> >
> > Just because userspace can get at the information directly from the
> hardware doesn???t mean that this is the most efficient or best way for
> userspace to get at it.
> >
> It depends, but single instruction (!) vs syscall comparision makes this
> discussion silly.
>
> > Oh, and some of these things are useful in portable code, so having to
> write some assembly for every target to get information that the kernel
> already knows is wasteful.
> >
> Required work is to provide the definitions of these interfaces, then they
> can be implemented in the best way for each architecture.  But nobody did
> that.
>
Initially I was "asking" to see if these facilities were available so that
I didn't have to go do some hack job
that would be brittle or reinvent the wheel.

My use case for getting the cache lines was to prevent false sharing.
I should've been more clear about that in my initial email but,
I didn't know all these other people were interested in this issue as well.

since I'd like the cache line sizes to prevent false sharing that's my use
case.

Does anyone else have any use cases that they would like to propose?

Once we have come to some agreement on what features they need,
then we can work out the interfaces and get the work done on implementation?

Re: Programmatically cache line

[Konstantin Belousov]

On Thu, Jan 04, 2018 at 10:03:32AM +, David Chisnall wrote:
> On 3 Jan 2018, at 22:12, Nathan Whitehorn  wrote:
> > 
> > On 01/03/18 13:37, Ed Schouten wrote:
> >> 2018-01-01 11:36 GMT+01:00 Konstantin Belousov :
> >> On x86, the CPUID instruction leaf 0x1 returns the information in
> >> %ebx register.
> > Hm, weird. Why don't we extend sysctl to include this info?
> >>> For the same reason we do not provide a sysctl to add two integers.
> >> I strongly agree with Kostik on this one. Why add stuff to the kernel,
> >> if userspace is already capable of extracting this? Adding that stuff
> >> to sysctl has the downside that it will effectively introduce yet
> >> another FreeBSDism, whereas something generic already exists.
> >> 
> > 
> > Well, kind of. The userspace version is platform-dependent and not always 
> > available: for example, on PPC, you can't do this from userland and we 
> > provide a sysctl machdep.cacheline_size to userland. It would be nice to 
> > have an MI API.
> 
> On ARMv8, similarly, sometimes the kernel needs to advertise the wrong size.  
> A few big.LITTLE cores have 64-byte cache lines on one cluster and 32-byte on 
> the other.  If you query the size from userspace while running on a 64-byte 
> cluster, then issue the zero-cache-line instruction while migrated to the 
> 32-byte cluster, you only clear half the size.  Linux works around this by 
> trapping and emulating the instruction to query the cache size and always 
> reporting the size for the smallest cache lines.  ARM tells people not to 
> build systems like this, but it doesn???t always stop them.  Trapping and 
> emulating is much slower than just providing the information in a shared 
> page, elf aux args vector, or even (often) a system call.

Of course MD way is the best way to get such information, just because the
meaning of the 'cache line size' exists only in context of the given CPU
(micro)architecture.  For instance, on PowerPC and ARM you are often concerned
with the granularity of the instruction cache flush, but also you might be
concerned with the DMA, and these are different concepts of cache.

Even on x86, you may care about alignment to avoid false sharing or
about CLFLUSH granularity, and these can be different legitimately.
Which one to report as 'cache line' ?

And you cannot bail out with the max among all constants, because sometimes
you really need the min size (for CLFLUSH), and sometime max size (for
false sharing).

> 
> To give another example, Linux provides a very cheap way for a userspace 
> process to enquire which core it???s running on.  Some more recent 
> high-performance mallocs use this to have a second-layer per-core cache after 
> the per-thread cache for free blocks.  Unlike the per-thread cache, the 
> per-core cache does need a lock, but it???s very unlikely to be contended (it 
> will only be contended if either a thread is migrated in between checking and 
> locking, so acquires the wrong CPU???s lock, or if a thread is preempted in 
> the middle of middle of the very brief fill operation).  The author of the 
> SuperMalloc paper tried doing this with CPUID and found that it was slower by 
> a sufficient margin to almost entirely offset the benefits of the extra layer 
> of caching.  

There, RDTSCP is the intended way to get cpu id in userspace, but the use
of this instruction requires some minimal OS support.  It should be faster
than CPUID, since it is not fully serializing.  We do not support it only
because nobody asked so far.

> 
> Just because userspace can get at the information directly from the hardware 
> doesn???t mean that this is the most efficient or best way for userspace to 
> get at it.
> 
It depends, but single instruction (!) vs syscall comparision makes this
discussion silly.

> Oh, and some of these things are useful in portable code, so having to write 
> some assembly for every target to get information that the kernel already 
> knows is wasteful.
> 
Required work is to provide the definitions of these interfaces, then they
can be implemented in the best way for each architecture.  But nobody did
that.
___
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: Intel CPU design flaw - FreeBSD affected? // disabling _R_DTSC

[blubee blubeeme]

On Fri, Jan 5, 2018 at 2:25 AM, Klaus P. Ohrhallinger  wrote:

> On 04.01.2018 19:23, Klaus P. Ohrhallinger wrote:
> > Hello,
> >
> > I disabled the ldtsc and ldtscp instructions for usermode on one of my
> > production servers:
> >
>
> Oops, RDTSC of course.
>
> ___
> 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"
>
I'd love to see if RISC-V is vulnerable to this?

I think they are in the best position to capitalize on this clusterfk...
___
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: Intel CPU design flaw - FreeBSD affected? // disabling LDTSC

[Klaus P. Ohrhallinger]

Hello,

I disabled the ldtsc and ldtscp instructions for usermode on one of my
production servers:

% ./spectre
Reading 40 bytes:
Bus error (core dumped)

All PoC code I have seen today relies on those instructions.
Is there any other way to measure the memory/cache access times ?

On 10.4-RELEASE I had to rebuild world and some ports, but now
everything seems to be working fine.
Patches attached.

Regards, Klaus
diff -aupr src.orig/sys/amd64/amd64/initcpu.c src/sys/amd64/amd64/initcpu.c
--- src.orig/sys/amd64/amd64/initcpu.c  2017-09-29 02:20:05.0 +0200
+++ src/sys/amd64/amd64/initcpu.c   2018-01-04 15:19:32.741729000 +0100
@@ -210,6 +210,7 @@ initializecpu(void)
}
if (cpu_stdext_feature & CPUID_STDEXT_FSGSBASE)
cr4 |= CR4_FSGSBASE;
+   cr4 |= CR4_TSD;
 
/*
 * Postpone enabling the SMEP on the boot CPU until the page
diff -aupr src.orig/sys/x86/x86/tsc.c src/sys/x86/x86/tsc.c
--- src.orig/sys/x86/x86/tsc.c  2017-09-29 02:20:06.0 +0200
+++ src/sys/x86/x86/tsc.c   2018-01-04 15:19:32.756123000 +0100
@@ -658,6 +658,7 @@ tsc_freq_changed(void *arg, const struct
 static int
 sysctl_machdep_tsc_freq(SYSCTL_HANDLER_ARGS)
 {
+#if 0
int error;
uint64_t freq;
 
@@ -671,6 +672,9 @@ sysctl_machdep_tsc_freq(SYSCTL_HANDLER_A
freq >> (int)(intptr_t)tsc_timecounter.tc_priv);
}
return (error);
+#else
+   return (EOPNOTSUPP);
+#endif
 }
 
 SYSCTL_PROC(_machdep, OID_AUTO, tsc_freq, CTLTYPE_U64 | CTLFLAG_RW,
diff -aupr src.orig/lib/libc/amd64/sys/__vdso_gettc.c 
src/lib/libc/amd64/sys/__vdso_gettc.c
--- src.orig/lib/libc/amd64/sys/__vdso_gettc.c  2017-09-29 02:20:13.0 
+0200
+++ src/lib/libc/amd64/sys/__vdso_gettc.c   2018-01-04 16:53:31.590961000 
+0100
@@ -30,17 +30,22 @@ __FBSDID("$FreeBSD: releng/10.4/lib/libc
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "libc_private.h"
 
 static u_int
 __vdso_gettc_low(const struct vdso_timehands *th)
 {
+#if 0
uint32_t rv;
 
__asm __volatile("rdtsc; shrd %%cl, %%edx, %0"
: "=a" (rv) : "c" (th->th_x86_shift) : "edx");
return (rv);
+#else
+   return (0);
+#endif
 }
 
 #pragma weak __vdso_gettc
@@ -48,7 +53,11 @@ u_int
 __vdso_gettc(const struct vdso_timehands *th)
 {
 
+#if 0
return (th->th_x86_shift > 0 ? __vdso_gettc_low(th) : rdtsc32());
+#else
+   return (0);
+#endif
 }
 
 #pragma weak __vdso_gettimekeep
@@ -56,5 +65,9 @@ int
 __vdso_gettimekeep(struct vdso_timekeep **tk)
 {
 
+#if 0
return (_elf_aux_info(AT_TIMEKEEP, tk, sizeof(*tk)));
+#else
+   return (ENOSYS);
+#endif
 }
diff -aupr src.orig/lib/libc/i386/sys/__vdso_gettc.c 
src/lib/libc/i386/sys/__vdso_gettc.c
--- src.orig/lib/libc/i386/sys/__vdso_gettc.c   2017-09-29 02:20:14.0 
+0200
+++ src/lib/libc/i386/sys/__vdso_gettc.c2018-01-04 17:03:03.096724000 
+0100
@@ -30,17 +30,22 @@ __FBSDID("$FreeBSD: releng/10.4/lib/libc
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "libc_private.h"
 
 static u_int
 __vdso_gettc_low(const struct vdso_timehands *th)
 {
+#if 0
uint32_t rv;
 
__asm __volatile("rdtsc; shrd %%cl, %%edx, %0"
: "=a" (rv) : "c" (th->th_x86_shift) : "edx");
return (rv);
+#else
+   return (0);
+#endif
 }
 
 #pragma weak __vdso_gettc
@@ -48,7 +53,11 @@ u_int
 __vdso_gettc(const struct vdso_timehands *th)
 {
 
+#if 0
return (th->th_x86_shift > 0 ? __vdso_gettc_low(th) : rdtsc32());
+#else
+   return (0);
+#endif
 }
 
 #pragma weak __vdso_gettimekeep
@@ -56,5 +65,9 @@ int
 __vdso_gettimekeep(struct vdso_timekeep **tk)
 {
 
+#if 0
return (_elf_aux_info(AT_TIMEKEEP, tk, sizeof(*tk)));
+#else
+   return (ENOSYS);
+#endif
 }
___
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: Intel CPU design flaw - FreeBSD affected? // disabling _R_DTSC

[Klaus P. Ohrhallinger]

On 04.01.2018 19:23, Klaus P. Ohrhallinger wrote:
> Hello,
> 
> I disabled the ldtsc and ldtscp instructions for usermode on one of my
> production servers:
> 

Oops, RDTSC of course.

___
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: Intel CPU design flaw - FreeBSD affected?

[Warner Losh]

On Thu, Jan 4, 2018 at 7:33 AM, Stefan Esser  wrote:

> Am 04.01.18 um 12:56 schrieb Darren Reed:
> > On 4/01/2018 11:51 AM, Mark Heily wrote:
> >> On Jan 2, 2018 19:05, "Warner Losh"  wrote:
> >>
> >> The register article says the specifics are under embargo still. That
> would
> >> make it hard for anybody working with Intel to comment publicly on the
> flaw
> >> and any mitigations that may be underway. It would be unwise to assume
> that
> >> all the details are out until the embargo lifts.
> >>
> >>
> >> Details of the flaws are now published at:
> >>
> >> https://meltdownattack.com
> >
> > The web page has both: meltdown and spectre.
> > Most people are only talking about meltdown which doesn't hit AMD.
> > spectre impacts *both* Intel and AMD.
> >
> > SuSE are making available a microcode patch for AMD 17h processors that
> > disables branch prediction:
> >
> > https://lists.opensuse.org/opensuse-security-announce/
> 2018-01/msg4.html
>
> Disabling branch prediction will have a very noticeable effect on execution
> speed in general (while split page tables only affect programs that perform
> system calls at a high frequency).
>
> I have not fully read the Meltdown and Spectre papers, yet, but I do
> assume,
> that the attack at the branch prediction tries to counter KASLR, which we
> do
> not support at all in FreeBSD.
>
> So, I guess, we do not have to bother with disabling of branch prediction
> in
> FreeBSD for the time being?
>

Branch prediction has nothing to do with defeating KASLR. It's rather the
whole crux of the attack. Disabling it is one way to prevent Specter.

The only thing that will help Meltdown, though, is separate page tables.

It's only an incidental foot note that these methods don't care about KASLR
and KASLR isn't at all effective in blunting these attacks.

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

Re: Intel CPU design flaw - FreeBSD affected?

[Chris H]

On Thu, 4 Jan 2018 15:33:46 +0100 "Stefan Esser"  said


Am 04.01.18 um 12:56 schrieb Darren Reed:
> On 4/01/2018 11:51 AM, Mark Heily wrote:
>> On Jan 2, 2018 19:05, "Warner Losh"  wrote:
>>
>> The register article says the specifics are under embargo still. That would
>> make it hard for anybody working with Intel to comment publicly on the flaw
>> and any mitigations that may be underway. It would be unwise to assume that
>> all the details are out until the embargo lifts.
>>
>>
>> Details of the flaws are now published at:
>>
>> https://meltdownattack.com
> 
> The web page has both: meltdown and spectre.

> Most people are only talking about meltdown which doesn't hit AMD.
> spectre impacts *both* Intel and AMD.
> 
> SuSE are making available a microcode patch for AMD 17h processors that

> disables branch prediction:
> 
> https://lists.opensuse.org/opensuse-security-announce/2018-01/msg4.html


Disabling branch prediction will have a very noticeable effect on execution
speed in general (while split page tables only affect programs that perform
system calls at a high frequency).

OUCH! That was the whole point of these; drop cores, and frequency, for huge
cache lines, and branch prediction. You eliminate that branch prediction, and
these become near useless. :-(
Glad I waited, before getting one!



I have not fully read the Meltdown and Spectre papers, yet, but I do assume,
that the attack at the branch prediction tries to counter KASLR, which we do
not support at all in FreeBSD.

So, I guess, we do not have to bother with disabling of branch prediction in
FreeBSD for the time being?

Regards, STefan

--Chris


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

RFC: mallocarray()

[Kristof Provost]

Hi,

I’d like to make it easier to avoid integer overflow issues in the 
kernel.
It’d be a lot nicer to have a malloc function figure this out for us, 
so I’d like mallocarray().


https://reviews.freebsd.org/D13766

Are there any objections to this?

Regards,
Kristof
___
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: Intel CPU design flaw - FreeBSD affected?

[Stefan Esser]

Am 04.01.18 um 12:56 schrieb Darren Reed:
> On 4/01/2018 11:51 AM, Mark Heily wrote:
>> On Jan 2, 2018 19:05, "Warner Losh"  wrote:
>>
>> The register article says the specifics are under embargo still. That would
>> make it hard for anybody working with Intel to comment publicly on the flaw
>> and any mitigations that may be underway. It would be unwise to assume that
>> all the details are out until the embargo lifts.
>>
>>
>> Details of the flaws are now published at:
>>
>> https://meltdownattack.com
> 
> The web page has both: meltdown and spectre.
> Most people are only talking about meltdown which doesn't hit AMD.
> spectre impacts *both* Intel and AMD.
> 
> SuSE are making available a microcode patch for AMD 17h processors that
> disables branch prediction:
> 
> https://lists.opensuse.org/opensuse-security-announce/2018-01/msg4.html

Disabling branch prediction will have a very noticeable effect on execution
speed in general (while split page tables only affect programs that perform
system calls at a high frequency).

I have not fully read the Meltdown and Spectre papers, yet, but I do assume,
that the attack at the branch prediction tries to counter KASLR, which we do
not support at all in FreeBSD.

So, I guess, we do not have to bother with disabling of branch prediction in
FreeBSD for the time being?

Regards, STefan
___
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: Intel CPU design flaw - FreeBSD affected?

[Tomoaki AOKI]

And now official announcement from Intel...

 
https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00088=en-fr


On Wed, 3 Jan 2018 19:51:40 -0500
Mark Heily  wrote:

> On Jan 2, 2018 19:05, "Warner Losh"  wrote:
> 
> The register article says the specifics are under embargo still. That would
> make it hard for anybody working with Intel to comment publicly on the flaw
> and any mitigations that may be underway. It would be unwise to assume that
> all the details are out until the embargo lifts.
> 
> 
> Details of the flaws are now published at:
> 
> https://meltdownattack.com
> 
> 
> Warner
> 
> On Jan 2, 2018 4:13 PM, "Michael Butler"  wrote:
> 
> > Has any impact assessment been made as to FreeBSD's exposure or
> > mitigation strategies?
> >
> > 'Kernel memory leaking' Intel processor design flaw forces Linux,
> > Windows redesign - The Register
> >
> > Other OSes will need an update, performance hits loom A fundamental
> > design flaw in Intel's processor chips has forced a significant redesign
> > of the Linux and Windows kernels to defang the chip-level security bug.…
> > Programmers are scrambling to overhaul the open-source Linux kernel's
> > virtual memory system. Meanwhile, Microsoft is expected to publicly
> > introduce necessary changes to its Windows operating system in this
> > month's Patch Tuesday ...
> >
> > https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
> >
> > imb
> >
> > ___
> > 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"
> 
> 


-- 
Tomoaki AOKI
___
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: more fallout from removal of lint

[Mark Heily]

On Thu, Jan 4, 2018 at 6:17 AM, O. Hartmann  wrote:

> On Tue, 2 Jan 2018 09:33:08 -0500
> Shawn Webb  wrote:
>
> > On Mon, Jan 01, 2018 at 05:14:00PM -0800, Don Lewis wrote:
> > > Since lint was removed from 12.0-CURRENT, it is not possible to build
> > > 11.1-STABLE on a 12.0-CURRENT host
>

There is a big difference between what is "possible" and what is
"supported".
Since CURRENT is branched off of STABLE, there is always a period of time
where the two build systems are compatible. During this time, it is
*possible*
to build STABLE on a CURRENT host.

However, the build system for CURRENT can be changed in
ways that make it incompatible with building STABLE. This is normal and
expected behavior for a development branch. It has never been a *supported*
option to mix and match source code from different branches on a single
host.

Can you try creating a 11.1-STABLE jail on your 12-CURRENT host, and
perform the build within the jail? I'm not clear on what role Poudriere
plays
in all of this, so that may take some additional work to straighten out.

Regards,

 - Mark
___
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: Intel CPU design flaw - FreeBSD affected?

[Darren Reed]

On 4/01/2018 11:51 AM, Mark Heily wrote:
> On Jan 2, 2018 19:05, "Warner Losh"  wrote:
>
> The register article says the specifics are under embargo still. That would
> make it hard for anybody working with Intel to comment publicly on the flaw
> and any mitigations that may be underway. It would be unwise to assume that
> all the details are out until the embargo lifts.
>
>
> Details of the flaws are now published at:
>
> https://meltdownattack.com

The web page has both: meltdown and spectre.
Most people are only talking about meltdown which doesn't hit AMD.
spectre impacts *both* Intel and AMD.

SuSE are making available a microcode patch for AMD 17h processors that
disables branch prediction:

https://lists.opensuse.org/opensuse-security-announce/2018-01/msg4.html

Kind Regards,
Darren

___
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: more fallout from removal of lint

[O. Hartmann]

On Tue, 2 Jan 2018 09:33:08 -0500
Shawn Webb  wrote:

> On Mon, Jan 01, 2018 at 05:14:00PM -0800, Don Lewis wrote:
> > Since lint was removed from 12.0-CURRENT, it is not possible to build
> > 11.1-STABLE on a 12.0-CURRENT host, but I was able to work around that
> > by copying /usr/bin/true to /usr/bin/lint.  Unfortunately, that trick
> > doesn't work when updating a 11.1-STABLE poudriere jail on a
> > 12.0-CURRENT host.
> >   
> > ===> usr.bin/xlint (install)
> > ===> usr.bin/xlint/lint1 (install)  
> > install -N /var/poudriere/jails/111STABLEi386/usr/src/etc  -s -o root -g
> > wheel -m 555   lint1 /var/poudriere/jails/111STABLEi386/usr/libexec/lint1
> > install -N /var/poudriere/jails/111STABLEi386/usr/src/etc  -o root -g wheel
> > -m 444
> > lint1.debug 
> > /var/poudriere/jails/111STABLEi386/usr/lib/debug/usr/libexec/lint1.debug
> > install -N /var/poudriere/jails/111STABLEi386/usr/src/etc  -o root -g wheel
> > -m 444 lint.7.gz  /var/poudriere/jails/111STABLEi386/usr/share/man/man7/
> > ===> usr.bin/xlint/lint2 (install) install
> > -N /var/poudriere/jails/111STABLEi386/usr/src/etc  -s -o root -g wheel -m
> > 555   lint2 /var/poudriere/jails/111STABLEi386/usr/libexec/lint2 install
> > -N /var/poudriere/jails/111STABLEi386/usr/src/etc  -o root -g wheel -m 444
> > lint2.debug 
> > /var/poudriere/jails/111STABLEi386/usr/lib/debug/usr/libexec/lint2.debug
> > ===> usr.bin/xlint/xlint (install) install
> > -N /var/poudriere/jails/111STABLEi386/usr/src/etc  -s -o root -g wheel -m
> > 555   xlint /var/poudriere/jails/111STABLEi386/usr/bin/lint install
> > -N /var/poudriere/jails/111STABLEi386/usr/src/etc  -o root -g wheel -m 444
> > lint.debug 
> > /var/poudriere/jails/111STABLEi386/usr/lib/debug/usr/bin/lint.debug
> > install -N /var/poudriere/jails/111STABLEi386/usr/src/etc  -o root -g wheel
> > -m 444 lint.1.gz  /var/poudriere/jails/111STABLEi386/usr/share/man/man1/
> > ===> usr.bin/xlint/llib (install) lint -cghapbx
> > -I/usr/obj/i386.i386/var/poudriere/jails/111STABLEi386/usr/src/tmp/usr/include
> > -Cposix 
> > /var/poudriere/jails/111STABLEi386/usr/src/usr.bin/xlint/llib/llib-lposix
> > sh: lint: not found *** [llib-lposix.ln] Error code 127
> > 
> > make[6]: stopped
> > in /var/poudriere/jails/111STABLEi386/usr/src/usr.bin/xlint/llib 1 error
> > 
> > 
> > # ls -l /usr/bin/lint /usr/bin/true
> > -r-xr-xr-x  1 root  wheel  4976 Dec 30 12:37 /usr/bin/lint
> > -r-xr-xr-x  1 root  wheel  4976 Dec 29 21:13 /usr/bin/true  
> 
> I had filed[1] a bug report about this a little over a month ago and
> FreeBSD was disinterested in even discussing it. HardenedBSD worked
> around the issue by disabling the build of lint in its 11-STABLE and
> 10-STABLE trees.
> 
> [1]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223892
> 
> Thanks,
> 

I ran also into this problem and for security reasons, I HAVE TO update several
hosts to 11.1-RELENG-p6. I can not, because the building host (poudriere, also
the binary packages for a binary update of base) is on CURRENT.

I hope this issue gets fixed soon.

Regards,

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

Re: r327359: cylinder checksum failed: cg0, cgp: 0x4515d2a3 != bp: 0xd9fba319 Dec 30 23:29:24 <0.2>

[O. Hartmann]

On Thu, 4 Jan 2018 09:10:37 +0100
Michael Tuexen  wrote:

> > On 31. Dec 2017, at 02:45, Warner Losh  wrote:
> > 
> > On Sat, Dec 30, 2017 at 4:41 PM, O. Hartmann  wrote:
> >   
> >> On most recent CURRENT I face the error shwon below on /tmp filesystem
> >> (UFS2) residing
> >> on a Samsung 850 Pro SSD:
> >> 
> >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3 !=
> >> bp: 0xd9fba319
> >> handle_workitem_freefile: got error 5 while accessing filesystem
> >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3
> >> != bp: 0xd9fba319
> >> handle_workitem_freefile: got error 5 while accessing filesystem
> >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3
> >> != bp: 0xd9fba319
> >> handle_workitem_freefile: got error 5 while accessing filesystem
> >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3
> >> != bp: 0xd9fba319
> >> handle_workitem_freefile: got error 5 while accessing filesystem
> >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3
> >> != bp: 0xd9fba319
> >> handle_workitem_freefile: got error 5 while accessing filesystem
> >> 
> >> I've already formatted the /tmp filesystem, but obviously without any
> >> success.
> >> 
> >> Since I face such strange errors also on NanoBSD images dd'ed to SD cards,
> >> I guess there
> >> is something fishy ...  
> > 
> > 
> > It indicates a problem. We've seen these 'corruptions' on data in motion at
> > work, but I hacked fsck to report checksum mismatches (it silently corrects
> > them today) and we've not seen any mismatch when we unmount and fsck the
> > filesystem.  
> Not sure this helps: But we have seen this also after system panics
> when having soft update journaling enabled. Having soft update journaling
> disabled, we do not observed this after several panics.
> Just to be clear: The panics are not related to this issue,
> but to other network development we do.
> 
> You can check using tunefs -p devname if soft update journaling is enabled or
> not.

In all cases I reported in earlier and now, softupdates ARE ENABLED on all
partitions in question (always GPT, in my cases also all on flash based
devices, SD card and/or SSD).


> 
> Best regards
> Michael
> > 
> > Warner
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"  
> 
> ___
> 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: USB stack

[O'Connor, Daniel]

> On 4 Jan 2018, at 09:23, Gary Jennejohn  wrote:
>> What is an "LG v30"?
>> 
> It's a smartphone from LG and only supports USB2 speed.  The reported
> transfer rate is no big surprise.

OK thanks.

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
 -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

___
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: Programmatically cache line

[David Chisnall]

On 3 Jan 2018, at 22:12, Nathan Whitehorn  wrote:
> 
> On 01/03/18 13:37, Ed Schouten wrote:
>> 2018-01-01 11:36 GMT+01:00 Konstantin Belousov :
>> On x86, the CPUID instruction leaf 0x1 returns the information in
>> %ebx register.
> Hm, weird. Why don't we extend sysctl to include this info?
>>> For the same reason we do not provide a sysctl to add two integers.
>> I strongly agree with Kostik on this one. Why add stuff to the kernel,
>> if userspace is already capable of extracting this? Adding that stuff
>> to sysctl has the downside that it will effectively introduce yet
>> another FreeBSDism, whereas something generic already exists.
>> 
> 
> Well, kind of. The userspace version is platform-dependent and not always 
> available: for example, on PPC, you can't do this from userland and we 
> provide a sysctl machdep.cacheline_size to userland. It would be nice to have 
> an MI API.

On ARMv8, similarly, sometimes the kernel needs to advertise the wrong size.  A 
few big.LITTLE cores have 64-byte cache lines on one cluster and 32-byte on the 
other.  If you query the size from userspace while running on a 64-byte 
cluster, then issue the zero-cache-line instruction while migrated to the 
32-byte cluster, you only clear half the size.  Linux works around this by 
trapping and emulating the instruction to query the cache size and always 
reporting the size for the smallest cache lines.  ARM tells people not to build 
systems like this, but it doesn’t always stop them.  Trapping and emulating is 
much slower than just providing the information in a shared page, elf aux args 
vector, or even (often) a system call.

To give another example, Linux provides a very cheap way for a userspace 
process to enquire which core it’s running on.  Some more recent 
high-performance mallocs use this to have a second-layer per-core cache after 
the per-thread cache for free blocks.  Unlike the per-thread cache, the 
per-core cache does need a lock, but it’s very unlikely to be contended (it 
will only be contended if either a thread is migrated in between checking and 
locking, so acquires the wrong CPU’s lock, or if a thread is preempted in the 
middle of middle of the very brief fill operation).  The author of the 
SuperMalloc paper tried doing this with CPUID and found that it was slower by a 
sufficient margin to almost entirely offset the benefits of the extra layer of 
caching.  

Just because userspace can get at the information directly from the hardware 
doesn’t mean that this is the most efficient or best way for userspace to get 
at it.

Oh, and some of these things are useful in portable code, so having to write 
some assembly for every target to get information that the kernel already knows 
is wasteful.

David

___
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: USB stack

[Gary Jennejohn]

On Wed, 3 Jan 2018 20:29:08 +0100
"O'Connor, Daniel"  wrote:

> > On 3 Jan 2018, at 11:56, blubee blubeeme  wrote:
> > On Wed, Jan 3, 2018 at 6:41 PM, O'Connor, Daniel  wrote:
> > 
> >   
> > > On 3 Jan 2018, at 11:31, blubee blubeeme  wrote:
> > > Does FreeBSD current USB stack support usb >= 2.0 devices?  
> > 
> > Absolutely.
> >   
> > > Testing out the USB devices support I get about 7.2-7.8 megabytes per
> > > second which seems odd.  
> > 
> > What sort of test? What sort of device? What sort of port?
> > 
> > What is the output of dmesg and usbconfig?
> > 
> > I transferred about 30GB of audio from laptop to Samsung usb class 10 usb 
> > device connected to LG v30.
> > 
> > current usbconfig shows this:
> > ugen0.1: <0x8086 XHCI root HUB> at usbus0, cfg=0 md=HOST spd=SUPER 
> > (5.0Gbps) pwr=SAVE (0mA)
> > ugen0.3:  at usbus0, cfg=0 md=HOST 
> > spd=HIGH (480Mbps) pwr=ON (500mA)
> > ugen0.2:  at usbus0, cfg=0 md=HOST spd=FULL 
> > (12Mbps) pwr=ON (100mA)  
> 
> Ugh, your mail client has mangled things, oh well.
> 
> You missed posting the output of dmesg..
> 
> What is an "LG v30"?
> 

It's a smartphone from LG and only supports USB2 speed.  The reported
transfer rate is no big surprise.

-- 
Gary Jennejohn
___
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: r327359: cylinder checksum failed: cg0, cgp: 0x4515d2a3 != bp: 0xd9fba319 Dec 30 23:29:24 <0.2>

[Michael Tuexen]

> On 31. Dec 2017, at 02:45, Warner Losh  wrote:
> 
> On Sat, Dec 30, 2017 at 4:41 PM, O. Hartmann  wrote:
> 
>> On most recent CURRENT I face the error shwon below on /tmp filesystem
>> (UFS2) residing
>> on a Samsung 850 Pro SSD:
>> 
>> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3 !=
>> bp: 0xd9fba319
>> handle_workitem_freefile: got error 5 while accessing filesystem
>> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3
>> != bp: 0xd9fba319
>> handle_workitem_freefile: got error 5 while accessing filesystem
>> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3
>> != bp: 0xd9fba319
>> handle_workitem_freefile: got error 5 while accessing filesystem
>> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3
>> != bp: 0xd9fba319
>> handle_workitem_freefile: got error 5 while accessing filesystem
>> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3
>> != bp: 0xd9fba319
>> handle_workitem_freefile: got error 5 while accessing filesystem
>> 
>> I've already formatted the /tmp filesystem, but obviously without any
>> success.
>> 
>> Since I face such strange errors also on NanoBSD images dd'ed to SD cards,
>> I guess there
>> is something fishy ...
> 
> 
> It indicates a problem. We've seen these 'corruptions' on data in motion at
> work, but I hacked fsck to report checksum mismatches (it silently corrects
> them today) and we've not seen any mismatch when we unmount and fsck the
> filesystem.
Not sure this helps: But we have seen this also after system panics
when having soft update journaling enabled. Having soft update journaling
disabled, we do not observed this after several panics.
Just to be clear: The panics are not related to this issue,
but to other network development we do.

You can check using tunefs -p devname if soft update journaling is enabled or
not.

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

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