Re: iscsi?
On Feb 28, 2013, at 0:09, Brian Buhrow wrote: > Hello. I'm pretty sure iscsi-initiator support is only provided for > NetBSD through the netbsd-iscsi-initiator package in the net category of > the pkgsrc tree. Because it relies on the fuse interface to get its work > done, I am also pretty sure the earliest version of NetBSD on which it will > work is NetBSD-5. It's included in base as of NetBSD 6.0: http://www.daemon-systems.org/man/iscsi-initiator.8.html -- Name: Dave Huang | Mammal, mammal / their names are called / INet: k...@azeotrope.org | they raise a paw / the bat, the cat / FurryMUCK: Dahan | dolphin and dog / koala bear and hog -- TMBG Dahan: Hani G Y+C 37 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++
Re: Changes to make /dev/*random better sooner
On Apr 8, 2014, at 21:33, Thor Lancelot Simon wrote:
> On Wed, Apr 09, 2014 at 02:43:23AM +0100, Mindaugas Rasiukevicius wrote:
>> Few fragments which caught my eye while skimming through the diff..
>>
>>> #if defined(__HAVE_CPU_COUNTER)
>>> - if (cpu_hascounter())
>>> - return (cpu_counter32());
>>> + if (cpu_hascounter() && sizeof(cpu_counter() == sizeof(uint64_t))) {
>>> + return (cpu_counter());
>>> + }
>>> #endif
>>
>> ??
>
> We provide no MI API for obtaining a counter value of any known size except
> 32 bits, unfortunately. The instrumentation I added while developing these
> changes revealed that the delta entropy estimator was terribly broken due
> to wraparound; changing it to 64 bits is the fix.
I don't have any knowledge or opinion about that, but maybe the "??"
has to do with the sizeof? I think the parens are wrong; they're around
the entire equality comparison.
--
Name: Dave Huang | Mammal, mammal / their names are called /
INet: k...@azeotrope.org | they raise a paw / the bat, the cat /
FurryMUCK: Dahan | dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 38 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++
Re: meltdown
On Jan 4, 2018, at 15:22, Phil Nelson wrote: > How about turning on the workaround for any process that ignores > or catches SEGV.Any process that is terminated by a SEGV should > be safe, shouldn't it? Isn't there a suggested mitigation? Seems to me NetBSD should implement it as suggested, rather than coming up with its own special criteria for when to enable the workaround. -- Name: Dave Huang | Mammal, mammal / their names are called / INet: k...@azeotrope.org | they raise a paw / the bat, the cat / Telegram: @DahanC| dolphin and dog / koala bear and hog -- TMBG Dahan: Hani G Y+C 42 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++
Re: amd64: svs
On 1/6/2018 19:58, Mouse wrote: Why? Is there any reason to not deploy known effective countermeasures while waiting for a real fix? Indeed, do we have any reason to think a real fix will be forthcoming from Intel? In view of their attempts to downplay their bugs, I have negative confidence they will actually _fix_ them...if indeed they are fixable on current hardware. (It's not publicly known, as far as I know, to what extent the bugs are fixable in microcode; in some respects they may be baked into the silicon.) My understanding is that it's not something that can be fixed in microcode, but that Intel has already released a microcode update that provides hardware support for mitigating the problems. I haven't been able to find actual documentation about the changes, but apparently Intel calls them "Indirect Branch Restricted Speculation" and "Indirect Branch Prediction Barriers". On CPUs with the new microcode, there are now new SPEC_CTRL and PRED_CMD model-specific registers that allow you to enable/disable the behavior. It looks like two of the Dell machines I use have BIOS updates that include the new microcode, but I don't know when it'll be available for the other machines I use. The standalone microcode update at https://downloadcenter.intel.com/download/27337/Linux-Processor-Microcode-Data-File is dated 20171117, and from what I've read, does not contain the latest changes. -- Name: Dave Huang | Mammal, mammal / their names are called / INet: k...@azeotrope.org | they raise a paw / the bat, the cat / Telegram: @dahanc| dolphin and dog / koala bear and hog -- TMBG Dahan: Hani G Y+C 42 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++
Re: amd64: svs
On Jan 13, 2018, at 22:20, Emmanuel Dreyfus wrote: > > John Klos wrote: > >> FWIW, Intel updated their microcode on 8-Jan-2018: >> >> https://downloadcenter.intel.com/download/27431/ >> >> I can't find any documentation which shows what exactly is fixed for each >> family of processors. > > It does not seems to fix much. > > I tried the tests from git repository > http://github.com/IAIK/meltdown.git > > This is Linux-centric, but at least, the "secret" case seems to apply on > NetBSD. It reports vulnerability before (cpu0: microcode version 0x58, > platform ID 1) and after (cpu0: microcode version 0x80, platform ID 1) > microcode upgrade. > > And I do not have a spectre test case. Anyone has that? My understanding is that the microcode update doesn't actually *fix* anything by itself. What it does is enable an OS to more easily fix things. The kernel would need to check for the new SPEC_CTRL CPUID bit, and if present, twiddle with the new speculation control-related MSRs at the appropriate times. -- Name: Dave Huang | Mammal, mammal / their names are called / INet: k...@azeotrope.org | they raise a paw / the bat, the cat / Telegram: @DahanC| dolphin and dog / koala bear and hog -- TMBG Dahan: Hani G Y+C 42 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++
Re: Proposal, again: Disable autoload of compat_xyz modules
On 9/26/2019 17:02, Maxime Villard wrote: So here's what's going to happen. I will drop this thread, because in the end I don't care a lot. I will stop doing the work I've been doing, have withdrawn from secteam already, and won't be taking care of any of that from now on. I'm done, this is over. Bye, Felicia!
