Re: diff: improving msdosfs write speed for large files

2012-04-05 Thread Alexander Polakov 
* Mike Belopuhov m...@crypt.org.ru [120404 17:51]:
 i agree that this is a great find.  i don't really like the diff though.
 i see no point in introducing this macro.  what do others think?

Your diff looks better to me.

 Index: msdosfs/denode.h
 ===
 RCS file: /cvs/src/sys/msdosfs/denode.h,v
 retrieving revision 1.23
 diff -u -p -r1.23 denode.h
 --- msdosfs/denode.h  17 Jul 2010 19:27:07 -  1.23
 +++ msdosfs/denode.h  4 Apr 2012 12:20:23 -
 @@ -116,10 +116,11 @@ struct fatcache {
   * cache is probably pretty worthless if a file is opened by multiple
   * processes.
   */
 -#define  FC_SIZE 2   /* number of entries in the cache */
 +#define  FC_SIZE 3   /* number of entries in the cache */
  #define  FC_LASTMAP  0   /* entry the last call to pcbmap() 
 resolved
* to */
  #define  FC_LASTFC   1   /* entry for the last cluster in the 
 file */
 +#define  FC_OLASTFC  2   /* entry for the previous last cluster 
 */
  
  #define  FCE_EMPTY   0x  /* doesn't represent an actual 
 cluster # */
  
 Index: msdosfs/msdosfs_fat.c
 ===
 RCS file: /cvs/src/sys/msdosfs/msdosfs_fat.c,v
 retrieving revision 1.22
 diff -u -p -r1.22 msdosfs_fat.c
 --- msdosfs/msdosfs_fat.c 4 Jul 2011 04:30:41 -   1.22
 +++ msdosfs/msdosfs_fat.c 4 Apr 2012 12:20:26 -
 @@ -952,6 +952,13 @@ extendfile(struct denode *dep, uint32_t 
   return (error);
   }
  
 + /*
 +  * Preserve value for the last cluster before extending the file
 +  * to speed up further lookups.
 +  */
 + fc_setcache(dep, FC_OLASTFC, dep-de_fc[FC_LASTFC].fc_frcn,
 + dep-de_fc[FC_LASTFC].fc_fsrcn);
 +
   while (count  0) {
   /*
* Allocate a new cluster chain and cat onto the end of the

-- 
Alexander Polakov | plhk.ru

Re: diff: improving msdosfs write speed for large files

2012-04-05 Thread Mike Belopuhov 
On Thu, Apr 5, 2012 at 9:21 AM, Alexander Polakov polac...@gmail.com wrote:
 * Mike Belopuhov m...@crypt.org.ru [120404 17:51]:
 i agree that this is a great find.  i don't really like the diff though.
 i see no point in introducing this macro.  what do others think?

 Your diff looks better to me.


the diff is in. thanks for pointing this out to us!

Re: login_yubikey does not accept user.name

2012-04-05 Thread Björn Ketelaars 
On Thu, Apr 5, 2012 at 6:51 AM, Otto Moerbeek o...@drijf.net wrote:
 That sounds like timing bases attacks to guess a username still will work.

-Otto

First thing I thought when reading your reply: absolute nonsense. With
that mindset I really wanted to disprove your suggestion. For this I
have set-up two different scenarios:

1.) Local 'attack' without use of getpwnam (plain-vanilla login_yubikey)
2.) Local 'attack' with use of getpwnam (altered version, read: with
applied diff)

Each scenario was run two times: one time targeting existing users and
one time targeting not existing users. I measured the time it took to
get a reply (accept / reject) after sending a password. Each test-run
was done a couple ten thousand times. I compared data from the two
test-runs within each scenario using a simple t-test. For scenario 1,
I found that the probability that one can guess that a user exist or
not is less than 0,0014%. For scenario 2 the probability is less
than 0.0021%. Albeit the probability is small, it increased four
orders in magnitude.

In my own opinion I have failed to disprove your suggestion. I now can
imagine that somebody who has knowledge on the subject can derive
useful information as a result from the alteration to login_yubikey.
So, in a nutshell: I guess you are right!

From the different diffs I've send in I learned that code needs to be
readable, regexp is a no-no and that the use of getpwnam is probably
not a good idea. I changed my first diff to reflect the above
learning's.

As I am out of alternative ideas: Opinions? / Alternatives? / Comments?


Index: login_yubikey.c
===
RCS file: /cvs/src/libexec/login_yubikey/login_yubikey.c,v
retrieving revision 1.4
diff -u -p -r1.4 login_yubikey.c
--- login_yubikey.c 1 Feb 2012 16:07:28 -   1.4
+++ login_yubikey.c 5 Apr 2012 10:53:57 -
@@ -165,10 +165,18 @@ main(int argc, char *argv[])
 static int
 clean_string(const char *s)
 {
+   int nlim, n = 1;
+
+   nlim = strlen(s);
while (*s) {
-   if (!isalnum(*s)  *s != '-'  *s != '_')
+   if (n == 1  !isalnum(*s)  *s != '_')
+   return (0);
+   else if (n == nlim  !isalnum(*s)  *s != '_'  *s != '-')
+   return (0);
+   else if (!isalnum(*s)  *s != '_'  *s != '-'  *s != '.')
return (0);
++s;
+   ++n;
}
return (1);
 }

Re: login_yubikey does not accept user.name

2012-04-05 Thread Otto Moerbeek 
On Thu, Apr 05, 2012 at 01:32:46PM +0200, Bj?rn Ketelaars wrote:

 On Thu, Apr 5, 2012 at 6:51 AM, Otto Moerbeek o...@drijf.net wrote:
  That sounds like timing bases attacks to guess a username still will work.
 
 -Otto
 
 First thing I thought when reading your reply: absolute nonsense. With
 that mindset I really wanted to disprove your suggestion. For this I
 have set-up two different scenarios:
 
 1.) Local 'attack' without use of getpwnam (plain-vanilla login_yubikey)
 2.) Local 'attack' with use of getpwnam (altered version, read: with
 applied diff)
 
 Each scenario was run two times: one time targeting existing users and
 one time targeting not existing users. I measured the time it took to
 get a reply (accept / reject) after sending a password. Each test-run
 was done a couple ten thousand times. I compared data from the two
 test-runs within each scenario using a simple t-test. For scenario 1,
 I found that the probability that one can guess that a user exist or
 not is less than 0,0014%. For scenario 2 the probability is less
 than 0.0021%. Albeit the probability is small, it increased four
 orders in magnitude.
 
 In my own opinion I have failed to disprove your suggestion. I now can
 imagine that somebody who has knowledge on the subject can derive
 useful information as a result from the alteration to login_yubikey.
 So, in a nutshell: I guess you are right!
 
 From the different diffs I've send in I learned that code needs to be
 readable, regexp is a no-no and that the use of getpwnam is probably
 not a good idea. I changed my first diff to reflect the above
 learning's.
 
 As I am out of alternative ideas: Opinions? / Alternatives? / Comments?

 
I'm really wondering what's the purpose of clean_string(). If a bogus
name is suppied, the fopen will fail and that's it. Unless I'm missing
something obvious.

-Otto
 
 
 Index: login_yubikey.c
 ===
 RCS file: /cvs/src/libexec/login_yubikey/login_yubikey.c,v
 retrieving revision 1.4
 diff -u -p -r1.4 login_yubikey.c
 --- login_yubikey.c   1 Feb 2012 16:07:28 -   1.4
 +++ login_yubikey.c   5 Apr 2012 10:53:57 -
 @@ -165,10 +165,18 @@ main(int argc, char *argv[])
  static int
  clean_string(const char *s)
  {
 + int nlim, n = 1;
 +
 + nlim = strlen(s);
   while (*s) {
 - if (!isalnum(*s)  *s != '-'  *s != '_')
 + if (n == 1  !isalnum(*s)  *s != '_')
 + return (0);
 + else if (n == nlim  !isalnum(*s)  *s != '_'  *s != '-')
 + return (0);
 + else if (!isalnum(*s)  *s != '_'  *s != '-'  *s != '.')
   return (0);
   ++s;
 + ++n;
   }
   return (1);
  }

Impression grand format sur mesure. Rapide et Economique.

2012-04-05 Thread VEDI - Express 
Disponible en 3 jours

Impression HD (risistance UV)
4 supports et 8 finitions au choix

Fichiers: transfert online direct ou diffiri
Commandez en 5 minutes: facile  rapide!



Igalement sur mesure:
adhisifs, affiches papier,
posters photo  papier peint adhisif



Pour toutes les applications
* vitres et vitrines
* points de vente, bureaux
* adhisifs de sol
* signalitique (intirieur/extirieur)
* auto
* micro-perfori (One Way Vision)
* etc...
Associez-les ` un laminat pour optimiser la risistance et la tenue des
couleurs.

Papier peint personnalisi

* impression HD
   optimisie
* textile satin
   autocollant M1
* repositionnable
* haut de
   gamme
* dico d'intirieur,
   aminagement
   magasins,
   stands, etc...


Affiches papier  posters photo
* impression HD
* support laminable
* profiles de
  supension en
  aluminium
  anodisi





VEDI express ) 2002-2012
Rollup, Pop Up, bbches, stands parapluie aux meilleurs prix et dans les
meilleurs dilais.
Powered by VEDI
 ne plus recevoir nos newsletters



Fichiers acceptis
Taille des images :
Pour Pop Up 3x3m :
- Image 337,5x222cm : fichier 337,5x222cm
Pour Pop Up 4x3m :
- Image 405x222cm : fichier 405x222cm
Risolutions conseillies:
PDF: 80 dpi avec typo vectorisie
TIFF ou JPEG: 120 dpi
Format des fichiers acceptis :
PDF HD, EPS (avec polices et images incorpories et vectorisies), TIFF, JPEG
Respect des couleurs :
De prifirence, fournir les fichiers en CMYK (noir quadri: C70 M70 Y70 K100).
Les fichiers RGB seront convertis.





Garanties de qualiti
Qualiti d'impression :
Impression HD : vos images sont toujours imprimies en haute difinition.
Couleurs vivantes et respecties : La gestion des couleurs et la garantie de
rendu sont assuriespar notre iquipe d'infographistes et d'imprimeurs
professionnels expirimentis.
Encres UV risistantes : Les encres utilisies pour l'impression de votre image
sont toujours des encres risistantes aux rayons ultra violets. Ces encres de
qualiti garantissent une bonne longiviti aux couleurs de votre visuel, pour
une image toujours vive.
Supports de qualiti : Vos images sont imprimies sur support satini, pour un
meilleur rendu des couleurs et des contrastes. D'une ipaisseur de 170 5m ou
supirieure, nos supports d'impression vous garantissent une image qui ne
gondole pas et offrent une protection contre les griffes et les poussihres.
Risistants aux dichirures et ` l'eau, ils peuvent se nettoyer.
Images anti-feu : Vos images peuvent jtre imprimies sur support ignifugi B2 /
M1 (en option), idial et mjme parfois obligatoire pour les foires et salons.
Qualiti :
Structure solide : iliments construits en acier peint de section 20cm x 20 cm.
Simple ` monter : assemblage sans outil, montage en 30 minutes ` deux
personnes.
Idial pour la participation ` vos salons grand public ou professionnels.
La structure Wave permet de construire des stands dune multitude de
dimensions.
Les images murales sont fournies roulies avec une barre de suspension intigri
(Veclip). Elles se suspendent au montant horizontal supirieur du stand et se
diroulent de haut en bas entre les piliers.
Leur largeur est de maximum 2 mhtres afin de faciliter le stockage et le
transport.
Il existe 4 largeurs (50, 100, 150 et 200 cm) et 2 hauteurs (220 cm pour les
stands de 2m50 et 290cm pour les stand de 3m20).
Mises dos ` dos, elles permettent laffichage recto-verso. Vous choisissez
vous-mjme les diffirentes largeurs de sorte de combler complhtement un ctti du
stand ou de laisser un passage.
La largeur disponible pour limage est igale ` la largeur du stand moins 50
cm.
Par exemple: si la largeur du ctti du stand ` fermer est de 5 mhtres, la
largeur disponible pour limage est de 450cm. Pour combler cette largeur, vous
pouvez commander 2 images de 200cm et 1 image de 50cm. Si la hauteur de votre
stand est
de 320 cm, vous choisirez une hauteur dimage de 290 cm.
Production et livraison :
Livraison express : votre stand livri, prjt ` monter en 5 jours ouvrables.





Conditions ginirales de ventes
Giniralitis
Seules les prisentes conditions de vente sont dapplication pour la vente.
Ces conditions ginirales s'appliquent ` lexclusion de toutes autres
conditions, mjme celles reprises sur des bons de commande imanant de
lacheteur.
Le vendeur se riserve le droit de modifier ` tout moment ces conditions
ginirales. Nianmoins, les commandes en cours restent soumises aux conditions
applicables au moment oy la vente a iti conclue.
Les photos, illustrations, couleurs et textes associis aux produits repris sur
ce site nont pas de caracthre contractuel et de
ce fait ne sauraient engager la responsabiliti du vendeur.
Toute commande donnera lieu ` une facturation 30 jours aprhs son acceptation
dans le cas oy la commande ne peut jtre exicutie en raison d'un retard
imputable au client.
En cas d'annulation de sa commande, le client sera redevable d'un montant
correspondant aux frais dij` exposi, augmenti
d'une indemniti de 15 % du montant commandi.
La facture sera itablie ` la sociiti de

k5d061(AD)发（AD）票e

2012-04-05 Thread mail...@tw.mtf.news.yahoo.com 
 f( e/d:d8e  fg+ g5d= e!!

g5f(ggh(o

bbbbbbbbbbbbbbbbbbbbbbbbbbbbbb

qf1t2c3dd8h4e
!e%=

oADo  d;#

e

e

g%(

hg3;d::ofeg

hg3;g5h/o137-1427-5556
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb

k5d061(AD)eoADog%(e
http://tw.myblog.yahoo.com/jw!1K84p1yREQXRDO9YOXH0EfAuoaYkEjm18Q--/article?mid=1

Yahoo!e%f)fe0 d= gfe0.ee3.gf4;f0i+i)c
http://tw.fashion.yahoo.com/
g   f,
f   f   Yahoo!e%f)

jumbos for bge(4) BCM5714/5715/5780

2012-04-05 Thread Brad Smith 
The following diff adds support for jumbos with the bge(4) BCM5714/5715/5780
chipsets. I have only been able to find someone to test with a 5714 family
chipset with non-jumbo mode of operation but it's a remote system on a network
without jumbos so not able to test there as well as 5700 family with and without
jumbos and newer chipsets without (they don't support jumbos). So I'm looking
for someone with a 5714 family chipset (5714, 5715, 5780) and is able to test
with an approriate setup with jumbos that would be great.


Index: share/man/man4/bge.4
===
RCS file: /home/cvs/src/share/man/man4/bge.4,v
retrieving revision 1.53
diff -u -p -r1.53 bge.4
--- share/man/man4/bge.413 Jul 2011 07:44:38 -  1.53
+++ share/man/man4/bge.413 Mar 2012 01:00:30 -
@@ -122,8 +122,8 @@ The BCM5717, BCM5718, BCM5723, BCM5724, 
 BCM5784, BCM5785, BCM5787 and BCM577xx chips also support IPv6 receive TCP/UDP
 checksum offload.
 .Pp
-The BCM5700, BCM5701, BCM5703 and BCM5704 chips are capable of
-supporting Jumbo frames, which can be configured via the
+The BCM5700, BCM5701, BCM5703, BCM5704, BCM5714, BCM5715 and BCM5780 chips are
+capable of supporting Jumbo frames, which can be configured via the
 interface MTU setting.
 Selecting an MTU larger than 1500 bytes with the
 .Xr ifconfig 8
Index: sys/dev/pci/if_bge.c
===
RCS file: /home/cvs/src/sys/dev/pci/if_bge.c,v
retrieving revision 1.307
diff -u -p -r1.307 if_bge.c
--- sys/dev/pci/if_bge.c22 Jun 2011 16:44:27 -  1.307
+++ sys/dev/pci/if_bge.c13 Mar 2012 02:04:55 -
@@ -731,10 +731,10 @@ bge_newbuf(struct bge_softc *sc, int i)
struct mbuf *m;
int error;
 
-   m = MCLGETI(NULL, M_DONTWAIT, sc-arpcom.ac_if, MCLBYTES);
+   m = MCLGETI(NULL, M_DONTWAIT, sc-arpcom.ac_if, sc-bge_std_len);
if (!m)
return (ENOBUFS);
-   m-m_len = m-m_pkthdr.len = MCLBYTES;
+   m-m_len = m-m_pkthdr.len = sc-bge_std_len;
if (!(sc-bge_flags  BGE_RX_ALIGNBUG))
m_adj(m, ETHER_ALIGN);
 
@@ -859,8 +859,8 @@ bge_init_rx_ring_std(struct bge_softc *s
return (0);
 
for (i = 0; i  BGE_STD_RX_RING_CNT; i++) {
-   if (bus_dmamap_create(sc-bge_dmatag, MCLBYTES, 1, MCLBYTES, 0,
-   BUS_DMA_WAITOK | BUS_DMA_ALLOCNOW,
+   if (bus_dmamap_create(sc-bge_dmatag, sc-bge_std_len, 1,
+   sc-bge_std_len, 0, BUS_DMA_WAITOK | BUS_DMA_ALLOCNOW,
sc-bge_cdata.bge_rx_std_map[i]) != 0) {
printf(%s: unable to create dmamap for slot %d\n,
sc-bge_dev.dv_xname, i);
@@ -1434,7 +1434,7 @@ bge_blockinit(struct bge_softc *sc)
 * using this ring (i.e. once we set the MTU
 * high enough to require it).
 */
-   if (BGE_IS_JUMBO_CAPABLE(sc)) {
+   if (sc-bge_flags  BGE_JUMBO_RING) {
rcb = sc-bge_rdata-bge_info.bge_jumbo_rx_rcb;
BGE_HOSTADDR(rcb-bge_hostaddr,
BGE_RING_DMA_ADDR(sc, bge_rx_jumbo_ring));
@@ -1472,6 +1472,7 @@ bge_blockinit(struct bge_softc *sc)
CSR_WRITE_4(sc, BGE_ISO_PKT_TX,
(CSR_READ_4(sc, BGE_ISO_PKT_TX)  ~3) | 2);
}
+
/*
 * Set the BD ring replenish thresholds. The recommended
 * values are 1/8th the number of descriptors allocated to
@@ -1481,7 +1482,8 @@ bge_blockinit(struct bge_softc *sc)
 * to work around HW bugs.
 */
CSR_WRITE_4(sc, BGE_RBDI_STD_REPL_THRESH, 8);
-   CSR_WRITE_4(sc, BGE_RBDI_JUMBO_REPL_THRESH, 8);
+   if (sc-bge_flags  BGE_JUMBO_RING)
+   CSR_WRITE_4(sc, BGE_RBDI_JUMBO_REPL_THRESH, 8);
 
if (BGE_ASICREV(sc-bge_chipid) == BGE_ASICREV_BCM5717 ||
BGE_ASICREV(sc-bge_chipid) == BGE_ASICREV_BCM57765) {
@@ -1968,9 +1970,15 @@ bge_attach(struct device *parent, struct
sc-bge_flags  BGE_PCIX)
sc-bge_flags |= BGE_RX_ALIGNBUG;
 
-   if (BGE_IS_5700_FAMILY(sc))
+   if (BGE_IS_5700_FAMILY(sc) || BGE_IS_5714_FAMILY(sc))
sc-bge_flags |= BGE_JUMBO_CAPABLE;
 
+   if (BGE_IS_5700_FAMILY(sc))
+   sc-bge_flags |= BGE_JUMBO_RING;
+
+   if (BGE_IS_5714_FAMILY(sc))
+   sc-bge_flags |= BGE_JUMBO_STD;
+
if ((BGE_ASICREV(sc-bge_chipid) == BGE_ASICREV_BCM5700 ||
BGE_ASICREV(sc-bge_chipid) == BGE_ASICREV_BCM5701) 
PCI_VENDOR(subid) == DELL_VENDORID)
@@ -2034,6 +2042,11 @@ bge_attach(struct device *parent, struct
sc-bge_flags |= BGE_PHY_BER_BUG;
}
 
+   if (sc-bge_flags  BGE_JUMBO_STD)
+   sc-bge_std_len = BGE_JLEN;
+   else
+   sc-bge_std_len = MCLBYTES;
+
/* Try to reset the chip. */