Re: A proposal

2014-03-30 Thread Joe Nosay 
On Sat, Mar 29, 2014 at 12:14 PM, Allan Jude free...@allanjude.com wrote:

 On 2014-03-29 09:21, Joe Nosay wrote:
  On Sat, Mar 29, 2014 at 9:11 AM, Steve Kargl 
  s...@troutmask.apl.washington.edu wrote:
 
  On Sat, Mar 29, 2014 at 10:29:23AM +0100, Lars Engels wrote:
  On Fri, Mar 28, 2014 at 10:52:49PM -0700, Steve Kargl wrote:
  On Sat, Mar 29, 2014 at 01:46:15AM -0400, Joe Nosay wrote:
  On Sat, Mar 29, 2014 at 1:43 AM, Allan Jude free...@allanjude.com
  wrote:
 
  On 2014-03-29 01:22, Joe Nosay wrote:
  I have noticed that options VPS, VIMAGE, and MROUTING are not
  standard
  for
  the kernel with a base install. Is there any way that these can be
  made a
  part of the normal kernel so that jail(s) would get the full
 benefit
  without a kernel recompile?
 
 
  VIMAGE has some problems with PF. Martin Matu ska said at AsiaBSDCon
  that he had a patch that solves the issue.
 
  Really, you say? That's good news.
  So, will those options soon be standard for a first time install?
 
  Certainly, hope not.  I don't use any of options.
 
  So you use all the other devices and options of the GENERIC kernel?
 
  Of course, not.  Not sure how you inferred such a thing.
 
  IMHO, GENERIC should contain only those devices and options
  that are required to get FreeBSD booted on new hardware.
  VIMAGE and MROUTING aren't needed, and can be configured by
  the user after installation.  As for VPS, AFAICT, there isn't
  an option/device named VPS; at least 'find /sys/ -type f | xargs
  grep VPS' wasn't too enlightening.
 
 
  --
  Steve
 
 
 
  http://www.7he.at/freebsd/vps/announcements/
 
 
  Booyah. It exists.
  ___
  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
 

 VPS only exists in a project branch, and is not nearly in a state to be
 included in GENERIC

 And I don't see a compelling reason to have MROUTING in GENERIC either.

 --
 Allan Jude



VIMAGE?
___
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: r263096 sparc64: casperd: Unable to receive message from client: Cannot allocate memory.

2014-03-30 Thread Alexey Dokuchaev 
On Fri, Mar 14, 2014 at 02:54:43PM +0100, Jilles Tjoelker wrote:
 On Thu, Mar 13, 2014 at 05:14:56AM -0700, Anton Shterenlikht wrote:
  Mar 13 12:08:48 casperd[1313]: [ERROR] (casperd) Unable to receive message 
  from client: Cannot allocate memory.
  Mar 13 12:08:50 last message repeated 2 times
  Mar 13 12:09:57 casperd[1313]: [ERROR] (casperd) Unable to receive message 
  from client: Cannot allocate memory.

I'm seeing this as well on fresh -CURRENT/powerpc when trying to ping(8)
something with casperd(8) enabled; albeit a bit different (s/Cannot allocate
memory/Invalid argument/).

 It looks like a bug causes the big endian flag to be lost. As a
 result, the bits are interpreted as little endian and an extremely large
 allocation is attempted. Try this patch:
 
 Index: lib/libnv/nvlist.c
 ===
 --- lib/libnv/nvlist.c(revision 262358)
 +++ lib/libnv/nvlist.c(working copy)
 @@ -582,7 +582,7 @@ nvlist_check_header(struct nvlist_header *nvlhdrp)
   errno = EINVAL;
   return (false);
   }
 - if ((nvlhdrp-nvlh_flags = ~NV_FLAG_ALL_MASK) != 0) {
 + if ((nvlhdrp-nvlh_flags  ~NV_FLAG_ALL_MASK) != 0) {
   errno = EINVAL;
   return (false);
   }

This patch alone (without touching lib/libnv/msgio.c) fixed it for me
(applied, rebuilt/reinstalled libnv, restared casperd(8)), thank you! :)

./danfe
___
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: Call for testers: SNMPv3 support for bsnmpd(1)

2014-03-30 Thread Hartmut Brandt 
Hi Anthony,

On Fri, 28 Mar 2014, Marciano, Anthony wrote:

MAI've been tasked to get bsnmpd V3 working for my company. The post 
MAreferenced in the subject above gave me some insights but I'm still 
MAstuck and was wondering if you would take the time to answer some 
MAquestions. I'm a snmpV3 newbie and have never worked with bsnmpd. I 
MAhave worked minimally with net-snmp V2.
MA
MAFirst, is there a document listing all of the configuration options in 
MAthe snmpd.confg file? It appears to differ from other packages such as 
MAnet-snmp.


I can answer only this question - I'm not very familiar with SNMPv3, but 
Shteryana should be able to help.

No, there is no document with all the setting. The reason is simple: the 
config file is just a set of SNMP SET PDUs executed at startup, SIGHUP or 
module load. The file is segmented into sections by %name lines with all 
segments having the same name beeing put together. At the begin of the 
file there is an implicit %snmpd line.

Each section is a SET PDU. The %snmpd PDU is executed on startup and 
SIGHUP, all other sections are executed when the corresponding module is 
beeing loaded or on SIGHUP if that module is already loaded when the 
SIGHUP occures.

So any writeable or creatable MIB variable can be put into the 
configuration file.

harti
___
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: sendmail Broken Pipe Error

2014-03-30 Thread Willy Offermans 
Hello Rick and FreeBSD friends,

On Fri, Mar 28, 2014 at 06:25:23PM -0400, Rick Macklem wrote:
 John-Mark Gurney wrote:
  Willy Offermans wrote this message on Thu, Mar 27, 2014 at 15:46
  +0100:
   Hello John-Mark and FreeBSD friends,
   
   On Wed, Mar 26, 2014 at 04:04:27PM -0700, John-Mark Gurney wrote:
Willy Offermans wrote this message on Wed, Mar 26, 2014 at 18:22
+0100:
 Hello John-Mark and FreeBSD friends,
 
 On Wed, Mar 26, 2014 at 09:20:35AM -0700, John-Mark Gurney
 wrote:
  Willy Offermans wrote this message on Wed, Mar 26, 2014 at
  12:17 +0100:
   On Tue, Mar 25, 2014 at 09:43:16AM -0700, John-Mark Gurney
   wrote:
Willy Offermans wrote this message on Tue, Mar 25, 2014
at 11:39 +0100:
 I'm not an expert in tcpdump. Can anyone make sense out
 of the messages?

If you dumped the contents, using -s 0 -X, and look at
that last packet
you should see 0d 0a 2e 0d 0a at the end..  which is
CR/LF/./CR/LF.. If
you don't see that, then for some reason sendmail/FreeBSD
isn't telling
the server that it's done sending which would prevent the
receiving
side from ack'ing the email causing the timeout...
   
   I followed your suggestions. However I'm not able to
   distinguish the last
   packet. Is there a way to find this with help of the Flags?
   The following
   is the output of tcpdump -r /root/tmp/tcpdump -X | grep
   Flags
   
   11:57:56.539788 IP MyServer.com.41115  Smarthost.com.smtp:
   Flags [S], seq 1001452351, win 65535, options [mss
   1448,nop,wscale 6,sackOK,TS val 407239960 ecr 0], length 0
   11:57:56.555262 IP Smarthost.com.smtp  MyServer.com.41115:
   Flags [S.], seq 1277075046, ack 1001452352, win 8192,
   options [mss 1452], length 0
  
  It should look something like:
  09:18:34.723280 IP jmgmac.funkthat.com.64724 
  h2.funkthat.com.ssh: Flags [.], ack 177, win 33280, options
  [nop,nop,TS val 1854905469 ecr 3482476972], length 0
  0x:  4510 0034 d7ac 4000 4006 e1af c0a8 0003
   E..4..@.@...
  0x0010:  c0a8 0004 fcd4 0016 7e48 238e d872 43dc
   ~H#..rC.
  0x0020:  8010 8200 7c08  0101 080a 6e8f 9c7d
   |...n..}
  0x0030:  cf92 61ac
 ..a.
  
  Notice the hex output...  I didn't see any of that in your
  output...
  The last packet I was talking about is the last one that had
  length
  1448 that your server sent...
 
 I sent two e-mails consecutively: the first without an
 attachment, the
 second with attachment. I dumped tcp of the NIC for port smtp.
 I got the
 following:
 
 
 12:20:55.988622 IP MyServer.com.37191  Smarthost.com.smtp:
 Flags [P.], seq 18943:19104, ack 412, win 65535, length 161
 0x:  4500 00c9 eebd 4000 4006  c0a8 0004
  E.@.@...
 0x0010:  d54b 3f0d 9147 0019 4ea0 36dd 15a7 38a0
  .K?..G..N.6...8.
 0x0020:  5018  4481  2020 2020 2020 2020
  P...D...
 0x0030:  2020 2020 2020 2020 2020 2020 2020 2020
  
 0x0040:  2020 2020 2020 2020 2020 2020 2020 205c
  ...\
 0x0050:  2f20 205c 205e 0d0a 2020 2020 2020 2020
  /..\.^..
 0x0060:  2020 2020 2020 2020 2020 2020 2020 2020
  
 0x0070:  2020 2020 2020 2020 2020 2020 2020 2020
  
 0x0080:  2020 202e 5c2e 5f2f 5f29 0d0a 0d0a 2020
  \._/_)..
 0x0090:  2020 2020 2020 2020 2020 2020 2020 2020
  
 0x00a0:  2020 2020 2020 2020 2020 2020 2020 2020
  
 0x00b0:  2020 2020 2077  2e46 7265 6542 5344
  .www.FreeBSD
 0x00c0:  2e6f 7267 0d0a 2e0d 0a
   .org.
 
 As predicted by John-Mark, the first ended with 0d0a 2e0d 0a.
 However it
 was not the last packet with length 1448. I hope that this will
 not spoil
 the party. Is the Flag [P.] more indicative? It looks like to
 me, but I'm
 just learning.
 
 Anyway the second mail ended with:
 
 12:22:17.960896 IP MyServer.com.37191  Smarthost.com.smtp:
 Flags [.], seq 35127:36575, ack 638, win 65535, length 1448
 0x:  4500 05d0 fe9d 4000 4006  c0a8 0004
  E.@.@...
 snip
 /snip
 0x0560:  5670 6876 4a67 5a5a 5a50 4b2f 4b78 3774
  VphvJgZZZPK/Kx7t
 0x0570:  382f 4230 594f 6b78 3449 0d0a 4a76 6551
  8/B0YOkx4I..JveQ
 0x0580:

Re: sendmail Broken Pipe Error

2014-03-30 Thread Allan Jude 
On 2014-03-30 15:31, Willy Offermans wrote:
 Hello Rick and FreeBSD friends,
 
 On Fri, Mar 28, 2014 at 06:25:23PM -0400, Rick Macklem wrote:
 John-Mark Gurney wrote:
 Willy Offermans wrote this message on Thu, Mar 27, 2014 at 15:46
 +0100:
 Hello John-Mark and FreeBSD friends,

 On Wed, Mar 26, 2014 at 04:04:27PM -0700, John-Mark Gurney wrote:
 Willy Offermans wrote this message on Wed, Mar 26, 2014 at 18:22
 +0100:
 Hello John-Mark and FreeBSD friends,

 On Wed, Mar 26, 2014 at 09:20:35AM -0700, John-Mark Gurney
 wrote:
 Willy Offermans wrote this message on Wed, Mar 26, 2014 at
 12:17 +0100:
 On Tue, Mar 25, 2014 at 09:43:16AM -0700, John-Mark Gurney
 wrote:
 Willy Offermans wrote this message on Tue, Mar 25, 2014
 at 11:39 +0100:
 I'm not an expert in tcpdump. Can anyone make sense out
 of the messages?

 If you dumped the contents, using -s 0 -X, and look at
 that last packet
 you should see 0d 0a 2e 0d 0a at the end..  which is
 CR/LF/./CR/LF.. If
 you don't see that, then for some reason sendmail/FreeBSD
 isn't telling
 the server that it's done sending which would prevent the
 receiving
 side from ack'ing the email causing the timeout...

 I followed your suggestions. However I'm not able to
 distinguish the last
 packet. Is there a way to find this with help of the Flags?
 The following
 is the output of tcpdump -r /root/tmp/tcpdump -X | grep
 Flags

 11:57:56.539788 IP MyServer.com.41115  Smarthost.com.smtp:
 Flags [S], seq 1001452351, win 65535, options [mss
 1448,nop,wscale 6,sackOK,TS val 407239960 ecr 0], length 0
 11:57:56.555262 IP Smarthost.com.smtp  MyServer.com.41115:
 Flags [S.], seq 1277075046, ack 1001452352, win 8192,
 options [mss 1452], length 0

 It should look something like:
 09:18:34.723280 IP jmgmac.funkthat.com.64724 
 h2.funkthat.com.ssh: Flags [.], ack 177, win 33280, options
 [nop,nop,TS val 1854905469 ecr 3482476972], length 0
 0x:  4510 0034 d7ac 4000 4006 e1af c0a8 0003
  E..4..@.@...
 0x0010:  c0a8 0004 fcd4 0016 7e48 238e d872 43dc
  ~H#..rC.
 0x0020:  8010 8200 7c08  0101 080a 6e8f 9c7d
  |...n..}
 0x0030:  cf92 61ac
..a.

 Notice the hex output...  I didn't see any of that in your
 output...
 The last packet I was talking about is the last one that had
 length
 1448 that your server sent...

 I sent two e-mails consecutively: the first without an
 attachment, the
 second with attachment. I dumped tcp of the NIC for port smtp.
 I got the
 following:


 12:20:55.988622 IP MyServer.com.37191  Smarthost.com.smtp:
 Flags [P.], seq 18943:19104, ack 412, win 65535, length 161
 0x:  4500 00c9 eebd 4000 4006  c0a8 0004
  E.@.@...
 0x0010:  d54b 3f0d 9147 0019 4ea0 36dd 15a7 38a0
  .K?..G..N.6...8.
 0x0020:  5018  4481  2020 2020 2020 2020
  P...D...
 0x0030:  2020 2020 2020 2020 2020 2020 2020 2020
  
 0x0040:  2020 2020 2020 2020 2020 2020 2020 205c
  ...\
 0x0050:  2f20 205c 205e 0d0a 2020 2020 2020 2020
  /..\.^..
 0x0060:  2020 2020 2020 2020 2020 2020 2020 2020
  
 0x0070:  2020 2020 2020 2020 2020 2020 2020 2020
  
 0x0080:  2020 202e 5c2e 5f2f 5f29 0d0a 0d0a 2020
  \._/_)..
 0x0090:  2020 2020 2020 2020 2020 2020 2020 2020
  
 0x00a0:  2020 2020 2020 2020 2020 2020 2020 2020
  
 0x00b0:  2020 2020 2077  2e46 7265 6542 5344
  .www.FreeBSD
 0x00c0:  2e6f 7267 0d0a 2e0d 0a
   .org.

 As predicted by John-Mark, the first ended with 0d0a 2e0d 0a.
 However it
 was not the last packet with length 1448. I hope that this will
 not spoil
 the party. Is the Flag [P.] more indicative? It looks like to
 me, but I'm
 just learning.

 Anyway the second mail ended with:

 12:22:17.960896 IP MyServer.com.37191  Smarthost.com.smtp:
 Flags [.], seq 35127:36575, ack 638, win 65535, length 1448
 0x:  4500 05d0 fe9d 4000 4006  c0a8 0004
  E.@.@...
 snip
 /snip
 0x0560:  5670 6876 4a67 5a5a 5a50 4b2f 4b78 3774
  VphvJgZZZPK/Kx7t
 0x0570:  382f 4230 594f 6b78 3449 0d0a 4a76 6551
  8/B0YOkx4I..JveQ
 0x0580:  2b6e 7765 5647 2f33 6e79 6231 6133 496f
  +nweVG/3nyb1a3Io
 0x0590:  5474 554f 4d61 4374 696b 714b 436b 4959
  TtUOMaCtikqKCkIY
 0x05a0:  704a 7668 3055 416d 6c33 4754 4f4c 6455
  pJvh0UAml3GTOLdU
 0x05b0:  774b 4145 7151 5741 7841 4141 5a66 7647
  wKAEqQWAxAAAZfvG
 0x05c0:  706b 6c36 0d0a 7a4e 6234 745a 6633 5a6c
  pkl6..zNb4tZf3Zl

 Being packet with length 1448 and sent from my side. The code
 0d0a 2e0d
 0a is missing. Immediately thereafter the

Re: [CFT] ASLR and PIE on amd64

2014-03-30 Thread Oliver Pinter 
On 3/22/14, Shawn Webb latt...@gmail.com wrote:
 Hey All,

 First off, I hope that even as a non-committer, it's okay that I post
 a call for testing. If not, please excuse my newbishness in this
 process. This is my first time submitting a major patch upstream to
 FreeBSD.

 Over the past few months, I've had the opportunity and pleasure to
 enhance existing patches to FreeBSD that implement a common exploit
 mitigation technology called Address Space Layout Randomization (ASLR)
 along with support for Position Independent Executables (PIE).
 ASLR+PIE has been a long-requested feature by many people I've met on
 IRC.

 I've submitted my patch to PR kernel/181497. I'm currently in the
 process of adding PIE support to certain high-visibility applications
 in base (mainly network daemons). I've added a make.conf knob that's
 default to enabled (WITH_PIE=1). An application has to also explicitly
 support PIE as well by defining CAN_PIE in the Makefile prior to
 including bsd.prog.mk. After I get a decent amount of applications
 enabled with PIE support, I'll submit one last patch.

 The following sysctl's can be set with a kernel compiled with the
 PAX_ASLR option:

 security.pax.aslr.status: 1
 security.pax.aslr.debug: 0
 security.pax.aslr.mmap_len: 16
 security.pax.aslr.stack_len: 12
 security.pax.aslr.exec_len: 12

 The security.pax.aslr.status sysctl enables and disables the ASLR
 system as a whole. The debug sysctl gives debugging output. The
 mmap_len sysctl tells the ASLR system how many bits to randomize with
 mmap() is called. The stack_len sysctl tells the ASLR system how many
 bits to randomize in the stack. The exec_len sysctl tells the ASLR
 system how many bits to randomize the execbase (this controls PIE).
 These sysctls can be set as a per-jail basis. If you have an
 application which doesn't support ASLR, yet you want ASLR enabled for
 everything else, you can simply place that misbehaving application in
 a jail with only that jail's ASLR settings turned off.

 Please let me know how your testing goes. I'm giving a presentation at
 BSDCan regarding this.

 If you want to keep tabs on my bleeding-edge development process,
 please follow my progress on GitHub:
 https://github.com/lattera/freebsd (branch: soldierx/lattera/aslr).

 Thank you very much,

Hi!

Please apply this patch. This fixed an issue with tunables.


 Shawn Webb
 ___
 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



0001-PaX-ASLR-fixed-tunables-in-kern_pax.c.patch
Description: Binary data
___
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: [CFT] ASLR and PIE on amd64

2014-03-30 Thread Shawn Webb 
On Mar 31, 2014 02:07 AM +0200, Oliver Pinter wrote:
 On 3/22/14, Shawn Webb latt...@gmail.com wrote:
  Hey All,
 
  First off, I hope that even as a non-committer, it's okay that I post
  a call for testing. If not, please excuse my newbishness in this
  process. This is my first time submitting a major patch upstream to
  FreeBSD.
 
  Over the past few months, I've had the opportunity and pleasure to
  enhance existing patches to FreeBSD that implement a common exploit
  mitigation technology called Address Space Layout Randomization (ASLR)
  along with support for Position Independent Executables (PIE).
  ASLR+PIE has been a long-requested feature by many people I've met on
  IRC.
 
  I've submitted my patch to PR kernel/181497. I'm currently in the
  process of adding PIE support to certain high-visibility applications
  in base (mainly network daemons). I've added a make.conf knob that's
  default to enabled (WITH_PIE=1). An application has to also explicitly
  support PIE as well by defining CAN_PIE in the Makefile prior to
  including bsd.prog.mk. After I get a decent amount of applications
  enabled with PIE support, I'll submit one last patch.
 
  The following sysctl's can be set with a kernel compiled with the
  PAX_ASLR option:
 
  security.pax.aslr.status: 1
  security.pax.aslr.debug: 0
  security.pax.aslr.mmap_len: 16
  security.pax.aslr.stack_len: 12
  security.pax.aslr.exec_len: 12
 
  The security.pax.aslr.status sysctl enables and disables the ASLR
  system as a whole. The debug sysctl gives debugging output. The
  mmap_len sysctl tells the ASLR system how many bits to randomize with
  mmap() is called. The stack_len sysctl tells the ASLR system how many
  bits to randomize in the stack. The exec_len sysctl tells the ASLR
  system how many bits to randomize the execbase (this controls PIE).
  These sysctls can be set as a per-jail basis. If you have an
  application which doesn't support ASLR, yet you want ASLR enabled for
  everything else, you can simply place that misbehaving application in
  a jail with only that jail's ASLR settings turned off.
 
  Please let me know how your testing goes. I'm giving a presentation at
  BSDCan regarding this.
 
  If you want to keep tabs on my bleeding-edge development process,
  please follow my progress on GitHub:
  https://github.com/lattera/freebsd (branch: soldierx/lattera/aslr).
 
  Thank you very much,
 
 Hi!
 
 Please apply this patch. This fixed an issue with tunables.

Patch merged successfully into my GitHub repo. Fixed with commit
d2c0813. I'll include it in my next patch submission upstream when I
submit my PIE work. Thanks!


pgpcK7WD3olj8.pgp
Description: PGP signature