Re: ifconfig accepting hostname as ipv4 address

2012-06-08 Thread Jonathan McKeown
On Thursday 07 June 2012 17:00:04 Alexander V. Chernikov wrote:
> Hello list!
>
> Since the early days ifconfig(8) has the following functionality:

[hostname in place of literal address]

> Moreover, ifconfig em0 some_valid_fqdn/MASK silently ignores it, so you
> can't set valid CIDR address using this notation.

I'm not sure that's true. Have you tried it? Because it seems to work here.

Jonathan
___
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: ifconfig accepting hostname as ipv4 address

2012-06-08 Thread Alexander V. Chernikov

On 08.06.2012 11:20, Jonathan McKeown wrote:

On Thursday 07 June 2012 17:00:04 Alexander V. Chernikov wrote:

Hello list!

Since the early days ifconfig(8) has the following functionality:


[hostname in place of literal address]


Moreover, ifconfig em0 some_valid_fqdn/MASK silently ignores it, so you
can't set valid CIDR address using this notation.


I'm not sure that's true. Have you tried it? Because it seems to work here.
Strangely enough, it works on another machine. Ok, this one works and 
can unfortunately be used by other people.


However, original question remains.



Jonathan



___
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: ifconfig accepting hostname as ipv4 address

2012-06-08 Thread Jonathan McKeown
On Friday 08 June 2012 09:43:25 Alexander V. Chernikov wrote:
> On 08.06.2012 11:20, Jonathan McKeown wrote:
> > On Thursday 07 June 2012 17:00:04 Alexander V. Chernikov wrote:
> >> Hello list!
> >>
> >> Since the early days ifconfig(8) has the following functionality:
> >
> > [hostname in place of literal address]
> >
> >> Moreover, ifconfig em0 some_valid_fqdn/MASK silently ignores it, so you
> >> can't set valid CIDR address using this notation.
> >
> > I'm not sure that's true. Have you tried it? Because it seems to work
> > here.
>
> Strangely enough, it works on another machine. Ok, this one works and
> can unfortunately be used by other people.
>
> However, original question remains.

So your question is, do we want to keep the behaviour of being able to 
configure an interface by hostname as well as by IP address?

My vote is yes. Sure, a typo in the parameters to ifconfig can cause problems 
under some circumstances. So can a typo in any command. I don't think that's 
a good enough reason to remove functionality you regard as ``unfortunate''. 
We find it useful, and a significant aid to maintainability and readability 
of configuration files.
___
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"


[Phrack Mag.] The false kingdom of jemalloc, or On exploiting the jemalloc memory manager

2012-06-08 Thread Oliver Pinter
An analysis of jemalloc - founded in phrack magazine.

--[ Table of contents

1 - Introduction
  1.1 - Thousand-faced jemalloc
2 - jemalloc memory allocator overview
  2.1 - Basic structures
2.1.1 - Chunks (arena_chunk_t)
2.1.2 - Arenas (arena_t)
2.1.3 - Runs (arena_run_t)
2.1.4 - Regions/Allocations
2.1.5 - Bins (arena_bin_t)
2.1.6 - Huge allocations
2.1.7 - Thread caches (tcache_t)
2.1.8 - Unmask jemalloc
  2.2 - Algorithms
3 - Exploitation tactics
  3.1 - Adjacent region corruption
  3.2 - Heap manipulation
  3.3 - Metadata corruption
3.3.1 - Run (arena_run_t)
3.3.2 - Chunk (arena_chunk_t)
3.3.3 - Thread caches (tcache_t)
4 - A real vulnerability
5 - Future work
6 - Conclusion
7 - References
8 - Code

[...]

"--[ 6 - Conclusion

We have done the first step in analyzing jemalloc. We do know, however,
that we have not covered every possible potential of corrupting the
allocator in a controllable way. We hope to have helped those that were
about to study the FreeBSD userspace allocator or the internals of Firefox
but wanted to have a first insight before doing so. Any reader that
discovers mistakes in our article is advised to contact us as soon as
possible and let us know.

Many thanks to the Phrack staff for their comments. Also, thanks to George
Argyros for reviewing this work and making insightful suggestions.

Finally, we would like to express our respect to Jason Evans for such a
leet allocator. No, that isn't ironic; jemalloc is, in our opinion, one of
the best (if not the best) allocators out there.
"

http://www.phrack.org/archives/68/p68_0x0a_Pseudomonarchia%20jemallocum_by_argp%20&%20huku.txt

http://www.phrack.org/archives/68/p68_0x0d_The%20Art%20of%20Exploitation:%20Exploiting%20VLC,%20a%20jemalloc%20case%20study_by_huku%20&%20argp.txt
___
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: boot menu option to disable graphics mode

2012-06-08 Thread Aled Morris
On 7 June 2012 16:12, Garrett Cooper  wrote:

> I've run into _multiple_ scenarios where this isn't possible because
> the terminal settings are screwed up in single user mode, and had to
> resort to `sed -i '' `.
>
>
ed is the standard text editor

Aled
___
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: CD bootcode

2012-06-08 Thread rank1seeker
- Original Message -
From: John Baldwin 
To: rank1see...@gmail.com
Cc: hack...@freebsd.org
Date: Thu, 7 Jun 2012 11:16:33 -0400
Subject: Re: CD bootcode

> On Thursday, June 07, 2012 9:58:25 am rank1see...@gmail.com wrote:
> > - Original Message -
> > From: John Baldwin 
> > To: freebsd-hackers@freebsd.org
> > Cc: rank1see...@gmail.com
> > Date: Thu, 7 Jun 2012 08:21:39 -0400
> > Subject: Re: CD bootcode

> > But even when loader is finally started, loader handles symlinks on UFS 
> > (kicked by '/boot/boot'), BUT fails so, on Rock-Ridge iso (kicked by 
> '/boot/cdboot')
> > Looks like loader must be made into looking at Rock-Ridge extensions.
> 
> It is src/lib/libstand/cd9660.c that would have to be patched.  It already has
> limited Rock-Ridge support, so adding symlink support to cd9660_open() may not
> be that hard to do.
> 
> -- 
> John Baldwin


Problem should be solved in 2 groups/steps.

First
-
stage 2 boot '/boot/boot' AND '/boot/cdboot' shouldn't be made into working 
with symlinks.
Just leave them, the way they are. First one can be navigated to loader via 
'boot.config' file.
So only '/boot/cdboot' should be edited, to react to the same 'boot.config' 
file as '/boot/boot' does.
Simply because they both target 'loader', 'boot.config' should work for both 
bootcodes.

Second
--
'loader' should be edited, to work with Rock-Ridge extensions.


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: ifconfig accepting hostname as ipv4 address

2012-06-08 Thread Thomas Rasmussen

On 08.06.2012 11:04, Jonathan McKeown wrote:

We find it useful, and a significant aid to maintainability and readability
of configuration files.

Hello,

What happens if your server reboots while the DNS
server is down/unavailable ?

This seems to be a bad idea for the same reasons
that putting hostnames in firewall configs are a bad idea:

You want the system to boot and work correctly
regardless of whether the systems DNS servers
were responsive at boot time or not.

Best regards

Thomas Steen Rasmussen

___
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: CD bootcode

2012-06-08 Thread John Baldwin
On Friday, June 08, 2012 10:33:00 am rank1see...@gmail.com wrote:
> - Original Message -
> From: John Baldwin 
> To: rank1see...@gmail.com
> Cc: hack...@freebsd.org
> Date: Thu, 7 Jun 2012 11:16:33 -0400
> Subject: Re: CD bootcode
> 
> > On Thursday, June 07, 2012 9:58:25 am rank1see...@gmail.com wrote:
> > > - Original Message -
> > > From: John Baldwin 
> > > To: freebsd-hackers@freebsd.org
> > > Cc: rank1see...@gmail.com
> > > Date: Thu, 7 Jun 2012 08:21:39 -0400
> > > Subject: Re: CD bootcode
> 
> > > But even when loader is finally started, loader handles symlinks on UFS 
> > > (kicked by '/boot/boot'), BUT fails so, on Rock-Ridge iso (kicked by 
> > '/boot/cdboot')
> > > Looks like loader must be made into looking at Rock-Ridge extensions.
> > 
> > It is src/lib/libstand/cd9660.c that would have to be patched.  It already 
> > has
> > limited Rock-Ridge support, so adding symlink support to cd9660_open() may 
> > not
> > be that hard to do.
> > 
> > -- 
> > John Baldwin
> 
> 
> Problem should be solved in 2 groups/steps.
> 
> First
> -
> stage 2 boot '/boot/boot' AND '/boot/cdboot' shouldn't be made into working 
> with symlinks.
> Just leave them, the way they are. First one can be navigated to loader via 
> 'boot.config' file.
> So only '/boot/cdboot' should be edited, to react to the same 'boot.config' 
> file as '/boot/boot' does.
> Simply because they both target 'loader', 'boot.config' should work for both 
> bootcodes.

Adding /boot.config support to cdboot is non-trivial.  Also, cdboot is
intended for read-only media, so dynamic configuration via a file is not
quite as useful.

> Second
> --
> 'loader' should be edited, to work with Rock-Ridge extensions.

It already supports RR for names, it is merely symlink support that has to be
added.

-- 
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: CD bootcode

2012-06-08 Thread rank1seeker
> > First
> > -
> > stage 2 boot '/boot/boot' AND '/boot/cdboot' shouldn't be made into working 
> > with symlinks.
> > Just leave them, the way they are. First one can be navigated to loader via 
> > 'boot.config' file.
> > So only '/boot/cdboot' should be edited, to react to the same 'boot.config' 
> > file as '/boot/boot' does.
> > Simply because they both target 'loader', 'boot.config' should work for 
> > both bootcodes.
> 
> Adding /boot.config support to cdboot is non-trivial.  Also, cdboot is
> intended for read-only media, so dynamic configuration via a file is not
> quite as useful.

cdboot is a FreeBSD specific
Fact that it is intended for RO media is irrelevant here, as stage 2  boot can 
also reside on RO fs.

For cdboot, 'boot.config' file should give instructions of full path to loader, 
nothing else (no other, stage 2 boot's flags/functionality).
Hm, then again, if cdboot file would inherit just that 1 functionality, then it 
can't share same config file.
How about 'cdboot.config' file name?

Thanks to boot.config, I specify full path to loader, so '/boot/boot' isn't 
"halted" by symlink.
If cdboot would obey it in a same way, I wouldn't have to patch it, by adding 
third path.


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: nss compat shims

2012-06-08 Thread Michael Bushkov
I don't know for sure, but it seems that there was no need to support
anything besides groups and password when nss_compat.c was committed.
At that time, IIRC, the modules that we had in ports supported only
these databases.

--
Michael

On Thu, Jun 7, 2012 at 2:43 PM, Mel Flynn  wrote:
> Hi,
>
> I'm currently implementing support for more NSS databases in
> net/nss-pamd-ldapd and I've started to wonder why there's only the group
> and password support in lib/libc/net/nss_compat.c?
>
> Is there a specific reason for it or is this a classic case of "patches
> welcome"? I wasn't able to determine the reason from the commit log.
> --
> Mel
> ___
> 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: ifconfig accepting hostname as ipv4 address

2012-06-08 Thread David Brodbeck
On Fri, Jun 8, 2012 at 10:08 AM, Thomas Rasmussen  wrote:
> On 08.06.2012 11:04, Jonathan McKeown wrote:
>>
>> We find it useful, and a significant aid to maintainability and
>> readability
>> of configuration files.
>
> Hello,
>
> What happens if your server reboots while the DNS
> server is down/unavailable ?

Shouldn't this still work if the machine has its own hostname
associated with its IP in /etc/hosts?  Is that not still common
practice?

I can see the logic here.  By putting the IP in /etc/hosts and the
hostname in the ifconfig, you only have to edit the address in one
place if it ever changes.

This reminds me that the old (pre-NWAM) way to configure Solaris with
a static IP was to put the IP and hostname in /etc/hosts, the hostname
in /etc/hostname.e1000g0 (or whatever your interface name was), the
gateway address in /etc/defaultrouter, and the network address and
netmask in /etc/netmasks.


-- 
David Brodbeck
System Administrator, Linguistics
University of Washington
___
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: boot menu option to disable graphics mode

2012-06-08 Thread Jason Hellenthal


On Thu, Jun 07, 2012 at 01:06:09PM +0300, Andriy Gapon wrote:
> on 07/06/2012 12:57 Gleb Kurtsou said the following:
> > What do you think about adding generic support for overriding *_enable
> > options in rc.conf?
> > 
> > I'd like to be able to disable services at boot prompt, e.g.
> > # set rc.slim_enable="no" -- overrides slim_enable="yes" in rc.conf
> > 
> > Similarly rc.pf_enable="no"
> > 
> > Then introduce x_enable knob (=yes by default) to disable login
> > managers. User will be able to override this setting with
> > # service xdm forcestart
> 
> I think that this is an excellent idea.
> 

runlevel support might be a better solution so it does not differ that
much from what other systems do and would be easy for people to grasp.

-- 

 - (2^(N-1))
___
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: boot menu option to disable graphics mode

2012-06-08 Thread Andriy Gapon
on 09/06/2012 04:16 Jason Hellenthal said the following:
> runlevel support might be a better solution so it does not differ that
> much from what other systems do and would be easy for people to grasp.

Patches are welcome, as always.

-- 
Andriy Gapon
___
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"