Re: Chicken and egg, encrypted root FS on remote server
On Wed, Feb 20, 2013 at 07:58:10AM +0100, Paul Schenkeveld wrote: Hi, I've been trying to find a solution for this chicken and egg problem, how to have an encrypted root filesystem on a remote server. Geli can ask for a root password at the console to unlock the root fs but that of course won't work for a remote server. Ideally I'd like the server to start, do minimal network config, run a minimal ssh client (dropbear?) and wait for someone to log in, provide the passphrase to unlock the root filesystem and then mount the root filesystem and do a normal startup. I read about a pivotroot call in other OS-es, that would allow for a very small unencrypted root filesystem to be mounted temporarily until the passphrase has been entered and then swap that for a real, encrypted root filesystem. But AFAIK we don't have pivotroot. The problem could also be solved if the real root fs could be union mounted over the small unencrypted one but unionfs won't mount over /. Why is it that I cannot union mount anything over /, is there a technical reason for that or is it because of security concerns? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Chicken and egg, encrypted root FS on remote server
Geli can ask for a root password at the console to unlock the root fs but that of course won't work for a remote server. Ideally I'd like the server to start, do minimal network config, run a minimal ssh client (dropbear?) and wait for someone to log in, provide the passphrase to unlock the root filesystem and then mount the root filesystem and do a normal startup. I read about a pivotroot call in other OS-es, that would allow for a too much complexity. just make simple small partition with OS installed, and just sshd and maybe few (not requiring security) things services running, then log in, geli attach main partition, fsck and mount and then run other services. make script for it. that's all ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Chicken and egg, encrypted root FS on remote server
On 20 Feb 2013, at 08:46, Paul Schenkeveld free...@psconsult.nl wrote: On Wed, Feb 20, 2013 at 02:42:57AM -0500, Jason Hellenthal wrote: Just a thought with no working example but… bootp / tftp - from a remote secured management frame to TX a key filesytem to unlock your rootfs. Could be something as simple as a remote wireless adhoc server with a 64GB thumbdrive to hold your data or just enough to tell the system where to get it. Considering a key can be any length string of a sort just to say but... Serve the rootfs key directly from a TXT out of a secured DNS zone only visible to so said machines. Thank you but manual entry of the passprase is a prerequisite here so serving the key automatically is not an option. With kind regards, Paul Schenkeveld What about getting a remote console like HP's ILO or Dell's DRAC ? You get to login remotely, you can use some degree of access control... you can even remote boot. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
gpart autofill
On target provider I had 20971440 free sectors, each of 512 B. That would be 10485720 kB, for a last slice. This number is valid, as it is splitable with 63, 8, 4 and 2, without any residue. So, upon attempt to add that slice, I get: -- gpart: autofill: No space left on device -- Tried both '-s 10485720k' and '-s 20971440' Finally, ommiting -s flag, just to see what gpart wants to do, worked. It added slice by leaving last 63 sectors free. Those were supposed to be a part of a slice. I.e; If provider had 20971455 free sectors, then slice would be 20971440 of sector size and last 15 sectors would be left free. Domagoj Smolčić ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Chicken and egg, encrypted root FS on remote server
On Wed, Feb 20, 2013 at 09:47:36AM +0100, Damien Fleuriot wrote: On 20 Feb 2013, at 08:46, Paul Schenkeveld free...@psconsult.nl wrote: On Wed, Feb 20, 2013 at 02:42:57AM -0500, Jason Hellenthal wrote: Just a thought with no working example but⦠bootp / tftp - from a remote secured management frame to TX a key filesytem to unlock your rootfs. Could be something as simple as a remote wireless adhoc server with a 64GB thumbdrive to hold your data or just enough to tell the system where to get it. Considering a key can be any length string of a sort just to say but... Serve the rootfs key directly from a TXT out of a secured DNS zone only visible to so said machines. Thank you but manual entry of the passprase is a prerequisite here so serving the key automatically is not an option. With kind regards, Paul Schenkeveld What about getting a remote console like HP's ILO or Dell's DRAC ? You get to login remotely, you can use some degree of access control... you can even remote boot. For new hardware I could indeed use this, the current hardware does not support remote console. I don't have experience with ILO nor DRAC but I do have experience with SuperMicro's KVM over LAN which does need a java client to run. If I can enter the passphrase over ssh that would be better as I can use any device including a smartphone to dial in and enter the passphrase. Thanks! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Chicken and egg, encrypted root FS on remote server
On 20/02/2013, at 21:43, Paul Schenkeveld free...@psconsult.nl wrote: What about getting a remote console like HP's ILO or Dell's DRAC ? You get to login remotely, you can use some degree of access control... you can even remote boot. For new hardware I could indeed use this, the current hardware does not support remote console. I don't have experience with ILO nor DRAC but I do have experience with SuperMicro's KVM over LAN which does need a java client to run. If I can enter the passphrase over ssh that would be better as I can use any device including a smartphone to dial in and enter the passphrase. If you setup a serial console you don't need Java if you use ipmitool, eg ipmitool -H remoteip -U ADMIN -I lanplus sol activate The way IPMI graphical console stuff _stinks_ - I spent several hours trying to help a customer and I was stymied at every level trying to work out how to use SSH port forwarding to have the console Java client connect to the remote server (for example, it ignores system wide SOCKS proxy settings). In the end I used tun forwarding which was just stupid - it really is written assuming everyone uses a VPN. There is no logic behind the use of the VNC protocol but bastardised enough that normal clients can connect. /rant That inspired me to send a longer rant to Supermicro about it, maybe nothing will come of it but I feel better ;) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
[patch] Wine DLL base address patches
Hi Wine needs some of its libraries to be loaded at specific base addresses (https://wiki.freebsd.org/Wine), something FreeBSD currently lacks. I've written a patch to the dynamic loader (/libexec/ld-elf.so.1) that loads libraries at their preferred base addresses (http://www.freebsd.org/cgi/query-pr.cgi?pr=176216), as well as a port of Prelink to FreeBSD which Wine uses to set base addresses (http://www.freebsd.org/cgi/query-pr.cgi?pr=176283). Both work :-), the changed dynamic loader doesn't show any problems in a few days of testing, and prelink works with the --reloc-only option as used by Wine. Please review/test/comment/commit. Thank you Damjan Jovanovic ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [patch] Wine DLL base address patches
On Wed, Feb 20, 2013 at 05:29:01PM +0200, Damjan Jovanovic wrote: Hi Wine needs some of its libraries to be loaded at specific base addresses (https://wiki.freebsd.org/Wine), something FreeBSD currently lacks. I've written a patch to the dynamic loader (/libexec/ld-elf.so.1) that loads libraries at their preferred base addresses (http://www.freebsd.org/cgi/query-pr.cgi?pr=176216), as well as a port of Prelink to FreeBSD which Wine uses to set base addresses (http://www.freebsd.org/cgi/query-pr.cgi?pr=176283). Both work :-), the changed dynamic loader doesn't show any problems in a few days of testing, and prelink works with the --reloc-only option as used by Wine. Please review/test/comment/commit. Unfortunately, it is not safe. MAP_FIXED overrides any previous mappings which could exist at the specified address. What you could do, is - either specify the desired base without MAP_FIXED. Kernel takes the base as the hint, but only uses it if the request completely fits into the hinted area without overriding any existing mapping. Also, the heap is explicitely avoided. The code would need to check if kernel honored hint by comparing the actual map address with the desired address, and act accordingly. - or add a new mmap(2) flag, which would specify that mapping should be done at that address, if possible to not overlap with existing mapping, otherwise the mapping should fail. pgpTmtvgtVj_B.pgp Description: PGP signature
Re: Looking for reviewers for patch that adds foreign disk support mfiutil
On Tuesday, February 19, 2013 6:49:52 pm Steven Hartland wrote:
- Original Message -
From: John Baldwin
Thanks for the feedback John appreciated, a couple of questions inline
below if you would be so kind.
Certainly.
- Is dump_config() really the right choice for 'foreign config'? It doesn't
attempt to output things very pretty, and I think mfiutil's non-debug
commands should aim to be human readable.
Will check this, just didn't want to re-invent the wheel ;-)
Heh, can you reuse the show_config code instead perhaps? It might be useful if
you could provide an example of the current 'foreign config' output?
- This (human readable) is also why it doesn't include the opcode in the
error
message by default. Sysadmins don't really care which opcode fails. Maybe
put that under '#ifdef DEBUG'?
Previously there was no information about what command failed, which made
the failure message kinda useless, so while debugging I added the opcode
to help me trace things.
In general my goal had been to make the caller provide that level of detail if
it is useful. While developing a command it can indeed be useful which is why
I suggested moving it under #ifdef DEBUG. This provides the extra detail while
working on a command while keeping the UI for users clean. If it is under DEBUG
you can just print the raw opcode in hex as you are doing now.
- mfireg.h should be kept in sync with the driver's version of that header,
so
don't reorder the enum's unless you are changing it to match what is in the
device driver's mfireg.h. In fact, mfiutil should probably be using the
mfireg.h from sys/dev/mfi directly now that it is in the tree. (mfiutil
was originally developed outside of the tree as a standalone app)
There is only one mfireg.h and that is already in sys/dev/mfi :)
Oh, bah. I misread the diff. Reordering the commands looks good to me in that
case.
- Please don't do assignments in declarations and leave a blank line between
declarations and the bode of code. Thus:
mfi_op_desc(...)
{
int i, num_ops;
num_ops = nitems(mfi_op_codes);
...
(nitems() is nice to use when it is available as well)
Changed, this the case for constant initialisers too? e.g. is the
following incorrect or acceptable?
myfunc(...)
{
int i = 0, j = 1;
...
style(9) forbids those as well (and I generally avoid them myself), but you
will find code in the tree that does use initializers for simple expressions.
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: libprocstat(3): retrieve process command line args and environment
On Tuesday, February 12, 2013 4:50:54 pm Mikolaj Golub wrote: On Fri, Jan 25, 2013 at 03:31:43PM -0500, John Baldwin wrote: BTW, one off-ball thought I have is that I would like to have a mode where libprocstat operates on a core file (of a process, not a kernel crash dump), so it could list the threads from a core dump, and possibly file descriptor info (if PR kern/173723 is implemented). We certainly could have a 'raw' mode where it spat out name: value or XML of the entire kinfo_proc perhaps. It looks very interesting! Do you mean something like this? Yes, exactly like this! Very nice indeed. root@lisa:/root # sh -c 'kill -5 $$' Trace/BPT trap (core dumped) root@lisa:/root # ls -l sh.core -rw--- 1 root wheel 8790016 Feb 12 21:17 sh.core root@lisa:/root # procstat sh.core PID PPID PGID SID TSID THR LOGINWCHAN EMUL COMM 674 657 674 657 657 1 root - FreeBSD ELF32 sh root@lisa:/root # procstat -f sh.core PID COMM FD T V FLAGS REF OFFSET PRO NAME 674 sh text v r r - - - /bin/sh 674 sh ctty v c rw--- - - - /dev/pts/0 674 shcwd v d r - - - /root 674 sh root v d r - - - / 674 sh 0 v c rw--- 82537 - /dev/pts/0 674 sh 1 v c rw--- 82537 - /dev/pts/0 674 sh 2 v c rw--- 82537 - /dev/pts/0 root@lisa:/root # procstat -v sh.core PID STARTEND PRT RES PRES REF SHD FL TP PATH 674 0x8048000 0x8064000 r-x 280 1 0 CN-- vn /bin/sh 674 0x8064000 0x8066000 rw-20 1 0 df 674 0x28064000 0x2807a000 r-x 220 17 0 CN-- vn /libexec/ld-elf.so.1 674 0x2807a000 0x28083000 rw-90 1 0 df 674 0x28084000 0x280a3000 r-x 31 32 2 1 CN-- vn /lib/libedit.so.7 674 0x280a3000 0x280a5000 rw-20 1 0 C--- vn /lib/libedit.so.7 674 0x280a5000 0x280a7000 rw-00 0 0 -- 674 0x280a7000 0x280e r-x 570 4 2 CN-- vn /lib/libncurses.so.8 674 0x280e 0x280e3000 rw-30 1 0 C--- vn /lib/libncurses.so.8 674 0x280e3000 0x28213000 r-x 3040 34 17 CN-- vn /lib/libc.so.7 674 0x28213000 0x2821a000 rw-70 1 0 C--- vn /lib/libc.so.7 674 0x2821a000 0x28243000 rw- 160 2 0 df 674 0x2840 0x28c0 rw- 240 2 0 df 674 0xbfbdf000 0xbfbff000 rwx30 1 0 ---D df 674 0xbfbff000 0xbfc0 r-x00 20 0 CN-- ph Here is my attempt to implement it: http://people.freebsd.org/~trociny/procstat_core.1.patch The patch needs much work yet, especially the userland part, but looks like it is good enough for demonstration purposes to discuss how this should be done properly. So, procstat data is stored in a core as note sections with name FreeBSD and types NT_PROCSTAT_PROC, NT_PROCSTAT_FILES, ... The current format of notes is a header of sizeof(int) and data in the format as it is returned by a related sysctl call. I think the header should provide some versioning and for the cases I implemented (kinfo_proc, kinfo_file, kinfo_vmentry) it contains a value of the corresponding kinfo struct size (e.g. KINFO_VMENTRY_SIZE). It might be not the best solution and I would be glad for suggestions. I think including the size is good and is probably sufficient for versioning. (BTW, why don't we have constants like KINFO_VMENTRY_SIZE defined for all archs?) I cannot speak to that. To avoid code duplication I changed the code of kinfo sysctl handlers to output kinfo data to sbuf instead of calling SYSCTL_OUT directly so these functions could be used by both sysctl handlers and the coredump routine. Ok. Another thing I am not sure about is writing procstat data in the coredump routine. The coredump routine on the first pass calculates core sizes and on the second pass does actual writing. I added procstat in that way that procstat data is collected on the first run to internal buffers and on the second pass is copied from the buffers to the core. I could do this another way, e.g running kern_proc_*out() twice, on the fist pass with tiny buffer and a drain routine that would calculate data length, but this looks less efficient, complicates things and currently I am not sure that procstat sizes are not changeable between the passes. The issue with my approach I see is that after the first pass, before actually doing allocations we check corefile limits. I do allocations before checking the limit, so potentially using some kernel space when it might not be allowed by limits. Is this a problem I should worry and try another approach? The process should be
SA-13:02/libc and FreeBSD 6
All I was wondering if anyone knows, off hand if SA-13:02/libc applies to FreeBSD 6-STABLE and if it would be committed to the 6-STABLE branch ? -- mark saad | nones...@longcount.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: SA-13:02/libc and FreeBSD 6
http://www.freebsd.org/security/#sup 6 has been EOL for a looong time. So hmmm, guessing you won't see a patch. On Feb 20, 2013, at 6:29 PM, Mark Saad nones...@longcount.org wrote: All I was wondering if anyone knows, off hand if SA-13:02/libc applies to FreeBSD 6-STABLE and if it would be committed to the 6-STABLE branch ? -- mark saad | nones...@longcount.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: SA-13:02/libc and FreeBSD 6
I am aware its EOL'd but there are still a number of us stuck with 6-STABLE . On Wed, Feb 20, 2013 at 12:31 PM, Fleuriot Damien m...@my.gd wrote: http://www.freebsd.org/security/#sup 6 has been EOL for a looong time. So hmmm, guessing you won't see a patch. On Feb 20, 2013, at 6:29 PM, Mark Saad nones...@longcount.org wrote: All I was wondering if anyone knows, off hand if SA-13:02/libc applies to FreeBSD 6-STABLE and if it would be committed to the 6-STABLE branch ? -- mark saad | nones...@longcount.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org -- mark saad | nones...@longcount.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: SA-13:02/libc and FreeBSD 6
My point was, unless someone ports the patch back to 6 , if 6 is indeed affected, I think you're out of luck. I hope you get your answer and, possibly, a patch. On Feb 20, 2013, at 6:32 PM, Mark Saad nones...@longcount.org wrote: I am aware its EOL'd but there are still a number of us stuck with 6-STABLE . On Wed, Feb 20, 2013 at 12:31 PM, Fleuriot Damien m...@my.gd wrote: http://www.freebsd.org/security/#sup 6 has been EOL for a looong time. So hmmm, guessing you won't see a patch. On Feb 20, 2013, at 6:29 PM, Mark Saad nones...@longcount.org wrote: All I was wondering if anyone knows, off hand if SA-13:02/libc applies to FreeBSD 6-STABLE and if it would be committed to the 6-STABLE branch ? -- mark saad | nones...@longcount.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org -- mark saad | nones...@longcount.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: SA-13:02/libc and FreeBSD 6
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 02/20/13 09:29, Mark Saad wrote:
All I was wondering if anyone knows, off hand if SA-13:02/libc
applies to FreeBSD 6-STABLE and if it would be committed to the
6-STABLE branch ?
The patch itself won't apply, there were many changes after the last
6-STABLE branch.
Here is a patch backported for stable/6 but I do not have time to set
up a testing environment for it, if you do, please let me know if the
patch worked or not, thanks!
Cheers,
- --
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-BEGIN PGP SIGNATURE-
iQEcBAEBCgAGBQJRJRanAAoJEG80Jeu8UPuzyf0H/AyoNHoCSoXxTRl4tu0NOFsR
lZ/5O7h+YMK6LejwQxEfbb9vnNkRYmP5FtM4Ja7cQjqvFM24tL4RXtoazdYQcgid
/X+ExMIghF+/5fbEDt8x03lKQB8G5Ua3HTIqQfZoM5LREdzlXsyxREep4VspgT+y
GTofcvwReT7LJZyYqeYmLq+tJLOy/gWkl95MJPz/0E58+H/xqCwTEol8vDhUqTYh
WuBfRzNpY2OLnc5RStKZ+Vj+vkNIFHeHrOmwcYby+MGYl8V89pb+MjKP/mEITxcv
8NF8Ti52yY8ZtG7aS8tvAoY6qeAqWknv1yiHg+IZrgvtkXSBefExUSCAzS2z1G8=
=m/h0
-END PGP SIGNATURE-
diff --git a/lib/libc/gen/glob.c b/lib/libc/gen/glob.c
index 8e5ee69..5549311 100644
--- a/lib/libc/gen/glob.c
+++ b/lib/libc/gen/glob.c
@@ -93,6 +93,25 @@ __FBSDID($FreeBSD$);
#include collate.h
+/*
+ * glob(3) expansion limits. Stop the expansion if any of these limits
+ * is reached. This caps the runtime in the face of DoS attacks. See
+ * also CVE-2010-2632
+ */
+#defineGLOB_LIMIT_BRACE128 /* number of brace calls */
+#defineGLOB_LIMIT_PATH 65536 /* number of path elements */
+#defineGLOB_LIMIT_READDIR 16384 /* number of readdirs */
+#defineGLOB_LIMIT_STAT 1024/* number of stat system calls
*/
+#defineGLOB_LIMIT_STRING ARG_MAX /* maximum total size for paths
*/
+
+struct glob_limit {
+ size_t l_brace_cnt;
+ size_t l_path_lim;
+ size_t l_readdir_cnt;
+ size_t l_stat_cnt;
+ size_t l_string_cnt;
+};
+
#defineDOLLAR '$'
#defineDOT '.'
#defineEOS '\0'
@@ -144,7 +163,7 @@ typedef char Char;
static int compare(const void *, const void *);
-static int g_Ctoc(const Char *, char *, u_int);
+static int g_Ctoc(const Char *, char *, size_t);
static int g_lstat(Char *, struct stat *, glob_t *);
static DIR *g_opendir(Char *, glob_t *);
static Char*g_strchr(Char *, wchar_t);
@@ -152,34 +171,34 @@ static Char *g_strchr(Char *, wchar_t);
static Char*g_strcat(Char *, const Char *);
#endif
static int g_stat(Char *, struct stat *, glob_t *);
-static int glob0(const Char *, glob_t *, int *);
-static int glob1(Char *, glob_t *, int *);
-static int glob2(Char *, Char *, Char *, Char *, glob_t *, int *);
-static int glob3(Char *, Char *, Char *, Char *, Char *, glob_t *, int *);
-static int globextend(const Char *, glob_t *, int *);
-static const Char *
+static int glob0(const Char *, glob_t *, struct glob_limit *);
+static int glob1(Char *, glob_t *, struct glob_limit *);
+static int glob2(Char *, Char *, Char *, Char *, glob_t *,
+struct glob_limit *);
+static int glob3(Char *, Char *, Char *, Char *, Char *, glob_t *,
+struct glob_limit *);
+static int globextend(const Char *, glob_t *, struct glob_limit *);
+static const Char *
globtilde(const Char *, Char *, size_t, glob_t *);
-static int globexp1(const Char *, glob_t *, int *);
-static int globexp2(const Char *, const Char *, glob_t *, int *, int *);
+static int globexp1(const Char *, glob_t *, struct glob_limit *);
+static int globexp2(const Char *, const Char *, glob_t *, int *,
+struct glob_limit *);
static int match(Char *, Char *, Char *);
#ifdef DEBUG
static void qprintf(const char *, Char *);
#endif
int
-glob(pattern, flags, errfunc, pglob)
- const char *pattern;
- int flags, (*errfunc)(const char *, int);
- glob_t *pglob;
+glob(const char *pattern, int flags, int (*errfunc)(const char *, int), glob_t
*pglob)
{
- const u_char *patnext;
- int limit;
+ struct glob_limit limit = { 0, 0, 0, 0, 0 };
+ const char *patnext;
Char *bufnext, *bufend, patbuf[MAXPATHLEN], prot;
mbstate_t mbs;
wchar_t wc;
size_t clen;
- patnext = (u_char *) pattern;
+ patnext = pattern;
if (!(flags GLOB_APPEND)) {
pglob-gl_pathc = 0;
pglob-gl_pathv = NULL;
@@ -187,11 +206,10 @@ glob(pattern, flags, errfunc, pglob)
pglob-gl_offs = 0;
}
if (flags GLOB_LIMIT) {
- limit = pglob-gl_matchc;
- if (limit == 0)
- limit = ARG_MAX;
- } else
- limit = 0;
+ limit.l_path_lim = pglob-gl_matchc;
+ if (limit.l_path_lim == 0)
+
Re: libprocstat(3): retrieve process command line args and environment
On Wed, Feb 20, 2013 at 09:04:14AM -0500, John Baldwin wrote: The process should be stopped by the time we dump a core, so running it multiple times should be ok in that the sizes should not change. I would say that you should try to implement a determine sizes pass that doesn't allocate anything, but others should comment on that. I had a little talk with kib about this recently. Kib's main concern looked to be that a process with many threads/open files might require considerable amount of kernel memory if the procstat notes are prepared in memory before writing. So currently I am working on another approach, when on the first pass the sizes are found, and on the second pass procstat notes are written to coredump without preliminarily storing all notes in memory buffer. Hope, the code won't look very ugly... One other thing to consider is if gcore needs to be updated to output these records as well. It could use the sysctls to fetch the data and then write out appropriate notes I think, so perhaps it wouldn't be too difficult to add this as a followup commit once the kernel version has settled and the file format is set? Looks like very interesting idea! Thank you for all your comments and suggestions. -- Mikolaj Golub ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: SA-13:02/libc and FreeBSD 6
Xin I am rebuilding now, I'll let you know how it works. On Wed, Feb 20, 2013 at 1:32 PM, Xin Li delp...@delphij.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/20/13 09:29, Mark Saad wrote: All I was wondering if anyone knows, off hand if SA-13:02/libc applies to FreeBSD 6-STABLE and if it would be committed to the 6-STABLE branch ? The patch itself won't apply, there were many changes after the last 6-STABLE branch. Here is a patch backported for stable/6 but I do not have time to set up a testing environment for it, if you do, please let me know if the patch worked or not, thanks! Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJRJRanAAoJEG80Jeu8UPuzyf0H/AyoNHoCSoXxTRl4tu0NOFsR lZ/5O7h+YMK6LejwQxEfbb9vnNkRYmP5FtM4Ja7cQjqvFM24tL4RXtoazdYQcgid /X+ExMIghF+/5fbEDt8x03lKQB8G5Ua3HTIqQfZoM5LREdzlXsyxREep4VspgT+y GTofcvwReT7LJZyYqeYmLq+tJLOy/gWkl95MJPz/0E58+H/xqCwTEol8vDhUqTYh WuBfRzNpY2OLnc5RStKZ+Vj+vkNIFHeHrOmwcYby+MGYl8V89pb+MjKP/mEITxcv 8NF8Ti52yY8ZtG7aS8tvAoY6qeAqWknv1yiHg+IZrgvtkXSBefExUSCAzS2z1G8= =m/h0 -END PGP SIGNATURE- -- mark saad | nones...@longcount.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
IPMI console [Re: Chicken and egg, encrypted root FS on remote server]
Hi Daniel, On Wed, Feb 20, 2013 at 10:55:47PM +1030, Daniel O'Connor wrote: On 20/02/2013, at 21:43, Paul Schenkeveld free...@psconsult.nl wrote: What about getting a remote console like HP's ILO or Dell's DRAC ? You get to login remotely, you can use some degree of access control... you can even remote boot. For new hardware I could indeed use this, the current hardware does not support remote console. I don't have experience with ILO nor DRAC but I do have experience with SuperMicro's KVM over LAN which does need a java client to run. If I can enter the passphrase over ssh that would be better as I can use any device including a smartphone to dial in and enter the passphrase. If you setup a serial console you don't need Java if you use ipmitool, eg ipmitool -H remoteip -U ADMIN -I lanplus sol activate Tried that with some Supermicro servers, the serial console allows me to get into BIOS config and shows boot messages up to starting the kernel, once the kernel starts output stops. In the BIOS setup, console redirect defaults to com2 port which explains why output stops after the loader passes control to the kernel. BTW, ipmitool always gives me Info: cannot activate SOL payload with encryption but ipmi-console (sysutils/freeipmi) works. If I change the console redirect to com1, my screen stays blank. Would you perhaps know how to use com1 for redirect and connect to it using ipmi-console (or ipmi-tool)? Thanks, Paul Schenkeveld ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [patch] Wine DLL base address patches
On 20-02-2013 16:48, Konstantin Belousov wrote:
On Wed, Feb 20, 2013 at 05:29:01PM +0200, Damjan Jovanovic wrote:
Hi
Wine needs some of its libraries to be loaded at specific base
addresses (https://wiki.freebsd.org/Wine), something FreeBSD currently
lacks.
I've written a patch to the dynamic loader (/libexec/ld-elf.so.1) that
loads libraries at their preferred base addresses
(http://www.freebsd.org/cgi/query-pr.cgi?pr=176216), as well as a port
of Prelink to FreeBSD which Wine uses to set base addresses
(http://www.freebsd.org/cgi/query-pr.cgi?pr=176283). Both work :-),
the changed dynamic loader doesn't show any problems in a few days of
testing, and prelink works with the --reloc-only option as used by
Wine.
Please review/test/comment/commit.
Unfortunately, it is not safe. MAP_FIXED overrides any previous mappings
which could exist at the specified address.
I've simplified the rtld patch to a single line. The second patch makes
Wine use -Ttext-segment linker flag instead of prelink. This requires
binutils from ports, but it's easier than porting prelink.
Index: libexec/rtld-elf/map_object.c
===
--- libexec/rtld-elf/map_object.c (revision 246986)
+++ libexec/rtld-elf/map_object.c (working copy)
@@ -175,7 +175,7 @@ map_object(int fd, const char *path, const struct
base_vaddr = trunc_page(segs[0]-p_vaddr);
base_vlimit = round_page(segs[nsegs]-p_vaddr + segs[nsegs]-p_memsz);
mapsize = base_vlimit - base_vaddr;
-base_addr = hdr-e_type == ET_EXEC ? (caddr_t) base_vaddr : NULL;
+base_addr = (caddr_t) base_vaddr;
mapbase = mmap(base_addr, mapsize, PROT_NONE, MAP_ANON | MAP_PRIVATE |
MAP_NOCORE, -1, 0);
Index: Makefile
===
--- Makefile(revision 312556)
+++ Makefile(working copy)
@@ -28,7 +28,7 @@
LATEST_LINK= wine-devel
CPPFLAGS+= -I${LOCALBASE}/include
LDFLAGS+= -L${LOCALBASE}/lib
-USE_GCC= any
+USE_GCC= 4.7
GNU_CONFIGURE= yes
CONFIGURE_ARGS+=--verbose --disable-tests \
--without-alsa --without-capi --without-dbus \
Index: files/patch-tools-winegcc-utils.h
===
--- files/patch-tools-winegcc-utils.h (revision 0)
+++ files/patch-tools-winegcc-utils.h (working copy)
@@ -0,0 +1,12 @@
+--- tools/winegcc/utils.h.orig
tools/winegcc/utils.h
+@@ -42,7 +42,8 @@
+
+ enum target_platform
+ {
+-PLATFORM_UNSPECIFIED, PLATFORM_APPLE, PLATFORM_SOLARIS, PLATFORM_WINDOWS,
PLATFORM_CYGWIN
++PLATFORM_UNSPECIFIED, PLATFORM_APPLE, PLATFORM_FREEBSD, PLATFORM_SOLARIS,
++PLATFORM_WINDOWS, PLATFORM_CYGWIN
+ };
+
+ void error(const char* s, ...) DECLSPEC_NORETURN;
Index: files/patch-tools-winegcc-winegcc.c
===
--- files/patch-tools-winegcc-winegcc.c (revision 0)
+++ files/patch-tools-winegcc-winegcc.c (working copy)
@@ -0,0 +1,32 @@
+--- tools/winegcc/winegcc.c.orig
tools/winegcc/winegcc.c
+@@ -172,6 +172,7 @@
+ {
+ { macos, PLATFORM_APPLE },
+ { darwin, PLATFORM_APPLE },
++{ freebsd, PLATFORM_FREEBSD },
+ { solaris, PLATFORM_SOLARIS },
+ { cygwin, PLATFORM_CYGWIN },
+ { mingw32, PLATFORM_WINDOWS },
+@@ -232,6 +233,8 @@
+
+ #ifdef __APPLE__
+ static enum target_platform build_platform = PLATFORM_APPLE;
++#elif defined(__FreeBSD__)
++static enum target_platform build_platform = PLATFORM_FREEBSD;
+ #elif defined(__sun)
+ static enum target_platform build_platform = PLATFORM_SOLARIS;
+ #elif defined(__CYGWIN__)
+@@ -1020,6 +1023,12 @@
+ if (opts-strip)
+ strarray_add(link_args, -Wl,-x);
+ break;
++case PLATFORM_FREEBSD:
++if (opts-image_base)
++{
++strarray_add(link_args, strmake(-Wl,-Ttext-segment=%s,
opts-image_base));
++}
++break;
+ case PLATFORM_SOLARIS:
+ {
+ char *mapfile = get_temp_file( output_name, .map );
signature.asc
Description: OpenPGP digital signature
Re: [patch] Wine DLL base address patches
On Wed, Feb 20, 2013 at 09:51:37PM +0100, Tijl Coosemans wrote:
On 20-02-2013 16:48, Konstantin Belousov wrote:
On Wed, Feb 20, 2013 at 05:29:01PM +0200, Damjan Jovanovic wrote:
Hi
Wine needs some of its libraries to be loaded at specific base
addresses (https://wiki.freebsd.org/Wine), something FreeBSD currently
lacks.
I've written a patch to the dynamic loader (/libexec/ld-elf.so.1) that
loads libraries at their preferred base addresses
(http://www.freebsd.org/cgi/query-pr.cgi?pr=176216), as well as a port
of Prelink to FreeBSD which Wine uses to set base addresses
(http://www.freebsd.org/cgi/query-pr.cgi?pr=176283). Both work :-),
the changed dynamic loader doesn't show any problems in a few days of
testing, and prelink works with the --reloc-only option as used by
Wine.
Please review/test/comment/commit.
Unfortunately, it is not safe. MAP_FIXED overrides any previous mappings
which could exist at the specified address.
I've simplified the rtld patch to a single line. The second patch makes
Wine use -Ttext-segment linker flag instead of prelink. This requires
binutils from ports, but it's easier than porting prelink.
Index: libexec/rtld-elf/map_object.c
===
--- libexec/rtld-elf/map_object.c (revision 246986)
+++ libexec/rtld-elf/map_object.c (working copy)
@@ -175,7 +175,7 @@ map_object(int fd, const char *path, const struct
base_vaddr = trunc_page(segs[0]-p_vaddr);
base_vlimit = round_page(segs[nsegs]-p_vaddr + segs[nsegs]-p_memsz);
mapsize = base_vlimit - base_vaddr;
-base_addr = hdr-e_type == ET_EXEC ? (caddr_t) base_vaddr : NULL;
+base_addr = (caddr_t) base_vaddr;
mapbase = mmap(base_addr, mapsize, PROT_NONE, MAP_ANON | MAP_PRIVATE |
MAP_NOCORE, -1, 0);
If this is enough for wine, I definitely have no objection. The typical
dso has zero virtual base for the first segment, so the patch should change
nothing for dso built without special map file.
Index: Makefile
===
--- Makefile (revision 312556)
+++ Makefile (working copy)
@@ -28,7 +28,7 @@
LATEST_LINK= wine-devel
CPPFLAGS+= -I${LOCALBASE}/include
LDFLAGS+=-L${LOCALBASE}/lib
-USE_GCC= any
+USE_GCC= 4.7
GNU_CONFIGURE= yes
CONFIGURE_ARGS+=--verbose --disable-tests \
--without-alsa --without-capi --without-dbus \
Index: files/patch-tools-winegcc-utils.h
===
--- files/patch-tools-winegcc-utils.h (revision 0)
+++ files/patch-tools-winegcc-utils.h (working copy)
@@ -0,0 +1,12 @@
+--- tools/winegcc/utils.h.orig
tools/winegcc/utils.h
+@@ -42,7 +42,8 @@
+
+ enum target_platform
+ {
+-PLATFORM_UNSPECIFIED, PLATFORM_APPLE, PLATFORM_SOLARIS,
PLATFORM_WINDOWS, PLATFORM_CYGWIN
++PLATFORM_UNSPECIFIED, PLATFORM_APPLE, PLATFORM_FREEBSD,
PLATFORM_SOLARIS,
++PLATFORM_WINDOWS, PLATFORM_CYGWIN
+ };
+
+ void error(const char* s, ...) DECLSPEC_NORETURN;
Index: files/patch-tools-winegcc-winegcc.c
===
--- files/patch-tools-winegcc-winegcc.c (revision 0)
+++ files/patch-tools-winegcc-winegcc.c (working copy)
@@ -0,0 +1,32 @@
+--- tools/winegcc/winegcc.c.orig
tools/winegcc/winegcc.c
+@@ -172,6 +172,7 @@
+ {
+ { macos, PLATFORM_APPLE },
+ { darwin, PLATFORM_APPLE },
++{ freebsd, PLATFORM_FREEBSD },
+ { solaris, PLATFORM_SOLARIS },
+ { cygwin, PLATFORM_CYGWIN },
+ { mingw32, PLATFORM_WINDOWS },
+@@ -232,6 +233,8 @@
+
+ #ifdef __APPLE__
+ static enum target_platform build_platform = PLATFORM_APPLE;
++#elif defined(__FreeBSD__)
++static enum target_platform build_platform = PLATFORM_FREEBSD;
+ #elif defined(__sun)
+ static enum target_platform build_platform = PLATFORM_SOLARIS;
+ #elif defined(__CYGWIN__)
+@@ -1020,6 +1023,12 @@
+ if (opts-strip)
+ strarray_add(link_args, -Wl,-x);
+ break;
++case PLATFORM_FREEBSD:
++if (opts-image_base)
++{
++strarray_add(link_args, strmake(-Wl,-Ttext-segment=%s,
opts-image_base));
++}
++break;
+ case PLATFORM_SOLARIS:
+ {
+ char *mapfile = get_temp_file( output_name, .map );
pgpAviZFPInSj.pgp
Description: PGP signature
Re: IPMI console [Re: Chicken and egg, encrypted root FS on remote server]
On 20/02/2013 20:31, Paul Schenkeveld wrote: Hi Daniel, On Wed, Feb 20, 2013 at 10:55:47PM +1030, Daniel O'Connor wrote: On 20/02/2013, at 21:43, Paul Schenkeveld free...@psconsult.nl wrote: What about getting a remote console like HP's ILO or Dell's DRAC ? You get to login remotely, you can use some degree of access control... you can even remote boot. For new hardware I could indeed use this, the current hardware does not support remote console. I don't have experience with ILO nor DRAC but I do have experience with SuperMicro's KVM over LAN which does need a java client to run. If I can enter the passphrase over ssh that would be better as I can use any device including a smartphone to dial in and enter the passphrase. If you setup a serial console you don't need Java if you use ipmitool, eg ipmitool -H remoteip -U ADMIN -I lanplus sol activate Tried that with some Supermicro servers, the serial console allows me to get into BIOS config and shows boot messages up to starting the kernel, once the kernel starts output stops. In the BIOS setup, console redirect defaults to com2 port which explains why output stops after the loader passes control to the kernel. BTW, ipmitool always gives me Info: cannot activate SOL payload with encryption but ipmi-console (sysutils/freeipmi) works. If I change the console redirect to com1, my screen stays blank. Would you perhaps know how to use com1 for redirect and connect to it using ipmi-console (or ipmi-tool)? I have a supermicro using ipmi sol running happily using com2 my notes were ahem,less than through however hopefully they are enough? (FreeBSD 9.1-RELEASE) For Serial over lan (ipmi) edit /boot.config to contain -Dh edit /boot/loader.conf to add ipmi_load=YES hint.uart.0.flags= hint.uart.1.flags=0x10 console=comconsole vidconsole comconsole_speed=19200 boot_multicons=yes edit /etc/ttys change line for ttyu1 ttyu1 /usr/libexec/getty std.19200 vt100 on secure -- root@kyanite london]# ipmitool -I lanplus -U admin -E -H 192.168.22.118 sol activate Unable to read password from environment Password: [SOL Session operational. Use ~? for help] FreeBSD/amd64 (copia.namesco.net) (ttyu1) login: Hope thats helpful Vince Thanks, Paul Schenkeveld ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: IPMI console [Re: Chicken and egg, encrypted root FS on remote server]
- Original Message - From: Paul Schenkeveld free...@psconsult.nl To: Daniel O'Connor docon...@gsoft.com.au Cc: hack...@freebsd.org Sent: Wednesday, February 20, 2013 8:31 PM Subject: IPMI console [Re: Chicken and egg, encrypted root FS on remote server] Hi Daniel, On Wed, Feb 20, 2013 at 10:55:47PM +1030, Daniel O'Connor wrote: On 20/02/2013, at 21:43, Paul Schenkeveld free...@psconsult.nl wrote: What about getting a remote console like HP's ILO or Dell's DRAC ? You get to login remotely, you can use some degree of access control... you can even remote boot. For new hardware I could indeed use this, the current hardware does not support remote console. I don't have experience with ILO nor DRAC but I do have experience with SuperMicro's KVM over LAN which does need a java client to run. If I can enter the passphrase over ssh that would be better as I can use any device including a smartphone to dial in and enter the passphrase. If you setup a serial console you don't need Java if you use ipmitool, eg ipmitool -H remoteip -U ADMIN -I lanplus sol activate Tried that with some Supermicro servers, the serial console allows me to get into BIOS config and shows boot messages up to starting the kernel, once the kernel starts output stops. In the BIOS setup, console redirect defaults to com2 port which explains why output stops after the loader passes control to the kernel. BTW, ipmitool always gives me Info: cannot activate SOL payload with encryption but ipmi-console (sysutils/freeipmi) works. If I change the console redirect to com1, my screen stays blank. Would you perhaps know how to use com1 for redirect and connect to it using ipmi-console (or ipmi-tool)? We use the following on Supermicro servers works fine:- http://blog.multiplay.co.uk/2012/12/freebsd-serial-over-lan/ Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [patch] Wine DLL base address patches
On Wed, Feb 20, 2013 at 10:51 PM, Tijl Coosemans t...@coosemans.org wrote: On 20-02-2013 16:48, Konstantin Belousov wrote: On Wed, Feb 20, 2013 at 05:29:01PM +0200, Damjan Jovanovic wrote: Hi Wine needs some of its libraries to be loaded at specific base addresses (https://wiki.freebsd.org/Wine), something FreeBSD currently lacks. I've written a patch to the dynamic loader (/libexec/ld-elf.so.1) that loads libraries at their preferred base addresses (http://www.freebsd.org/cgi/query-pr.cgi?pr=176216), as well as a port of Prelink to FreeBSD which Wine uses to set base addresses (http://www.freebsd.org/cgi/query-pr.cgi?pr=176283). Both work :-), the changed dynamic loader doesn't show any problems in a few days of testing, and prelink works with the --reloc-only option as used by Wine. Please review/test/comment/commit. Unfortunately, it is not safe. MAP_FIXED overrides any previous mappings which could exist at the specified address. I've simplified the rtld patch to a single line. The second patch makes Wine use -Ttext-segment linker flag instead of prelink. This requires binutils from ports, but it's easier than porting prelink. All of that occurred to me as well. The problem with that one-line rtld patch is that loading an application will now fail if any of its libraries cannot be loaded at their requested address. The problem with -Ttext-segment (and isn't it just -Ttext?) is that it doesn't seem to work: the base_vaddr seen by rtld will remain 0, and the address listed in /proc/.../map is different from what it should be. Also run readelf -l on a library compiled that way and compare with the output of one run through prelink --reloc-only, you'll see the lowest VirtAddr and PhysAddr in LOAD headers change only with prelink. I really ported prelink because there was no other choice. See my attached test cases, and examine the contents of /proc/.../map while they run. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: SA-13:02/libc and FreeBSD 6
On 20 February 2013 12:01, Mark Saad nones...@longcount.org wrote: Xin I am rebuilding now, I'll let you know how it works. As I've said before, if someone wants to take ownership of 6.x and backport changes / push them into STABLE_6, be my guest. Yahoo was doing that for some unsupported old releases for a while. They'd still stay unsupported.. well, as long as there's not a big group of 6.x users standing up and taking ownership. (Same can be said of what's going to happen to 7.x soon.) Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: IPMI console [Re: Chicken and egg, encrypted root FS on remote server]
On 21/02/2013, at 9:06, Steven Hartland kill...@multiplay.co.uk wrote: If I change the console redirect to com1, my screen stays blank. Would you perhaps know how to use com1 for redirect and connect to it using ipmi-console (or ipmi-tool)? We use the following on Supermicro servers works fine:- http://blog.multiplay.co.uk/2012/12/freebsd-serial-over-lan/ Nice! BTW do you know what flag 0x20 does for UART? 0x10 is documented but 0x20 is not. I had a quick look at the code and AFAIK it doesn't do anything (on 9.1 anyway). Actually at a guess I would say it's a hangover from sio(4) where 0x20 forced the device in question to be the console. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
