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

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

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

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

Re: Programmatically cache line

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

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

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.

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

> 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

Re: Programmatically cache line

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

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

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

To which list should I submit a patch?

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

Re: To which list should I submit a patch?

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

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

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

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

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]: >

Re: Intel CPU design flaw - FreeBSD affected? Information from Arm

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

Re: more fallout from removal of lint

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

Re: more fallout from removal of lint

[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

Re: Intel CPU design flaw - FreeBSD affected?

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

Re: Programmatically cache line

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,

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

> 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

Re: USB stack

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

Re: Intel CPU design flaw - FreeBSD affected?

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

Re: Programmatically cache line

> 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

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

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

Re: USB stack

> 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

Re: more fallout from removal of lint

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

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

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

Re: Intel CPU design flaw - FreeBSD affected?

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

Re: more fallout from removal of lint

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

Re: Intel CPU design flaw - FreeBSD affected?

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

Re: Intel CPU design flaw - FreeBSD affected?

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

RFC: mallocarray()

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

Re: Intel CPU design flaw - FreeBSD affected?

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.