Second Call for 2017Q4 quarterly status reports

[Benjamin Kaduk]

Happy new year, and I hope that meltdown and spectre
are not taking too much of everyone's time.  That said, the
submission deadline is still January 14th, so please do send in your
status report entries to us!

Thanks,

Ben

On Mon, Dec 25, 2017 at 06:27:16PM -0600, Benjamin Kaduk wrote:
> Dear FreeBSD Community,
> 
> The deadline for the next FreeBSD Quarterly Status update is January 14,
> 2018, for work done in October through December.
> 
> Status report submissions do not need to be very long.  They may be
> about anything happening in the FreeBSD project and community, and
> provide a great way to inform FreeBSD users and developers about
> work that is underway and completed.  Submission of reports is not
> restricted to committers; anyone doing anything interesting and
> FreeBSD related can -- and should -- write one!
> 
> The preferred and easiest submission method is to use the XML
> generator [1] with the results emailed to the status report team at
> mont...@freebsd.org .  (Do be sure, though, to save the form output
> and not the form itself!  In particular, the Google Chrome "save as"
> function does not save the generated output for some reason.)  There
> is also an XML template [2] that can be filled out manually and
> attached if preferred.  For the expected content and style, please
> study our guidelines on how to write a good status report [3].  You
> can also review previous issues [4][5] for ideas on the style and
> format.
> 
> We look forward to seeing your 2017Q4 reports!
> 
> Thanks,
> 
> Ben (on behalf of monthly@)
> 
> [1] https://www.FreeBSD.org/cgi/monthly.cgi
> [2] https://www.FreeBSD.org/news/status/report-sample.xml
> [3] https://www.FreeBSD.org/news/status/howto.html
> [4] https://www.FreeBSD.org/news/status/report-2017-07-2017-09.html
> [5] https://www.FreeBSD.org/news/status/report-2017-04-2017-06.html
> 
> 




signature.asc
Description: PGP signature

Re: Intel CPU design flaw - FreeBSD affected?

[blubee blubeeme]

On Thu, Jan 4, 2018 at 8: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
>
>
> 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-unsubscribe@
> freebsd.org"
> >
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
This is insane...

And to think a few months ago people were complaining that Ryzen processors
and specifically Threadripper might be insecure in data centers, ha.

This is a massive 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?

[Mark Heily]

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"

Re: Programmatically cache line

[Nathan Whitehorn]

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.

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

Re: Programmatically cache line

[Ed Schouten]

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.

-- 
Ed Schouten 
Nuxi, 's-Hertogenbosch, the Netherlands
___
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 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"?

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

[O'Connor, Daniel]

> 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?

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

[blubee blubeeme]

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

USB stack

[blubee blubeeme]

Does FreeBSD current USB stack support usb >= 2.0 devices?

Testing out the USB devices support I get about 7.2-7.8 megabytes per
second which seems odd.
___
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

[Maurizio Vairani]

2018-01-02 2:27 GMT+01:00 blubee blubeeme :

> On Tue, Jan 2, 2018 at 12:26 AM, Ian Lepore  wrote:
>
> > On Mon, 2018-01-01 at 12:36 +0200, Konstantin Belousov wrote:
> > > On Mon, Jan 01, 2018 at 06:52:37AM +, David Chisnall wrote:
> > > >
> > > > On 1 Jan 2018, at 05:09, Adrian Chadd 
> wrote:
> > > > >
> > > > >
> > > > > On 30 December 2017 at 00:28, Konstantin Belousov  wrote:
> > > > > >
> > > > > > On Sat, Dec 30, 2017 at 07:50:19AM +, blubee blubeeme wrote:
> > > > > > >
> > > > > > > Is there some way to programmatically get the CPU cache line
> > sizes on
> > > > > > > FreeBSD?
> > > > > > There are, all of them are MD.
> > > > > >
> > > > > > 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.
> > >
> > > >
> > > >
> > > > It would be nice to expose this kind of information via VDSO or
> > similar.  There are a lot of similar bits of info that people want to use
> > for ifunc and, SVE is going to have a bunch of similar requirements.
> > > >
> > > Is VDSO a new trendy word ?
> > >
> > > ifunc resolvers in usermode on FreeBSD/x86 get four arguments which
> > > are essentially cpu_features / cpu_features2 / cpu_stdext_features /
> > > cpu_stdext_features2.  I suspect that only FreeBSD/x86 arches have the
> > > ifunc support, in rtld and coming shortly in kernel.
> > >
> > > Recently HW_CAP/HW_CAP2 were added to the ELF auxv, and elf_aux_info(3)
> > > interface exported from libc.
> > >
> > > ARM* did not implemented yet the ifunc stubs in rtld. I believe this is
> > > considered a low priority because there is no ready to use toolchain
> > > which allow to utilize ifuncs on FreeBSD, except if you use recent bfd
> > > ld externally.
> >
> > Linux exports this info using getauxval().  I think we should support
> > getauxval() and as many of the AT_* values that linux defines as makes
> > sense for us to do.
> >
> > I think it was a mistake to give our version of the function a
> > different name and different semantics, but this is something that
> > affects mainly ports, and I don't yet have enough info to make the case
> > that being linux-compatible will ease porting rather than complicate it
> > (in some cases, patches will be needed either way).
> >
> > -- Ian
> >
> FreeBSD implements hardware specific atomic instructions [man atomic] or
> look at: #include 
>
> but implementing something that returns size of cache lines is somehow out
> of the question?
>
> If you're working with atomic data structures and want to ensure there's no
> false sharing the
> simplest method I know is to put some padding that's sizeof(cache_line) -
> sizeof(data_members)
> so that you can try to get them to live on different cache line.
>
> Do we have to go in and write inline assembly to grab the size of the cache
> line or wouldn't it
> be simpler to have atomic.h return this info?
>
> You can use CPUCTL(4).
___
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"