@bcr Do you have any objections on behalf of core@? As I am removing some stale members I was also looking forward for core's approval.

patch ready and tested at PR 265632

In D30333#825537, @arrowd wrote:

In D30333#825523, @eduardo wrote:

How can I find device id for this legion like

#define	LENOVO_L5AMD_SUBVENDOR	HDA_MODEL_CONSTRUCT(LENOVO, 0x381b)

Thanks

In my case I ran pciconf -lv and found a device with multimedia class:

hdac0@pci0:0:31:3:      class=0x040380 rev=0x31 hdr=0x00 vendor=0x8086 device=0xa171 subvendor=0x1043 subdevice=0x15e0
    vendor     = 'Intel Corporation'
    device     = 'CM238 HD Audio Controller'
    class      = multimedia
    subclass   = HDA

The subdevice=0x15e0 part turned out to be the correct value for that switch.

In D30333#825523, @eduardo wrote:

How can I find device id for this legion like

#define	LENOVO_L5AMD_SUBVENDOR	HDA_MODEL_CONSTRUCT(LENOVO, 0x381b)

Thanks

it works same way for a legion 5 intel version:

I'm trying to get sound from my speakers on a Lenovo 5 (intel i7), headphones works ok.

FWIW, splice: https://reviews.freebsd.org/D30597

Done: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256169

we have so many such unfinished things

In D30378#684094, @trasz wrote:

FWIW, splice(2) can be a wrapper around copy_file_range(2). We should also have a fallback from sendfile(2) to splice(2), for when it fails with ENOTSOCK. This is one of the things that break Mono

Why do we need it? All the BSD's seem to exist without splice() just fine?

The most pressing issue is the incomplete pthread support notably with FUTEX_LOCK_PI and FUTEX_UNLOCK_PI and friends.

https://wiki.freebsd.org/Linuxulator#Roadmap, pi is not the key, we have so many important holes

It's literally the second item on that list, for example pulseaudio hard crashes because it's not there. I have started but it's pretty hard, I wonder if anyone can help?

FWIW, splice(2) can be a wrapper around copy_file_range(2). We should also have a fallback from sendfile(2) to splice(2), for when it fails with ENOTSOCK. This is one of the things that break Mono.

In D30378#684088, @dchagin wrote:

we have so many such unfinished things, like arm linuxulator, splice sys call....

Yes, about splice, I was thinking we could just use a regular copy and be done with it. It wouldn't be that hard to implement, I can possibly look at it.

some time ago I wrote splice emulation via dofileread/dofilewrite ) but I abandoned it because I think we need a native splice() and tee() implementation. feel free to as arch@ about it:)

In D30378#684088, @dchagin wrote:

we have so many such unfinished things, like arm linuxulator, splice sys call....

Yes, about splice, I was thinking we could just use a regular copy and be done with it. It wouldn't be that hard to implement, I can possibly look at it.

some time ago I wrote splice emulation via dofileread/dofilewrite ) but I abandoned it because I think we need a native splice() and tee() implementation. feel free to as arch@ about it:)

The most pressing issue is the incomplete pthread support notably with FUTEX_LOCK_PI and FUTEX_UNLOCK_PI and friends.

https://wiki.freebsd.org/Linuxulator#Roadmap, pi is not the key, we have so many important holes

I don't think they are even usable, since the core file is in FreeBSD format that linux gdb can't parse, and confuse the freebsd gdb because it's a linux process/elf.

we have so many such unfinished things, like arm linuxulator, splice sys call....

Yes, about splice, I was thinking we could just use a regular copy and be done with it. It wouldn't be that hard to implement, I can possibly look at it.

In D30378#684071, @dchagin wrote:

In D30378#684069, @pitwuu_gmail.com wrote:

In D30378#684068, @emaste wrote:

Encountered in the crash handler of 'kodi'. Kodi still crashes, but at least the crash handler doesn't seem to crash anymore.

IMO this sort of thing is sufficient reason to have this linprocfs entry. What do you think about extending it slightly, at least translating FreeBSD's default %N.core to the Linux equivalent (%e.core I guess?)

we have so many such unfinished things, like arm linuxulator, splice sys call....

In D30333#683079, @arrowd wrote:

lots of output

In D30378#684069, @pitwuu_gmail.com wrote:

In D30378#684068, @emaste wrote:

Encountered in the crash handler of 'kodi'. Kodi still crashes, but at least the crash handler doesn't seem to crash anymore.

IMO this sort of thing is sufficient reason to have this linprocfs entry. What do you think about extending it slightly, at least translating FreeBSD's default %N.core to the Linux equivalent (%e.core I guess?)

In D30378#684068, @emaste wrote:

Encountered in the crash handler of 'kodi'. Kodi still crashes, but at least the crash handler doesn't seem to crash anymore.

IMO this sort of thing is sufficient reason to have this linprocfs entry. What do you think about extending it slightly, at least translating FreeBSD's default %N.core to the Linux equivalent (%e.core I guess?)

Encountered in the crash handler of 'kodi'. Kodi still crashes, but at least the crash handler doesn't seem to crash anymore.

In D30378#684066, @emaste wrote:

Is there a way to config git to do that by default? It's annoying to do every time.

I'm not sure, although I also suspect you don't want it when generating a patch for your own review, not for upload to Phabricator. There is a tool in the tree, tools/tools/git/git-arc, which can take care of submitting phab reviews for you.

Is there a way to config git to do that by default? It's annoying to do every time.

In D30378#683157, @emaste wrote:

For future uploads please include full context by using e.g. git show -U99999 <hash> - see https://wiki.freebsd.org/Phabricator for details

hi, what is the purpose for this? it will be used read only. so what is the program depend on it?

For future uploads please include full context by using e.g. git show -U99999 <hash> - see https://wiki.freebsd.org/Phabricator for details

Give us the output of 'pciconf -lv' please.

For my ASUS ROG GL553VE the following device hint fixed headset detection:

Do I have to do some specific action?

In D30333#681628, @emaste wrote:

Please confirm Philippe Michaud-Boudreault <pitwuu@gmail.com> as the correct author info for Git.

Please confirm Philippe Michaud-Boudreault <pitwuu@gmail.com> as the correct author info for Git.

Sorry for the delay (des@ have pinged me today). Consider this as a so@ approval as we haven't heard other objections so far.

delphij: is that OK for you?

By the second thought, no problem:) Since you mention that per-CPU locking is not your goal, in worst case the same harmless multiple stiring can happens since numruns belongs to the same arc4 data set to which stiring applied.

Unfortunately this is a problem that is already present in the current version.

In current version it is not a problem (see my previous comment about multiple stiring above), but in case each arc4 instance can run on different arc4 data set, it can be a problem.

Updated diff using full context, changed code according to delphij's comment

unlocked read of arc4->numruns

Will lead to several arc4 stiring in worst case (which IMHO is non-practical case). Any number of stiring does not harm arc4, at least one stiring should be enough. But all this for one CPU case, I don't know about per-CPU locking in details so can't answer the next note.

I have some comments inline -- please fix the style change.

Yes.

Is that OK for you?

Updated diff according to ache's remarks

This is nearly what I proposed before, but why would you reseed all the instances in case the user calls arc4rand with reseed = 1?

Because from current API point of view there is no separate CPU argument, so the call with reseed == 1 can come from any random CPU.
In general any random CPU may be not equal to unknown CPU for which this operation was made.

if (atomic_cmpset_int(&arc4rand_iniseed_state, ARC4_ENTR_HAVE, ARC4_ENTR_SEED) ||
    reseed) {
        ARC4_FOREACH(arc4)
                arc4_randomstir(arc4);
}
...
if (arc4->numruns > ARC4_RESEED_BYTES || 
    tv.tv_sec > arc4->t_reseed)
        arc4_randomstir(arc4);

This is nearly what I proposed before, but why would you reseed all the instances in case the user calls arc4rand with reseed = 1?

Not sure this is a big security concern or not?

Maybe I am wrong, but I don't see big deal here - the moment of good randomness available is unpredictable in the time intervals we consider, and if some threads got it a bit later (on the next call), I don't see the problem.

In D8130#169388, @ache wrote:

There can be small window when arc4rand_iniseed_state is already set to SEED, but arc4_randomstir() is not called yet. And right in this time another thread calls the code. Well, we miss only single reinitialization per-CPU (more are time-consuming and can't fit between the check and immediate function call), on the next call they will be already reinitialized. Dou mean another scenario?

Yes that is what I meant. Not sure this is a big security concern or not?

In D8130#169387, @ache wrote:

The problem is that another thread may call the arc4rand() function and get some unsafe random bytes before the stir actually occurs and after the state was set to SEED.

Please show how it can happen in steps by steps. In old code if the state was SEED, it surely reinitialized, and reinitialization itself keeps a lock, so RNG can't move further and wait for reinitialization (from any thread).

There can be small window when arc4rand_iniseed_state is already set to SEED, but arc4_randomstir() is not called yet. And right in this time another thread calls the code. Well, we miss only single reinitialization per-CPU (more are time-consuming and can't fit between the check and immediate function call), on the next call they will be already reinitialized. Dou mean another scenario?
We can move both check and function call under lock, but it will slow things down, i.e. the thing you fight against.

The problem is that another thread may call the arc4rand() function and get some unsafe random bytes before the stir actually occurs and after the state was set to SEED.

Please show how it can happen in steps by steps. In old code if the state was SEED, it surely reinitialized, and reinitialization itself keeps a lock, so RNG can't move further and wait for reinitialization (from any thread).

Here is what I propose:

In your code 'reseed' variable should be move to the same 'if' as 'arc4rand_iniseed_state' placed, we never know what we cpu we reseed otherwise.
The next thing I don't like much is possible double initialization, if this condition additionaly meet in the same time 'if ((arc4->numruns > ARC4_RESEED_BYTES) || (tv.tv_sec > arc4->t_reseed))
All you need is simple local 'reseedall' variable and set it where ARC4_FOREACH(arc4) is.

In D8130#169376, @ache wrote:

I meant the arc4rand_iniseed_state variable.

I too. Without locking or atomic either yet one additional seeding can happens or no seeding can happens at all (CPU writing to another half of word, which is already checked).

I do agree with that, but on the very first call of arc4rand(), we can make sure readomstir() is called,

Not all stiring are equal) Non random stiring is done to just not block arc4 on early boot phase.
When good randomnes becomes available (which arc4rand_iniseed_state indicates) it must be reinitialized immediately on the next call.

I meant the arc4rand_iniseed_state variable.

I too. Without locking or atomic either yet one additional seeding can happens or no seeding can happens at all (CPU writing to another half of word, which is already checked).

I do agree with that, but on the very first call of arc4rand(), we can make sure readomstir() is called,

Not all stiring are equal) Non random stiring is done to just not block arc4 on early boot phase.
When good randomnes becomes available (which arc4rand_iniseed_state indicates) it must be reinitialized immediately on the next call.

In D8130#169374, @ache wrote:

But I am not sure to see the actual benefit of this atomic?

It allows to not play with locking.

I meant the arc4rand_iniseed_state variable.

But I am not sure to see the actual benefit of this atomic?

It allows to not play with locking.

I guess the read_random() call is blocking until the underlying entropy processor becomes secure?

Yes. Then it allows arc4 reseed. There is no point to reseed it before it happens with non random data.

That's a good point indeed.

reseed arg without specifying particular CPU means nothing but stir all CPUs too. And specifying that CPU is impossible on API level - nobody know from which CPU this code will be called.

The problem is that arc4rand_iniseed_state which is reset on the first use with atomic currently asssume that all RNGs are stired, but really only first one.

Do you have other remarks on this patch?

In D8130#168807, @delphij wrote:

Thanks for working on this, but I have some different ideas which I don't really have the time to sit down and implement at this time that I feel like sharing and may be useful:

I think we could take a different approach: now that we have the pseudo-random state per-CPU, perhaps we can make them CPU-bound and completely eliminate the locks and use critical sections instead?

Thanks for working on this, but I have some different ideas which I don't really have the time to sit down and implement at this time that I feel like sharing and may be useful:

Changed malloc test to KASSERT

In D8130#168692, @emeric.poupon_stormshield.eu wrote:

In D8130#168678, @ache wrote:

Sorry, my prev. comment was sent non-edited. Please forget it if you got it through the mail and re-read here instead.

No problem!
Since the call is very unlikely to fail, what about a KASSERT on failure then? That seems to be an acceptable compromise.

In D8130#168678, @ache wrote:

Sorry, my prev. comment was sent non-edited. Please forget it if you got it through the mail and re-read here instead.

Sorry, my prev. comment was sent non-edited. Please forget it if you got it through the mail and re-read here instead.

Add SO

In D8130#168672, @emeric.poupon_stormshield.eu wrote:

In D8130#168667, @ache wrote:

It will be better to use non-failing malloc flag. arc4_init() can't fail.

You mean a M_WAITOK flag? I was wondering: are you sure it is really safe to sleep in this context?