Re: Tuning libcrypt with Modular Crypt Format
A.J. Kehoe IV (Nanoman) wrote this message on Mon, Mar 10, 2014 at 18:12 -0400: Derek (freebsd lists) wrote: [...] On 03/07/2014 07:36 PM, Xin Li wrote: On 03/07/14 14:50, A.J. Kehoe IV (Nanoman) wrote: Xin Li wrote: On 2014-03-07 11:13, A.J. Kehoe IV (Nanoman) wrote: Allan Jude wrote: [...] Honestly, my use case is just silently upgrading the strength of the hashing algorithm (when combined with my other feature request). Updating my bcrypt hashes from $2a$04$ to $2b$12$ or something. Same applies for the default sha512, maybe I want to update to rounds=15000 Like this? http://www.freebsd.org/cgi/query-pr.cgi?pr=182518 Request for comments: http://docs.freebsd.org/cgi/mid.cgi?20140106205156.GD4903 [...] My reasons for this were first to see if there was any interest from a committer to take this further. Much more likely to have a 15 or so line patch looked at, than one that touches stuff all over the place - I think. We are now at least having a conversation about it. It seemed to be a lot of work to specify rounds via login_setcryptfmt, with a bunch of changes also required in libcrypt. I don't have the resources to test for regressions in libcrypt, beyond the scope of whether login.conf works as expected (specifically, the ports tree, yp, ldap, or any other areas that I don't know about). If other developers were willing to work together on the api/abi changes, I would feel a lot better about spending my time there and doing it right. Without support from other, more knowledgeable people (as far as what will break if we do XYZ), who will eventually merge productive changes, I would be wasting my time. I don't want to be the libcrypt api changing pixie, scattering patches into /dev/null. :) So far, I've seen five people say that they want this functionality: 2005-01-08: Steven Alexander Jr. 2012-12-05: Derek 2013-07-07: me 2013-10-29: jmg@ 2014-02-27: Allan Jude There will surely be more, and I think it's fair to say that none of us are sufficiently familiar with the many things that depend on libcrypt and libutil. To avoid breaking something, we need feedback from the people who would ultimately be committing these changes. Is this the correct mailing list to discuss this proposed feature? I'm willing to commit these changes once the proper parties have signed off on them... We should probably include secteam@ too... I'm glad we have as much interest as we do... :) My suggestion is that we either have: a) passwd_format and passwd_round (so that they don't conflict), or I recommend against this. By example, based on current scrypt modular crypt RFCs, there are multiple tunable parameters. It's conceivable that other future algorithms will have different functional and named parameters. Additionally, I think having all the parsing code for this scattered about actually makes things less clear. For example, $2a$08$ means a lot more to people (across different *nix backgrounds) than blf, is concise, and is/already should be well documented in crypt(3). Likewise with sha512. Looking at login.conf, you can't tell exactly what it means. Modular crypt is something that developers are working to stay compatible with (e.g. $5$, $6$, $2y$, etc), is understood outside of the context of FreeBSD system administration, and would be understood by people who are knowledgeable enough to seek to change this aspect of their system. This is exactly what I meant. I completely agree. b) extend passwd_format in a compatible manner to allow specifying a round, or, c) make passwd_format and passwd_modular conflict so we don't silently accept it and instead bail out when doing pwd_mkdb. As jmg suggested, by supplying the modular format for passwd_format, we eliminate this conflict, and make it obvious. I definitely support this notion. Option C gets my vote too. Modular crypt is pretty standard across all implementations, whereas options A and B would require additional proprietary parsing, which I feel would be an unnecessarily more complex change. That means touching login_setcryptfmt and friends, I think. What do you think of the idea of putting this into libcrypt instead of pam_unix.c, and then patching pam_unix.c and pw_user.c to reference libcrypt? Which part of the idea? I think it's a bad idea to make libcrypt to depend on libutil (for login_cap(3)) but we should probably provide new wrappers in login_cap(3) to do the common things when requested for various password manipulating tools to reduce duplicated code. Specifically: The makesalt aspect can/should be put into libcrypt, refined appropriately, and exposed publicly. It is a terrible little piece of code as it is now, twice (or more!), and it could be cleaned up considerably. This could be a nice little api. You know, I was very confused how it even worked, how providing a random
processes stuck in vmo_de state
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, I have recently upgraded my home storage box (Avoton based board running FreeBSD/amd64) from 10.0-RELEASE (patched with some ZFS changes) to -CURRENT. It looks like the system would easily hang when I start 'buildworld', when this happens, I saw sh process stuck in 'vmo_de' state and procstat -kk would give me EBUSY: $ procstat -kk 1752 PIDTID COMM TDNAME KSTACK procstat: sysctl: kern.proc.kstack: 1752: Device busy To rule out issue introduced by my local changes, I reverted them all and used an unpatched 'VT' kernel (with WITNESS, etc. enabled). In loader.conf I have: zfs_load=YES aesni_load=YES hint.apic.0.clock=0 hint.atrtc.0.clock=0 In rc.conf I have: powerd_enable=YES economy_cx_lowest=LOW performance_cx_lowest=LOW The zpool I'm using is configured to use SHA256 as checksum. One zpool is created over 4 GELI provider and decrypted on boot but I don't think that matters. Any hints? The system have flaky IPMI access so I can't always debug from remote but would happy to provide more data if helpful. Cheers, -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJTHr/cAAoJEJW2GBstM+ns6akP/1nsP8EH1zQ3v04fP4ZrmHp2 /7RgU3LH5/ydRuoiVvMnnJsK0XjZxi/Uu8kad1P/xi4FpqDmMTsQ5/8u/HKoGA9Z Jik+LS79R7AApU4v64pWpPbUo7a9cs+JWH3gNWPCfqDHpg6FoP6B7sxrGdX4EY+n UftSstk/UVSeoGaoC1sEgzsR3/ORAN+pQ7YbTlPJ7/RK8OIcrq8GTXTJpXaT0EoP w0PQZtvPy5lWkB+KwAjrfF3QEr/G6pubLKbeq46eSwY0eDruL79zd7zozHcR5F9e 03tu17VM1QW41Y8zQT16cX8YEWI//5rk1wOQLZXT++jWyty9T9Ekt+d+H0mCPtjm nIwLlyVQrfXPZnvFi3oZcOxgSdT3x3O9cUDQVebC4yIN4NPUWdyHmn6C57xwjW/h efPoujEAkjPfD3iykWbLBXHGKyINi3KxU8ht1vndO4LdYKj+Dvtnz/IKs6VxnyT0 ld19nMkXZOjZc8Iftkx9/aLdlA1/BtkwIndod1J18kmMf7fWW9k7Mt8DyaGD8XUA 5QRIz3aeomF/+awTvVWTa07Rib5d4s6qv63ecGPEhNLjR6QA5t19b0W/8Ip2eTQD B39ROUtBbSE2wzcpYwNdkHQEUiQSOzQithqRPvzXJZrUdEk+I3/4D1870r5BFCIJ wL8/P0dmN1Y02vYFdJwy =xBqp -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: signal 8 (floating point exception) upon resume
On Mon, 10 Mar 2014, John Baldwin wrote:
On Tuesday, March 04, 2014 4:50:01 pm Bruce Evans wrote:
On Tue, 4 Mar 2014, John Baldwin wrote:
% Index: i386/i386/swtch.s
% ===
% --- i386/i386/swtch.s (revision 262711)
% +++ i386/i386/swtch.s (working copy)
[...savectx()]
This function is mostly bogus (see old mails).
I was going off of the commit logs for amd64 that removed this code as savectx()
is not used for fork(), only for IPI_STOP and suspend/resume.
Without fxsave, npxsuspend() cannot be atomic without locking, since
fnsave destroys the state in the FPU and you either need a lock to
reload the old state atomically enough, or a lock to modify FPCURTHREAD
atomically enough.
save_ctx() is now only called from IPI handlers or when doing suspend in
which case we shouldn't have to worry about being preempted.
I don't understand the suspend part. Is sufficient locking held througout
suspend/resume to prevent states changing after they have been saved here?
% @@ -520,7 +490,16 @@
% movl%eax,%dr7
%
% #ifdef DEV_NPX
% - /* XXX FIX ME */
% + /* Restore FPU state */
Is the problem just this missing functionality?
Possibly.
I now think it was just the clobbering of %cr0 so i386 never had the
problem.
I think on amd64 there was also the desire to have the pcb
state be meaningful in dumps (since we IPI_STOP before a dump). OTOH,
It should also be meaningful in debuggers. Hopefully stop IPIs put
it there form all stopped CPUs. I think it remains in the FPU for
the running CPU.
the current approach used by amd64 (and this patch for i386) is to not
dirty fpcurthread's state during save_ctx(), but to instead leave
fpcurthread alone and explicitly save whatever state the FPU is in
in the PCB used for IPI_STOP or suspend.
Hmm, if kernel debuggers actually supported displaying the FPU state, then
they would prefer to find it in the PCB only (after debugger entry puts
it there), but this doesn't work in places like the dna trap handler.
Similarly for IPIs and suspend. The dna trap handler would be broken
unless any saving in the PCB is undone when normal operation is resumed,
and it seems more difficult to undo it than to save specially so as not
to have anything to undo. It is OK to save in the usual place in the PCB
so that debuggers can find it more easily (since that place is not used
in normal operation), but not to change the state in the CPU+FPU across
the operation. Harmful state changes in the CPU+FPU include toggling
CR0_TS and implicit fninit. For suspend/resume, we have no option but
to undo everything, since other things may clobber the state.
% @@ -761,7 +761,34 @@
% PCPU_SET(fpcurthread, NULL);
% }
%
% +/*
% + * Unconditionally save the current co-processor state across suspend and
% + * resume.
% + */
% void
% +npxsuspend(union safefpu *addr)
% +{
% + register_t cr0;
% +
% + if (!hw_float)
% + return;
% + cr0 = rcr(0);
% + clts();
% + fpusave(addr);
% + load_cr(0, cr0);
% +}
In the !fxsave case, this destroys the state in the npx, leaving
fpcurthread invalid. It also does the save when the state in the
npx is inactive. I think jkim intentionally this state so that
resume can load it unconditionally. It must be arranged that there
are no interactions with fpcurthread.
Given the single-threaded nature of suspend/resume and IPI_STOP /
restart_cpus(), those requirements are met, so it should be safe
to resume whatever state was in the FPU and leave fpcurthread
unchanged.
Is the whole suspend/resume really locked?
This doesn't work so well
without fxsave. When fpcurthread != NULL, reloading CR0 keeps
CR0_TS and thus ensures that inconsistent state lives for longer.
Things will only be OK if fpcurthread isn't changed until resume.
After the save_ctx() the CPU is going to either resume without
doing a resume_ctx (IPI_STOP case) leaving fpcurthread unchanged
(so save_ctx() just grabbed a snapshot of the FPU state for
debugging purposes) or the CPU is going to power off for suspend.
If it doesn't restore for IPI_STOP, then it will continue with the
state clobbered by fnsave in the !fxsr case. That is rare but can
happen. Most CPUs that have IPIs also have fxsr. But on at least
i386, there is an option to disable fxsr.
During resume it will invoke resume_ctx() which will restore the
FPU state (whatever state it was in) and fpcurthread and only
after those are true is the CPU able to run other threads which
will modify or use the FPU state.
You can probably fix this by using the old code here. The old code
doesn't need the hw_float test, since fpcurthread != NULL implies
hw_float != 0.
Actually, I don't see any need to change anything on i386 -- after
storing the state for the thread, there should be no need to store it
anywhere else across suspend/resume. We intentionally use this method
(even on amd64 IIRC), although it is
RFT vidcontrol for vt(4)
Hello hackers! Here is link to the patch[1] for vidcontrol that makes it to know if it run w/ or w/o vt(4) and if vt(4) is present, then: 1. screen map feature disabled (vt(4) use Unicode, so screen map not needed). 2. enable to load fornt from /usr/share/vt/fonts/ dir. PLease put gallant font[2] to /usr/share/vt/fonts/. Looks like it works fine, but maybe I forgot something :) So please test it in your own environment. Big thanks to Ed for preparing that font file! 1. http://people.freebsd.org/~ray/newcons/vidcontrol_for_vt_2014-03-11.patch 2. http://people.freebsd.org/~emaste/newcons/gallant.fnt Thanks! WBW -- Aleksandr Rybalko r...@ddteam.net ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ZFS secondarycache on SSD problem on r255173
On Mon, Mar 03, 2014 at 11:17:05AM +0200 I heard the voice of Andriy Gapon, and lo! it spake thus: I noticed that on some of our systems we were getting a clearly abnormal number of l2arc checksum errors accounted in l2_cksum_bad. The hardware appeared to be in good health. FWIW, I have a system here where I see similar things; after sufficient uptime it shows an impressive number and proportion of checksum errors (50% or more of the hits, eventually), since at least sometime last fall. No indication anywhere else of problems (CAM, SMART, zpool status). Haven't tried the patches. It would take most of a month of seeing nothing to have much confidence they did anything anyway; it's got 2 weeks now and only ~500 errors, so it takes a long time with this system/workload to ramp up. But it'd be a nice fix to have, so mark me up as a user-vote for landing if the code makes sense to the codesense people. -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RFT vidcontrol for vt(4)
On Tue, Mar 11, 2014 at 04:27:43PM +0200, Aleksandr Rybalko wrote: Hello hackers! Here is link to the patch[1] for vidcontrol that makes it to know if it run w/ or w/o vt(4) and if vt(4) is present, then: % man vt No manual entry for vt % man 4 vt No manual entry for vt % locate vt.4 /usr/home/kargl/freebsd/doc/ja_JP.eucJP/man/man4/pcvt.4 Any chance that a manpage will ever show up? -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Too low PTHREAD_STACK_MIN value?
Hello,
While debugging a pthread program that sets the stack size of pthreads,
I've found out that the value PTHREAD_STACK_MIN is currently set (2048
bytes) seems to be way too low. As an example, the following simple
program will segfault:
---
#include pthread.h
#include stdio.h
#include stdlib.h
#include assert.h
#define MALLOC_SIZE 1024
void *
foo(void *arg)
{
void *bar;
bar = malloc(MALLOC_SIZE);
assert(bar != NULL);
return (NULL);
}
int main(void)
{
pthread_t thread;
pthread_attr_t attr;
int rc, i;
rc = pthread_attr_init(attr);
assert(rc == 0);
rc = pthread_attr_setstacksize(attr, PTHREAD_STACK_MIN);
assert(rc == 0);
rc = pthread_create(thread, attr, foo, NULL);
assert(0 == rc);
rc = pthread_join(thread, NULL);
assert(0 == rc);
exit(EXIT_SUCCESS);
}
---
IMHO, PTHREAD_STACK_MIN should be set to a sane value, that allows the
thread to at least make use of libc functions.
Roger.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: iwn(4) in -HEAD supporting Centrino Wireless-N 135
I still don't have any ideas here. I do however want to try hacking the driver to transmit EAPOL frames at the management rate, and then ensure the management rate is non-MCS. -a On 28 February 2014 15:14, Adrian Chadd adr...@freebsd.org wrote: Hi, the interesting bits: Feb 28 22:55:22 kernel: iwn_tx_data: qid 3 idx 3 len 129 nsegs 2 rate 0002 plcp 0x420a Feb 28 22:55:22 kernel: iwn_tx_data: qid 3 idx 4 len 129 nsegs 2 rate 0002 plcp 0x420a Feb 28 22:55:22 kernel: iwn5000_tx_done: qid 3 idx 3 retries 16 nkill 0 rate 80006902 duration 2815 status 83 Feb 28 22:55:22 kernel: iwn5000_tx_done: qid 3 idx 4 retries 16 nkill 0 rate 80006902 duration 2815 status 83 Feb 28 22:55:23 kernel: iwn_tx_data: qid 3 idx 5 len 129 nsegs 2 rate 0002 plcp 0x420a Feb 28 22:55:23 kernel: iwn_tx_data: qid 3 idx 6 len 129 nsegs 2 rate 0002 plcp 0x420a Feb 28 22:55:23 kernel: iwn5000_tx_done: qid 3 idx 5 retries 16 nkill 0 rate 80006902 duration 2815 status 83 Feb 28 22:55:23 kernel: iwn5000_tx_done: qid 3 idx 6 retries 16 nkill 0 rate 80006902 duration 2815 status 83 Feb 28 22:55:24 kernel: iwn_tx_data: qid 3 idx 7 len 129 nsegs 2 rate 0002 plcp 0x420a Feb 28 22:55:24 kernel: iwn_tx_data: qid 3 idx 8 len 129 nsegs 2 rate 0002 plcp 0x420a Feb 28 22:55:24 kernel: iwn5000_tx_done: qid 3 idx 7 retries 16 nkill 0 rate 80006902 duration 2815 status 83 Feb 28 22:55:24 kernel: iwn5000_tx_done: qid 3 idx 8 retries 16 nkill 0 rate 80006902 duration 2815 status 83 .. so it's failing to transmit the management frames after association - they're being transmitted at MCS0 and the AP is just plain not ACKing them. Now, I don't know why this is. It's trying to transmit the initial frame at non-MCS rates, but I have a feeling the multi-rate retry table thing is confusing it and it's trying to send it as MCS. So maybe the AP doesn't like management frames at MCS rates. I'll have to think about this a little. -a On 28 February 2014 15:07, Tom Murphy free...@pertho.net wrote: I've attached my iwn debug messages to this email starting with the point I tried to associate to the Wifi. Thanks again for looking at this! Kind regards, Tom On Thu, Feb 27, 2014 at 12:13:51PM -0800, Adrian Chadd wrote: On 26 February 2014 23:52, Alexandr shur...@shurik.kiev.ua wrote: Tom, could you: 1. compile kernel WITH_IWNDEBUG 2. sysctl dev.iwn.0.debug=0x1 3. wlandebug -i wlan0 auth+assoc 4. Associate with AP in 11n mode 5. Send us appropriate /var/log/messages Then I try to compare it with my log. Please do. I've been trying to track down the source of this ht just doesn't work! but it works fine with all of the Intel NICs I have here. Can someone see if they can find a mtaching NIC online (amazon,ebay?) Owning one that I can whack in a laptop is likely going ot help things a lot. Thanks, -a ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RFT vidcontrol for vt(4)
On 11 March 2014 11:59, Steve Kargl s...@troutmask.apl.washington.edu wrote: Any chance that a manpage will ever show up? Yes, a vt(4) man page, and updates for pages like vidcontrol, are requirements for the project to be fully complete and shipped enabled by default in a release. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Too low PTHREAD_STACK_MIN value?
On 12 Mar 2014, at 02:07, Roger Pau Monné roger@citrix.com wrote: I've found out that the value PTHREAD_STACK_MIN is currently set (2048 bytes) seems to be way too low This looks like an error in your code. The spec says: PTHREAD_STACK_MIN Minimum size in bytes of thread stack storage. Minimum Acceptable Value: 0 It is meant to be the minimum value that the system can give for a thread stack. The purpose of this constant is for languages that do their own stack management bit some chain of activation records of segmented stacks, but want to use pthreads for threading, so that they can allocate the smallest possible stack that allows pthread cleanup to work. Using it from C code is very likely to be a mistake. David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
