uid_t fix for sa(8)
deraadt@ pointed out that NetBSD committed a uid_t fix for their
sa(8), and as far as I can tell, it's needed in our tree too.
I'd really appreciate if someone who actually uses sa(8) could test
that this diff still works for them and save me the trouble of
learning how to use it. :) The important thing to test here is that
the per-user accounting summary database (i.e., /var/account/usracct)
is still updated correctly.
Index: usrdb.c
===
RCS file: /cvs/src/usr.sbin/sa/usrdb.c,v
retrieving revision 1.8
diff -u -p -r1.8 usrdb.c
--- usrdb.c 27 Oct 2009 23:59:54 - 1.8
+++ usrdb.c 30 Aug 2010 15:51:19 -
@@ -264,7 +264,7 @@ usracct_print(void)
static int
uid_compare(const DBT *k1, const DBT *k2)
{
- u_long d1, d2;
+ uid_t d1, d2;
memcpy(d1, k1-data, sizeof(d1));
memcpy(d2, k2-data, sizeof(d2));
Re: AES-GCM Part 2: PFKEY/ESP
On Tue, Aug 24, 2010 at 12:57 +0200, Mike Belopuhov wrote:
On Mon, Aug 23, 2010 at 20:19 +0200, Mike Belopuhov wrote:
ESP part gets a nice hack (esp_gcm_init_auth) that fakes an
authentication part of GCM from the encryption one. Frankly,
I'd rather put this into the userland, but it won't be that
simple and contained. Turned out, that it's much easier not
to touch SADB/PFKEY interface and deal with this at the ESP
initialization time.
OK, I lied. It's easy to do it at least in isakmpd. New diff.
after another round of poking, looks like it's better to do this
in the kernel so that userland applications won't need to care
about faking anything and will just provide the encryption part.
i decided to inline esp_gcm_init_auth content to the esp_init.
Index: net/pfkeyv2.h
===
RCS file: /home/cvs/src/sys/net/pfkeyv2.h,v
retrieving revision 1.58
diff -u -p -u -p -r1.58 pfkeyv2.h
--- net/pfkeyv2.h 9 Jul 2010 16:58:06 - 1.58
+++ net/pfkeyv2.h 23 Aug 2010 16:56:23 -
@@ -297,6 +297,9 @@ struct sadb_x_tap {
#define SADB_X_AALG_SHA2_384 6
#define SADB_X_AALG_SHA2_512 7
#define SADB_X_AALG_RIPEMD160HMAC8
+#define SADB_X_AALG_AES128GMAC 9
+#define SADB_X_AALG_AES192GMAC 10
+#define SADB_X_AALG_AES256GMAC 11
#define SADB_X_AALG_MD5 249
#define SADB_X_AALG_SHA1 250
#define SADB_AALG_MAX250
@@ -315,6 +318,10 @@ struct sadb_x_tap {
#define SADB_EALG_NULL11
#define SADB_X_EALG_AES 12
#define SADB_X_EALG_AESCTR13
+#define SADB_X_EALG_AESGCM8 18
+#define SADB_X_EALG_AESGCM12 19
+#define SADB_X_EALG_AESGCM16 20
+#define SADB_X_EALG_AESGMAC 21
#define SADB_X_EALG_SKIPJACK 249
#define SADB_EALG_MAX 249
Index: net/pfkeyv2_convert.c
===
RCS file: /home/cvs/src/sys/net/pfkeyv2_convert.c,v
retrieving revision 1.32
diff -u -p -u -p -r1.32 pfkeyv2_convert.c
--- net/pfkeyv2_convert.c 1 Jul 2010 02:09:45 - 1.32
+++ net/pfkeyv2_convert.c 23 Aug 2010 16:08:56 -
@@ -211,6 +211,18 @@ export_sa(void **p, struct tdb *tdb)
sadb_sa-sadb_sa_auth = SADB_X_AALG_SHA2_512;
break;
+ case CRYPTO_AES_128_GMAC:
+ sadb_sa-sadb_sa_auth = SADB_X_AALG_AES128GMAC;
+ break;
+
+ case CRYPTO_AES_192_GMAC:
+ sadb_sa-sadb_sa_auth = SADB_X_AALG_AES192GMAC;
+ break;
+
+ case CRYPTO_AES_256_GMAC:
+ sadb_sa-sadb_sa_auth = SADB_X_AALG_AES256GMAC;
+ break;
+
case CRYPTO_MD5_KPDK:
sadb_sa-sadb_sa_auth = SADB_X_AALG_MD5;
break;
@@ -241,6 +253,14 @@ export_sa(void **p, struct tdb *tdb)
case CRYPTO_AES_CTR:
sadb_sa-sadb_sa_encrypt = SADB_X_EALG_AESCTR;
+ break;
+
+ case CRYPTO_AES_GCM_16:
+ sadb_sa-sadb_sa_encrypt = SADB_X_EALG_AESGCM16;
+ break;
+
+ case CRYPTO_AES_GMAC:
+ sadb_sa-sadb_sa_encrypt = SADB_X_EALG_AESGMAC;
break;
case CRYPTO_CAST_CBC:
Index: netinet/ip_esp.c
===
RCS file: /home/cvs/src/sys/netinet/ip_esp.c,v
retrieving revision 1.111
diff -u -p -u -p -r1.111 ip_esp.c
--- netinet/ip_esp.c20 Jul 2010 15:36:03 - 1.111
+++ netinet/ip_esp.c30 Aug 2010 18:37:27 -
@@ -131,6 +131,14 @@ esp_init(struct tdb *tdbp, struct xforms
txform = enc_xform_aes_ctr;
break;
+ case SADB_X_EALG_AESGCM16:
+ txform = enc_xform_aes_gcm;
+ break;
+
+ case SADB_X_EALG_AESGMAC:
+ txform = enc_xform_aes_gmac;
+ break;
+
case SADB_X_EALG_BLF:
txform = enc_xform_blf;
break;
@@ -158,6 +166,23 @@ esp_init(struct tdb *tdbp, struct xforms
return EINVAL;
}
+ if (ii-ii_encalg == SADB_X_EALG_AESGCM16 ||
+ ii-ii_encalg == SADB_X_EALG_AESGMAC) {
+ switch (ii-ii_enckeylen) {
+ case 20:
+ ii-ii_authalg = SADB_X_AALG_AES128GMAC;
+ break;
+ case 28:
+ ii-ii_authalg = SADB_X_AALG_AES192GMAC;
+ break;
+ case 36:
+ ii-ii_authalg = SADB_X_AALG_AES256GMAC;
+
AES-GCM Part 3: isakmpd
isakmpd part. both initiator and responder modes work fine.
tested against strongswan/pluto and itself.
note that it defaults to AESGCM-256 (i did it this way because
linux picks largest key).
Index: conf.c
===
RCS file: /home/cvs/src/sbin/isakmpd/conf.c,v
retrieving revision 1.98
diff -u -p -r1.98 conf.c
--- conf.c 4 Aug 2010 18:09:45 - 1.98
+++ conf.c 30 Aug 2010 20:22:10 -
@@ -428,13 +428,21 @@ conf_load_defaults_qm(int tr, char *qme,
if (strcmp(qme ,BLOWFISH) == 0)
conf_set(tr, sect, KEY_LENGTH, CONF_DFLT_VAL_BLF_KEYLEN, 0,
1);
- else if (strcmp(qme_p ,-AES-128) == 0)
+ else if (strcmp(qme_p ,-AESGCM-128) == 0 ||
+ strcmp(qme_p ,-AESGMAC-128) == 0 ||
+ strcmp(qme_p ,-AES-128) == 0)
conf_set(tr, sect, KEY_LENGTH, 128,128:128, 0, 1);
- else if (strcmp(qme_p ,-AES-192) == 0)
+ else if (strcmp(qme_p ,-AESGCM-192) == 0 ||
+ strcmp(qme_p ,-AESGMAC-192) == 0 ||
+ strcmp(qme_p ,-AES-192) == 0)
conf_set(tr, sect, KEY_LENGTH, 192,192:192, 0, 1);
-else if (strcmp(qme_p ,-AES-256) == 0)
-conf_set(tr, sect, KEY_LENGTH, 256,256:256, 0, 1);
- else if (strcmp(qme ,AES) == 0)
+ else if (strcmp(qme_p ,-AESGCM-256) == 0 ||
+ strcmp(qme_p ,-AESGMAC-256) == 0 ||
+ strcmp(qme_p ,-AES-256) == 0)
+ conf_set(tr, sect, KEY_LENGTH, 256,256:256, 0, 1);
+ else if (strcmp(qme ,AESGCM) == 0 ||
+ strcmp(qme ,AESGMAC) == 0 ||
+ strcmp(qme ,AES) == 0)
conf_set(tr, sect, KEY_LENGTH, CONF_DFLT_VAL_AES_KEYLEN, 0,
1);
@@ -472,9 +480,13 @@ conf_load_defaults(int tr)
char*dhgroup_p[] = {, -GRP1, -GRP2, -GRP5, -GRP14,
-GRP15, 0};
char*qm_enc[] = {DES, 3DES, CAST, BLOWFISH, AES,
- AES, AES, AES, AES_128_CTR, NULL, NONE, 0};
+ AES, AES, AES, AES_128_CTR, AES_GCM_16,
+ AES_GCM_16, AES_GCM_16, AES_GCM_16, AES_GMAC,
+ AES_GMAC, AES_GMAC, AES_GMAC, NULL, NONE, 0};
char*qm_enc_p[] = {-DES, -3DES, -CAST, -BLF, -AES,
- -AES-128, -AES-192, -AES-256, -AESCTR, -NULL,
+ -AES-128, -AES-192, -AES-256, -AESCTR, -AESGCM,
+ -AESGCM-128, -AESGCM-192, -AESGCM-256, -AESGMAC,
+ -AESGMAC-128, -AESGMAC-192, -AESGMAC-256, -NULL,
, 0};
char*qm_hash[] = {HMAC_MD5, HMAC_SHA, HMAC_RIPEMD,
HMAC_SHA2_256, HMAC_SHA2_384, HMAC_SHA2_512, NONE,
Index: ipsec.c
===
RCS file: /home/cvs/src/sbin/isakmpd/ipsec.c,v
retrieving revision 1.135
diff -u -p -r1.135 ipsec.c
--- ipsec.c 29 Jun 2010 19:50:16 - 1.135
+++ ipsec.c 30 Aug 2010 20:21:07 -
@@ -975,7 +975,7 @@ ipsec_validate_transform_id(u_int8_t pro
transform_id IPSEC_AH_RIPEMD ? -1 : 0;
case IPSEC_PROTO_IPSEC_ESP:
return transform_id IPSEC_ESP_DES_IV64 ||
- (transform_id IPSEC_ESP_AES_128_CTR
+ (transform_id IPSEC_ESP_AES_GMAC
transform_id IPSEC_ESP_AES_MARS) ||
transform_id IPSEC_ESP_AES_TWOFISH ? -1 : 0;
case IPSEC_PROTO_IPCOMP:
@@ -1788,6 +1788,11 @@ ipsec_esp_enckeylength(struct proto *pro
return iproto-keylen / 8;
case IPSEC_ESP_AES_128_CTR:
return 20;
+ case IPSEC_ESP_AES_GCM_16:
+ case IPSEC_ESP_AES_GMAC:
+ if (!iproto-keylen)
+ return 36;
+ return iproto-keylen / 8 + 4;
case IPSEC_ESP_AES:
if (!iproto-keylen)
return 16;
Index: ipsec_num.cst
===
RCS file: /home/cvs/src/sbin/isakmpd/ipsec_num.cst,v
retrieving revision 1.16
diff -u -p -r1.16 ipsec_num.cst
--- ipsec_num.cst 14 Jun 2005 10:50:47 - 1.16
+++ ipsec_num.cst 30 Aug 2010 18:15:03 -
@@ -235,6 +235,8 @@ IPSEC_ESP
NULL 11
AES 12
AES_128_CTR 13
+ AES_GCM_16 20
+ AES_GMAC 23
AES_MARS 249
AES_RC6 250
AES_RIJNDAEL 251
Index: isakmpd.conf.5
===
RCS file: /home/cvs/src/sbin/isakmpd/isakmpd.conf.5,v
retrieving revision 1.126
diff -u -p -r1.126 isakmpd.conf.5
--- isakmpd.conf.5 7 Jun 2010 08:38:09 - 1.126
+++ isakmpd.conf.5 30 Aug 2010 19:15:37 -
@@ -141,7 +141,9 @@ where:
.It Ns {
AES-GCM Part 4: ipsecctl
ipsecctl part.
Index: ike.c
===
RCS file: /home/cvs/src/sbin/ipsecctl/ike.c,v
retrieving revision 1.67
diff -u -p -r1.67 ike.c
--- ike.c 4 Oct 2009 11:39:32 - 1.67
+++ ike.c 30 Aug 2010 17:54:19 -
@@ -161,6 +161,7 @@ static int
ike_section_p2(struct ipsec_rule *r, FILE *fd)
{
char*exchange_type, *sprefix;
+ int needauth = 1;
switch (r-p2ie) {
case IKE_QM:
@@ -224,6 +225,38 @@ ike_section_p2(struct ipsec_rule *r, FIL
case ENCXF_AESCTR:
fprintf(fd, AESCTR);
break;
+ case ENCXF_AES_GCM:
+ fprintf(fd, AESGCM);
+ needauth = 0;
+ break;
+ case ENCXF_AES_128_GCM:
+ fprintf(fd, AESGCM-128);
+ needauth = 0;
+ break;
+ case ENCXF_AES_192_GCM:
+ fprintf(fd, AESGCM-192);
+ needauth = 0;
+ break;
+ case ENCXF_AES_256_GCM:
+ fprintf(fd, AESGCM-256);
+ needauth = 0;
+ break;
+ case ENCXF_AES_GMAC:
+ fprintf(fd, AESGMAC);
+ needauth = 0;
+ break;
+ case ENCXF_AES_128_GMAC:
+ fprintf(fd, AESGMAC-128);
+ needauth = 0;
+ break;
+ case ENCXF_AES_192_GMAC:
+ fprintf(fd, AESGMAC-192);
+ needauth = 0;
+ break;
+ case ENCXF_AES_256_GMAC:
+ fprintf(fd, AESGMAC-256);
+ needauth = 0;
+ break;
case ENCXF_BLOWFISH:
fprintf(fd, BLF);
break;
@@ -232,6 +265,7 @@ ike_section_p2(struct ipsec_rule *r, FIL
break;
case ENCXF_NULL:
fprintf(fd, NULL);
+ needauth = 0;
break;
default:
warnx(illegal transform %s,
@@ -270,43 +304,44 @@ ike_section_p2(struct ipsec_rule *r, FIL
warnx(illegal transform %s, r-p2xfs-authxf-name);
return (-1);
}
- } else
- fprintf(fd, SHA2-256);
+ fprintf(fd, -);
+ } else if (needauth)
+ fprintf(fd, SHA2-256-);
if (r-p2xfs r-p2xfs-groupxf) {
switch (r-p2xfs-groupxf-id) {
case GROUPXF_NONE:
break;
case GROUPXF_768:
- fprintf(fd, -PFS-GRP1);
+ fprintf(fd, PFS-GRP1);
break;
case GROUPXF_1024:
- fprintf(fd, -PFS-GRP2);
+ fprintf(fd, PFS-GRP2);
break;
case GROUPXF_1536:
- fprintf(fd, -PFS-GRP5);
+ fprintf(fd, PFS-GRP5);
break;
case GROUPXF_2048:
- fprintf(fd, -PFS-GRP14);
+ fprintf(fd, PFS-GRP14);
break;
case GROUPXF_3072:
- fprintf(fd, -PFS-GRP15);
+ fprintf(fd, PFS-GRP15);
break;
case GROUPXF_4096:
- fprintf(fd, -PFS-GRP16);
+ fprintf(fd, PFS-GRP16);
break;
case GROUPXF_6144:
- fprintf(fd, -PFS-GRP17);
+ fprintf(fd, PFS-GRP17);
break;
case GROUPXF_8192:
- fprintf(fd, -PFS-GRP18);
+ fprintf(fd, PFS-GRP18);
break;
default:
warnx(illegal group %s, r-p2xfs-groupxf-name);
return (-1);
};
} else
- fprintf(fd, -PFS);
+ fprintf(fd, PFS);
fprintf(fd, -SUITE force\n);
return (0);
Index: ipsec.conf.5
===
RCS file: /home/cvs/src/sbin/ipsecctl/ipsec.conf.5,v
retrieving revision 1.126
diff -u -p -r1.126 ipsec.conf.5
Looking for testers for a simple X test
The Xorg xserver runs a scary amount of code in a signal handler. It's supposed to make your mouse cursor move more smoothly, but I can't spot the difference when I disable that feature. Instead, this feature breaks certain multi-card setups and god knows what. So we're considering switching this off by default. Before we do that, we'd like to do some wider testing. If you're regularly sitting behind an OpenBSD machine running X, can you add the following lines to /etc/X11/xorg.conf (or create one with these lines): Section ServerFlags Option UseSIGIO false EndSection and restart X. Let me know if you observe any significant changes in behaviour. Thanks, Mark
Re: Backout mclgeti for vr(4).
Evening, I have two machines with vr(4) interfaces running 4.7, and I can't seem to find any problem running ping -f against them. vr0 at pci0 dev 12 function 0 VIA VT6105 RhineIII rev 0x86: apic 2 int 19 (irq 10), address 00:19:5b:82:a1:e0 vr0 at pci0 dev 16 function 0 VIA Rhine/RhineII rev 0x06: irq 9, address 00:50:ba:bd:89:4d Is it possible that this bug only effects a few models? -Bryan.
Re: Backout mclgeti for vr(4).
On Mon, Aug 30, 2010 at 06:46:53PM -0400, Brynet wrote: Evening, I have two machines with vr(4) interfaces running 4.7, and I can't seem to find any problem running ping -f against them. vr0 at pci0 dev 12 function 0 VIA VT6105 RhineIII rev 0x86: apic 2 int 19 (irq 10), address 00:19:5b:82:a1:e0 vr0 at pci0 dev 16 function 0 VIA Rhine/RhineII rev 0x06: irq 9, address 00:50:ba:bd:89:4d Is it possible that this bug only effects a few models? Possible. I can't remember what model I had (as I no longer have access to the machines) but it was a soekris. It was pretty easy for me to crash the machine, ~8 ping -f's (from two different hosts on a 1G lan).
Re: Looking for testers for a simple X test
Mark Kettenis wrote: The Xorg xserver runs a scary amount of code in a signal handler. It's supposed to make your mouse cursor move more smoothly, but I can't spot the difference when I disable that feature. Instead, this feature breaks certain multi-card setups and god knows what. So we're considering switching this off by default. Before we do that, we'd like to do some wider testing. If you're regularly sitting behind an OpenBSD machine running X, can you add the following lines to /etc/X11/xorg.conf (or create one with these lines): Section ServerFlags Option UseSIGIO false EndSection and restart X. Let me know if you observe any significant changes in behaviour. Thanks, Mark Hi, Thanks you very much for this message. I use OpenBSD -stable with KDE. This setting has made a huge improvement to my quality of life :). After using the mouse for a bit, the mouse cursor would change to a square block or some other shape for no apparent reason. If the mouse cursor looked too weird and unusable my only recourse was to reboot my workstation (even restarting KDE or changing to the built-in WM did not help). This behavior started after around OpenBSD 3.9 or 4.0 -- after changing from xf86 to xorg or whatever (sorry, I don't know what I am talking about). I assumed this was because of using four monitors and two cards and changed my configuration to using two monitors and one card. The behavior persisted but since everything else worked perfectly and there were no complaints of this type in misc@ I thought it may be the hardware. Anyways, once I added the UseSIGIO option, I seem to have NO PROBLEMS with this configuration on my main system. I am using radeon instead of radeondrm since it seems to deal with the mouse problem better but will try this setting with radeondrm driver as well on this workstation. I have made this change to four other systems (Dell 2950, Supermicro X8SIL, ASUS netbook, LG notebook -- two servers are running AMD64 running 4.7 -stable and notebook and netbook are running i386 -current). Will report back after using those the next few days. On my main system I am using $ sysctl kern.version kern.version=OpenBSD 4.5-stable (GENERIC.MP.NPS) #1: Mon Jul 6 11:44:38 CDT 2009 r...@server11.sankars.local:/usr/src/sys/arch/i386/compile/GENERIC.MP.NPS Here is my xorg.conf in case it is of any use. Section ServerLayout Identifier X.org Configured Screen 0 Screen0 0 0 InputDeviceMouse0 CorePointer InputDeviceKeyboard0 CoreKeyboard EndSection Section Files ModulePath /usr/X11R6/lib/modules FontPath /usr/X11R6/lib/X11/fonts/misc/ FontPath /usr/X11R6/lib/X11/fonts/TTF/ FontPath /usr/X11R6/lib/X11/fonts/OTF FontPath /usr/X11R6/lib/X11/fonts/Type1/ FontPath /usr/X11R6/lib/X11/fonts/100dpi/ FontPath /usr/X11R6/lib/X11/fonts/75dpi/ EndSection Section Module Load dbe Load dri Load extmod Load glx Load freetype EndSection Section InputDevice Identifier Keyboard0 Driver kbd EndSection Section InputDevice Identifier Mouse0 Driver mouse Option Protocol wsmouse Option Device /dev/wsmouse Option ZAxisMapping 4 5 6 7 EndSection Section Monitor #DisplaySize 530 300 # mm Identifier Monitor0 VendorName SAM ModelNameSyncMaster HorizSync30.0 - 81.0 VertRefresh 56.0 - 75.0 Option DPMS EndSection Section Device ### Available Driver options are:- ### Values: i: integer, f: float, bool: True/False, ### string: String, freq: f Hz/kHz/MHz ### [arg]: arg optional #Option NoAccel # [bool] #Option SWcursor # [bool] #Option Dac6Bit # [bool] #Option Dac8Bit # [bool] #Option BusType # [str] #Option CPPIOMode # [bool] #Option CPusecTimeout # i #Option AGPMode # i #Option AGPFastWrite # [bool] #Option AGPSize # i #Option GARTSize # i #Option RingSize # i #Option BufferSize# i #Option EnableDepthMoves # [bool] #Option EnablePageFlip# [bool] #Option NoBackBuffer # [bool] #Option DMAForXv # [bool] #Option FBTexPercent # i #Option DepthBits # i #Option PCIAPERSize # i #Option AccelDFS # [bool] #Option DDCMode #
Re: Looking for testers for a simple X test
On Mon, Aug 30, 2010 at 11:31:25PM +0200, Mark Kettenis wrote: The Xorg xserver runs a scary amount of code in a signal handler. It's supposed to make your mouse cursor move more smoothly, but I can't spot the difference when I disable that feature. Instead, this feature breaks certain multi-card setups and god knows what. So we're considering switching this off by default. Before we do that, we'd like to do some wider testing. If you're regularly sitting behind an OpenBSD machine running X, can you add the following lines to /etc/X11/xorg.conf (or create one with these lines): Section ServerFlags Option UseSIGIO false EndSection and restart X. Let me know if you observe any significant changes in behaviour. How can you tell whether this option is turned on by default or not? xorg.conf(5) indicates that the default is platform dependent and that this option in general should only be used as a work-around to a bug until fixed. --patrick
Re: Looking for testers for a simple X test
How can you tell whether this option is turned on by default or not? xorg.conf(5) indicates that the default is platform dependent and that this option in general should only be used as a work-around to a bug until fixed. The X documentation is full of lies.
