FreeBSD IPSec adventures
Hello All. I have been working on a project where the goal has been to convert the FreeBSD IPSec stack to a userspace application. The project is pretty far along, so I thought I would dump my observations/experiences with regards the IPSec stack here. (Hopefully this is the correct forum) 1) SADB_X_SPDUPDATE (PFKEY call to update an existing Security Policy) I found that FreeBSD creates a new policy with a new unique Security Policy ID when performing an SP update. There appears to be no definitive RFC for this behaviour, I found this text in an IETF memo titled "MOBIKE Extensions for PF_KEY": " SADB_X_SPDUPDATE: If an existing SPD entry should be updated, the IKEv2 implementation sends a SADB_X_SPDUPDATE message to the kernel. This massage has the following format: The kernel responds with a message of the form: The meaning of the payloads is the same as for the SADB_X_SPDADD message. All the content of a SPD entry can be changed except the sadb_x_policy_id field and the source/destination addresses, which are the inner addresses in tunnel mode. However, the tunnel endpoint addresses, which only exist in tunnel mode, can be changed using a SADB_X_SPDUPDATE message. " I think that the approach of not modifying the policy ID is the more sensible; and as it turns out, was something that my work required. Does anyone know why FreeBSD takes this approach? 2) ESP + Authentication Crypto Performance I ran into some performance issues when using ESP with any authentication. The problem is that only one crypto device can be used for the ESP transform. This makes it impossible to use AESNI with ESP+auth with FreeBSD as it stands, which amounts to a major performance penalty. This looked tricky to resolve properly, as it seems to be an infrastructural problem. 3) SHA1 Performance I also had some problems with the opencrypto software SHA1 performance. By substituting the opencrypto sha1 call with an openssl library call the time to do a 1000B hash reduced to under half. Has anyone else noted SHA1 performance problems? Would be great to have some comments from FreeBSD gurus. Kind regards, David George ___ 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: gnome start error?help me.
I installed FreeBSD9.0 to IBM R51.Gnome startup black screen, only to restart.My graphics card is "82852/855GM Integrated Graphics Device".Is there any solution?Can you give me a detailed step? ? Thank you! same thing here. it is not video card dependent IMHO chao zhong li 2.12/5/13 ___ 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: csh builtin command problems
On Wed, 2012-05-09 at 21:34 -0400, Robert Simmons wrote: > I'm trying to use sysv style echo in /bin/csh and I've hit a wall as > to how to get it to work. > > The following does not have the outcome that I'm looking for: > > # echo_style=sysv > # echo test\ttest > test > # cat test > testttest > > I want this: > > # echo test\ttest > test > # cat test > testtest > > Any thoughts? What I see on 8.3 is this: % set echo_style=sysv % echo test\ttest testttest % echo "test\ttest" testtest % So it seems from this very minimal test that the implementation of echo is correct, but the parsing of the command line in csh requires that the \t in the arg be protected with quotes. (I don't normally spend any longer in csh than it takes for a .cshrc to launch bash, and even that's only on systems where I don't control /etc/passwd to just use bash directly.) -- Ian ___ 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: csh builtin command problems
On Mon, May 14, 2012 at 1:45 PM, Ian Lepore wrote: > On Wed, 2012-05-09 at 21:34 -0400, Robert Simmons wrote: >> I'm trying to use sysv style echo in /bin/csh and I've hit a wall as >> to how to get it to work. >> >> The following does not have the outcome that I'm looking for: >> >> # echo_style=sysv >> # echo test\ttest > test >> # cat test >> testttest >> >> I want this: >> >> # echo test\ttest > test >> # cat test >> test test >> >> Any thoughts? > > What I see on 8.3 is this: > > % set echo_style=sysv > % echo test\ttest > testttest > % echo "test\ttest" > test test > % > > So it seems from this very minimal test that the implementation of echo > is correct, but the parsing of the command line in csh requires that the > \t in the arg be protected with quotes. (I don't normally spend any > longer in csh than it takes for a .cshrc to launch bash, and even that's > only on systems where I don't control /etc/passwd to just use bash > directly.) Thanks. I should have tried double quotes. That works. ___ 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: GSoC Project: EFI on amd64/i386
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/10/12 07:45, Marcel Moolenaar wrote: > > On May 8, 2012, at 1:35 PM, Eric McCorkle wrote: > >> Here are some specific points to be decided: >> >> * An EFI boot service could potentially function similarly to >> [zfs]loader. Alternatively, it could function like >> gpt[zfs]boot, though this might require modifying loader(8) since >> EFI boot services run in protected/long mode, and have different >> system information table formats. It seems having the EFI boot service load the kernel directly is the way to go, based on Andrey's reply, the existing code, and my own intuition. I just wanted to ask, in case there was some compelling reason to have the EFI boot service load loader(8) instead. > Now, as for the FreeBSD boot loader: it's currently an EFI > program/image that can be run from within EFI and that uses the > boot- and runtime services to load the FreeBSD kernel from a file > system it knows about in some GPT partition. The loader is stored > in the EFI system partition so that it can be found and run. Sounds good. Also, Apple machines do things a bit differently, but it shouldn't be too much trouble to deal with. The Apple firmware looks for an HFS+ partition, and loads a specific file from it. A simple workaround is just to wrap the EFI boot program in an HFS+ filesystem. I have some half-finished code that does this on my hard drive. Also, the apple firmware starts in graphics (as opposed to text) mode. > >> * How much of what EFI provides do we want to use? There are >> advantages and disadvantages both ways. There are alot of features described in the EFI specification. It might be good to plan to use some of them, either now, or in the future. In particular, I noticed something about signing for boot services and drivers, which seems like it could be a great security feature (though not something I'd do this summer), though I haven't looked closely at it yet. On the other hand, I think it's a good idea to use libstand/libi386 whenever possible, even if it ends up calling through to EFI functions, as it keeps things standardized. >> * How much of the kernel needs to be changed to boot/run from an >> EFI boot? > > The hand-off will be different. In particular, a proper loader will > not load the kernel at some hardcoded address. Instead it will use > EFI's memory allocation routines to get available memory chunks and > load a kernel there. Since the kernel may not occupy a single > contiguous range in physical memory this way, you want the loader > to set up page tables as well. > > Put differently: the current state of affairs is that the EFI > loader we have loads a kernel, but can't boot it. Good to know. Here are some other questions/issues on my mind: If I understand things correctly, boot2 handles the switch to protected mode (as well as enabling A20), both loader(8) and the kernel begin their execution in a protected mode environment. Can I get an absolute confirmation on this? Obviously if this is not the case, then there will need to be another (protected mode) entry point into the kernel. I know some drivers rely on BIOS calls (vga, for instance, and I think some drivers for RAID cards do as well). These might (or might not) need to be modified. > You need to support both anyways. But not at the same time. The > machine either boots BIOS or EFI and depending on that will it use > the EFI loader or use the MBR to load boot code. There's nothing to > try. > > Key is to have a single kernel loadable and bootable by either the > EFI loader or using the "legacy" loader. Yes, I think it's prudent to make it possible for users to boot a given kernel with EFI or legacy BIOS, so that a bug doesn't leave early adopters "stuck" -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJPsXuEAAoJENSCzbQ+koZ7yaIP/1MGDIUCVN2HR9QOteKxg4U2 YeDZQ/C+s3xG5rnztfY5u5b5o9tEVoQJiBcvk+6+9JRW1cBhEUzAjgWnKDL5QMid RWql/rOPrg2jRhaRYQrh0dN9kkI0Dzdfm+N53Fmf0jat9fn11n5fYVzcA+WnFHTr eQ7IZNKGdJg7zzTC6+cDHz4wRjr+Lozp2Yk5hptsc4Xu3CkHus/7LRIoyfgEEc6r XwvjdBPYv9Jr6XirBFrZHjHNU/XvjUnD+bKyaEAhlUekLE/1J7Ge3oK0dqC3/zNh 5dP2ArQ0Xj91HzG2U8cDQs4SWp4AzIONygq5SdZeX+d78cpMJCzqzmxh3fdW2Aa9 oh40Aulqlj3BfeA7pak0Qe7SmDCi3OaZVI1z/HVbQD8utY4CxFmq7z6lnKBj6Y08 w9TyilE/px4AFy54nhjNke7eRfapu1g1Iz881oOHRtPcwecshTbjQWeBUQzc+3gV zE0L2NwUxUt5eWfw2jyC8bSK/mboMMBXpt4Zd4hBWjYKYcvbfaSSHS5Ys70Nlq30 GHjFphMz4MMpJbCO4ak/fMEJJPCDrDdoIT9QfUglyo3GjwI1BzUQF5iFoHFfqd/o hrcW+hgIVjb/qRT/Yr0qjEumoCnQLMHPcc8ylVVL1wt0qDyUL9XnjPiKRisQ4uqv lLNBhd+3V8SBV8V7sl0J =yyPA -END PGP SIGNATURE- ___ 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"
diagonising a overheating problem
I have a HP Pavilion g7-1365dx laptop that is constantly freezing up (doesn't respond to any key/mouse actions except the power switch) at random times the most reasonable explination I can think of is overheating and thus I have gotten one of those laptop mats that has a fan in it but to no avail (makes it less likely but now that stuff is heating up in late spring [I have no AC]) it is happening again... I use the machine for totally routine desktop stuff (surfing the web, watching flash movies and some lite java development) my guess is that for some reason the FreeBSD CPU/bus speed controls and such are not working based on the following item I found in my dmesg's: acpi_tz0: _CRT value is absurd, ignored (-273.2C) I have no other clues so far ___ 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: diagonising a overheating problem
Try sysctl dev.cpu.0.temperature. I have a notoriously overheating Dell laptop and for me, this sysctl always reports the temperature. - Bartosz ___ 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: diagonising a overheating problem
On Mon, May 14, 2012 at 6:37 PM, Bartosz Fabianowski wrote: > Try sysctl dev.cpu.0.temperature. I have a notoriously overheating Dell > laptop and for me, this sysctl always reports the temperature. > > - Bartosz ~/Desktop aryeh@localhost% sysctl dev.cpu.0.temperature sysctl: unknown oid 'dev.cpu.0.temperature' ~/Desktop aryeh@localhost% sysctl dev.cpu.0 dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.C000 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 1500 dev.cpu.0.freq_levels: 1500/7260 1400/6056 1225/5299 1200/5125 1100/4500 1000/4095 900/3753 800/3468 700/3034 600/2601 500/2167 400/1734 300/1300 200/867 100/433 dev.cpu.0.cx_supported: C1/0 C2/100 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% 0.00% last 233us ___ 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: diagonising a overheating problem
On Mon, May 14, 2012 at 06:56:47PM -0400, Aryeh Friedman wrote: > On Mon, May 14, 2012 at 6:37 PM, Bartosz Fabianowski > wrote: > > Try sysctl dev.cpu.0.temperature. I have a notoriously overheating Dell > > laptop and for me, this sysctl always reports the temperature. > > > > - Bartosz > > ~/Desktop aryeh@localhost% sysctl dev.cpu.0.temperature > sysctl: unknown oid 'dev.cpu.0.temperature' > ~/Desktop aryeh@localhost% sysctl dev.cpu.0 > dev.cpu.0.%desc: ACPI CPU > dev.cpu.0.%driver: cpu > dev.cpu.0.%location: handle=\_PR_.C000 > dev.cpu.0.%pnpinfo: _HID=none _UID=0 > dev.cpu.0.%parent: acpi0 > dev.cpu.0.freq: 1500 > dev.cpu.0.freq_levels: 1500/7260 1400/6056 1225/5299 1200/5125 > 1100/4500 1000/4095 900/3753 800/3468 700/3034 600/2601 500/2167 > 400/1734 300/1300 200/867 100/433 > dev.cpu.0.cx_supported: C1/0 C2/100 > dev.cpu.0.cx_lowest: C1 > dev.cpu.0.cx_usage: 100.00% 0.00% last 233us > ___ GEN8> sysctl hw.acpi.thermal hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 0 hw.acpi.thermal.tz0.temperature: 61.0C hw.acpi.thermal.tz0.active: 2 hw.acpi.thermal.tz0.passive_cooling: 1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 95.0C hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 105.0C hw.acpi.thermal.tz0._ACx: 75.0C 65.0C 50.0C 40.0C -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._TC1: 1 hw.acpi.thermal.tz0._TC2: 2 hw.acpi.thermal.tz0._TSP: 100 GEN8> See acpi_thermal(4) -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ 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: diagonising a overheating problem
On Mon, May 14, 2012 at 7:02 PM, Anton Shterenlikht wrote: > On Mon, May 14, 2012 at 06:56:47PM -0400, Aryeh Friedman wrote: >> On Mon, May 14, 2012 at 6:37 PM, Bartosz Fabianowski >> wrote: >> > Try sysctl dev.cpu.0.temperature. I have a notoriously overheating Dell >> > laptop and for me, this sysctl always reports the temperature. >> > >> > - Bartosz >> >> ~/Desktop aryeh@localhost% sysctl dev.cpu.0.temperature >> sysctl: unknown oid 'dev.cpu.0.temperature' >> ~/Desktop aryeh@localhost% sysctl dev.cpu.0 >> dev.cpu.0.%desc: ACPI CPU >> dev.cpu.0.%driver: cpu >> dev.cpu.0.%location: handle=\_PR_.C000 >> dev.cpu.0.%pnpinfo: _HID=none _UID=0 >> dev.cpu.0.%parent: acpi0 >> dev.cpu.0.freq: 1500 >> dev.cpu.0.freq_levels: 1500/7260 1400/6056 1225/5299 1200/5125 >> 1100/4500 1000/4095 900/3753 800/3468 700/3034 600/2601 500/2167 >> 400/1734 300/1300 200/867 100/433 >> dev.cpu.0.cx_supported: C1/0 C2/100 >> dev.cpu.0.cx_lowest: C1 >> dev.cpu.0.cx_usage: 100.00% 0.00% last 233us >> ___ > > GEN8> sysctl hw.acpi.thermal > hw.acpi.thermal.min_runtime: 0 > hw.acpi.thermal.polling_rate: 10 > hw.acpi.thermal.user_override: 0 > hw.acpi.thermal.tz0.temperature: 61.0C > hw.acpi.thermal.tz0.active: 2 > hw.acpi.thermal.tz0.passive_cooling: 1 > hw.acpi.thermal.tz0.thermal_flags: 0 > hw.acpi.thermal.tz0._PSV: 95.0C > hw.acpi.thermal.tz0._HOT: -1 > hw.acpi.thermal.tz0._CRT: 105.0C > hw.acpi.thermal.tz0._ACx: 75.0C 65.0C 50.0C 40.0C -1 -1 -1 -1 -1 -1 > hw.acpi.thermal.tz0._TC1: 1 > hw.acpi.thermal.tz0._TC2: 2 > hw.acpi.thermal.tz0._TSP: 100 > GEN8> > > See acpi_thermal(4) > hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 0 hw.acpi.thermal.tz0.temperature: 94.0C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.passive_cooling: 1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 95.0C hw.acpi.thermal.tz0._HOT: 105.0C hw.acpi.thermal.tz0._CRT: -1 hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._TC1: 2 hw.acpi.thermal.tz0._TC2: 3 hw.acpi.thermal.tz0._TSP: 30 ___ 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: diagonising a overheating problem
On Mon, 2012-05-14 at 18:56 -0400, Aryeh Friedman wrote: > On Mon, May 14, 2012 at 6:37 PM, Bartosz Fabianowski > wrote: > > Try sysctl dev.cpu.0.temperature. I have a notoriously overheating Dell > > laptop and for me, this sysctl always reports the temperature. > > > > - Bartosz > > ~/Desktop aryeh@localhost% sysctl dev.cpu.0.temperature > sysctl: unknown oid 'dev.cpu.0.temperature' > ~/Desktop aryeh@localhost% sysctl dev.cpu.0 > dev.cpu.0.%desc: ACPI CPU > dev.cpu.0.%driver: cpu > dev.cpu.0.%location: handle=\_PR_.C000 > dev.cpu.0.%pnpinfo: _HID=none _UID=0 > dev.cpu.0.%parent: acpi0 > dev.cpu.0.freq: 1500 > dev.cpu.0.freq_levels: 1500/7260 1400/6056 1225/5299 1200/5125 > 1100/4500 1000/4095 900/3753 800/3468 700/3034 600/2601 500/2167 > 400/1734 300/1300 200/867 100/433 > dev.cpu.0.cx_supported: C1/0 C2/100 > dev.cpu.0.cx_lowest: C1 > dev.cpu.0.cx_usage: 100.00% 0.00% last 233us dev.cpu.0.temperature is provided by the coretemp(4) driver, maybe you need to kldload it? -- Ian ___ 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: diagonising a overheating problem
> > dev.cpu.0.temperature is provided by the coretemp(4) driver, maybe you > need to kldload it? > > -- Ian > > Added coretemp and still no sysctl of that name ___ 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: diagonising a overheating problem
On Mon, May 14, 2012 at 05:19:26PM -0600 I heard the voice of Ian Lepore, and lo! it spake thus: > > dev.cpu.0.temperature is provided by the coretemp(4) driver, maybe > you need to kldload it? A quick Google suggests that model (g7-1365dx) is an AMD Llano proc, so I doubt "coretemp — device driver for Intel Core on-die digital thermal sensor" is going to he much help 8-} amdtemp(4) would be the possible choice. But I don't know whether it can handle Llano. >From the specs, it looks like it has a discrete graphics card as well as the integrated too. Since I'm pretty sure that combo isn't supported (and you're probably just running VESA anyway), the discrete is dead weight, and if it doesn't turn itself flat off (I don't know if it does or not), it may be contributing to heat problems. -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ 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"
