Re: Processor cores not properly detected/activated?
On Fri, May 23, 2014 at 8:42 PM, Tim Bishop wrote: > On Fri, May 23, 2014 at 08:07:03PM -0600, Alan Somers wrote: >> On Fri, May 23, 2014 at 7:47 PM, Tim Bishop wrote: >> > I have a new quad CPU system containing four of these processors: >> > >> > Intel(R) Xeon(R) CPU E7-4830 v2 @ 2.20GHz (2200.05-MHz K8-class CPU) >> > >> > I've tried FreeBSD 10.0, stable/10 and head, but all of them only detect >> > a maximum of 64 "CPUs". There should be 80. Here's the relevant dmesg >> > output (full output attached): >> > >> > FreeBSD/SMP: Multiprocessor System Detected: 64 CPUs >> > FreeBSD/SMP: 3 package(s) x 10 core(s) x 2 SMT threads >> > ... >> >> Try setting MAXCPU higher. It's defined by default to 64 in, >> sys/amd64/include/param.h > > Ah! Thank you, yes, that fixed it: > > FreeBSD/SMP: Multiprocessor System Detected: 80 CPUs > FreeBSD/SMP: 4 package(s) x 10 core(s) x 2 SMT threads > > Given the number of "CPUs" in some top end processors (up to 30 per > socket), a limit of 64 is starting to seem low. Is it worth doubling it > to 128? Or even higher? Yeah, I think so. It seems like a GENERIC kernel ought to be able to handle the biggest commonly available quad socket systems. Anything with more than 4 sockets, though, is probably too exotic to deserve such special treatment. > > It'd be nice to be able to use a stock kernel with freebsd-update at > least. > > Anyway, thanks for your help Alan, at least my system is working fully > now :-) > > Tim. > > -- > Tim Bishop > http://www.bishnet.net/tim/ > PGP Key: 0x6C226B37FDF38D55 > ___ 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: Processor cores not properly detected/activated?
On Fri, May 23, 2014 at 08:07:03PM -0600, Alan Somers wrote: > On Fri, May 23, 2014 at 7:47 PM, Tim Bishop wrote: > > I have a new quad CPU system containing four of these processors: > > > > Intel(R) Xeon(R) CPU E7-4830 v2 @ 2.20GHz (2200.05-MHz K8-class CPU) > > > > I've tried FreeBSD 10.0, stable/10 and head, but all of them only detect > > a maximum of 64 "CPUs". There should be 80. Here's the relevant dmesg > > output (full output attached): > > > > FreeBSD/SMP: Multiprocessor System Detected: 64 CPUs > > FreeBSD/SMP: 3 package(s) x 10 core(s) x 2 SMT threads > > ... > > Try setting MAXCPU higher. It's defined by default to 64 in, > sys/amd64/include/param.h Ah! Thank you, yes, that fixed it: FreeBSD/SMP: Multiprocessor System Detected: 80 CPUs FreeBSD/SMP: 4 package(s) x 10 core(s) x 2 SMT threads Given the number of "CPUs" in some top end processors (up to 30 per socket), a limit of 64 is starting to seem low. Is it worth doubling it to 128? Or even higher? It'd be nice to be able to use a stock kernel with freebsd-update at least. Anyway, thanks for your help Alan, at least my system is working fully now :-) Tim. -- Tim Bishop http://www.bishnet.net/tim/ PGP Key: 0x6C226B37FDF38D55 ___ 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: Processor cores not properly detected/activated?
On Fri, May 23, 2014 at 7:47 PM, Tim Bishop wrote:
> I have a new quad CPU system containing four of these processors:
>
> Intel(R) Xeon(R) CPU E7-4830 v2 @ 2.20GHz (2200.05-MHz K8-class CPU)
>
> I've tried FreeBSD 10.0, stable/10 and head, but all of them only detect
> a maximum of 64 "CPUs". There should be 80. Here's the relevant dmesg
> output (full output attached):
>
> FreeBSD/SMP: Multiprocessor System Detected: 64 CPUs
> FreeBSD/SMP: 3 package(s) x 10 core(s) x 2 SMT threads
> cpu0 (BSP): APIC ID: 0
> cpu1 (AP): APIC ID: 1
> ...
> cpu62 (AP): APIC ID: 98
> cpu63 (AP): APIC ID: 99
> cpu (AP): APIC ID: 100 (disabled)
> cpu (AP): APIC ID: 101 (disabled)
> cpu (AP): APIC ID: 102 (disabled)
> cpu (AP): APIC ID: 103 (disabled)
> cpu (AP): APIC ID: 104 (disabled)
> cpu (AP): APIC ID: 105 (disabled)
> cpu (AP): APIC ID: 112 (disabled)
> cpu (AP): APIC ID: 113 (disabled)
> cpu (AP): APIC ID: 114 (disabled)
> cpu (AP): APIC ID: 115 (disabled)
> cpu (AP): APIC ID: 116 (disabled)
> cpu (AP): APIC ID: 117 (disabled)
> cpu (AP): APIC ID: 118 (disabled)
> cpu (AP): APIC ID: 119 (disabled)
> cpu (AP): APIC ID: 120 (disabled)
> cpu (AP): APIC ID: 121 (disabled)
>
> Firstly, it should say 4 packages, so I'm not sure why its only has 3.
> But then it goes on to detect all the "CPUs", but doesn't enable the
> last 16.
>
> acpidump shows all the "CPUs" as enabled (trimmed output):
>
> APIC: Length=1090, Revision=1, Checksum=115,
> OEMID=DELL, OEM Table ID=PE_SC3, OEM Revision=0x1,
> Creator ID=DELL, Creator Revision=0x1
> Local APIC ADDR=0xfee0
> Flags={PC-AT}
>
> Type=Local APIC
> ACPI CPU=1
> Flags={ENABLED}
> APIC ID=0
>
> Type=Local APIC
> ACPI CPU=2
> Flags={ENABLED}
> APIC ID=32
>
> ...
>
> Type=Local APIC
> ACPI CPU=79
> Flags={ENABLED}
> APIC ID=89
>
> Type=Local APIC
> ACPI CPU=80
> Flags={ENABLED}
> APIC ID=121
>
> Finally, I've booted Ubuntu 14.04 (Linux 3.13) and it correctly detects
> all 80 "CPUs".
>
> Can anyone shed any light on what's happening?
>
> I'm running head at the moment and I'm happy to fiddle around as much as
> required to debug it.
>
> Thanks,
>
> Tim.
>
> --
> Tim Bishop
> http://www.bishnet.net/tim/
> PGP Key: 0x6C226B37FDF38D55
>
Try setting MAXCPU higher. It's defined by default to 64 in,
sys/amd64/include/param.h
___
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, PIE, and segvguard on 11-current and 10-stable
(Dropped the cross-posting, which *is* frowned upon) While I do very much appreciate this work being done, and I agree we should have it in the tree, I would really prefer it opt-in rather opt-out, at least initially. I know this may very well be the subject of a bikeshed of historical proportions but: 1) Understand this may break some applications (?). 2) It is yet undetermined what the performance effect will be. I find it very neat that it can be enabled for jails though. Pedro. ___ 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, PIE, and segvguard on 11-current and 10-stable
On May 23, 2014 07:53 PM +, Wojciech A. Koszek wrote: > On Wed, May 14, 2014 at 09:58:52AM -0400, Shawn Webb wrote: > > Hey All, > > > > [NOTE: crossposting between freebsd-current@, freebsd-security@, and > > freebsd-stable@. Please forgive me if crossposting is frowned upon.] > > > > Address Space Layout Randomization, or ASLR for short, is an exploit > > mitigation technology. It helps secure applications against low-level > > exploits. A popular secure implementation is known as PaX ASLR, which is > > a third-party patch for Linux. Our implementation is based off of PaX's. > > > > Oliver Pinter, Danilo Egea, and I have been working hard to bring more > > features and robust stability to our ASLR patches. We've done extensive > > testing on amd64. We'd like to get as many people testing these patches. > > Given the nature of them, we'd also like as many eyeballs reviewing the > > code as well. > > > > I have a Raspberry Pi and have noticed a few bugs. On ARM (at least, on > > the RPI), when a parent forks a child, and the child gracefully exits, > > the parent segfaults with the pc register pointing to 0xc000. That > > address is always the same, no matter the application. If anyone knows > > the ARM architecture well, and how FreeBSD ties into it, I'd like a > > little guidance. > > > > I also have a sparc64 box, but I'm having trouble getting a vanilla > > 11-current system to be stable on it. I ought to file a few PRs. > > > > You can find links to the patches below. > > > > Patch for 11-current: > > http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-current-aslr-segvguard-SNAPSHOT.diff > > > > Patch for 10-stable: > > http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-stable-10-aslr-segvguard-SNAPSHOT.diff > > > > Shawn > > I appreciate you working on this. We must have this in FreeBSD. > > I looked at the patch and I read, but not run it. Comments below. > > My personal opinion is that kern_pax.c should be compiled in by default. If > it adds a lot of size, it'd be better to provide empty stub calls instead of > #ifdef'ing everything. But security is very important especially in > embeddded systems, so you can imagine you're writing the code that everybody > wants and must have enabled for decent level of security. > > All modern systems run with ASLR turned on. > > I skipped user-space stuff. I don't think it's necessary in this commit and > should be separated. > > There's a lot of lines of code for status showing. Not sure if we care that > much: ASLR is either on or off. Not sure about more granularity. More below. We provide the level of granularity because there are a lot of applications that might exhibit weird behaviors or even crash if we randomize too many bits. We provide sane defaults, but allow each user to choose the level of security versus the level of stability they desire. > > Lots of files: > > You conditionally make .sv_pax_aslr_init method point to something else. I'd > assume PAX function _pax_aslr_init32() always gets called and based on > whether ASLR is on or not, it does something or not. This will simplify the > code a lot, and the difference probably won't be measurable. > > You have: > > int a; > int b; > > instead of: > > int a, b; > > And you miss spaces around "=" sometimes. Cleaning up the code and make style changes are a high priority on my list. Once I get a few more pieces of code locked down, I'm going to go over every line with a comb to make sure I'm adhering to the FreeBSD coding style. des@ has made a lot of suggestions in that regard and has even provided me with a sample vimrc. Prior to talking with des@, I was re-using the same vimrc that I use for ClamAV (which, admittedly, has a much different coding style than FreeBSD). > > kern_jail.c: > > something looks wrong here. Sounds like you need "pr->pax". But I don't > understand why you need to have these pr_* values here. It seems > unnecessary. I've made it possible to have per-jail ASLR settings. If you have an application that misbehaves, you can jail it with ASLR turned off just for that jail. My BSDCan presentation talks about this. The recording isn't up, yet, though. > > kern_pax.c: > > I can't quickly tell what locking is using. Some ASSERTS() in pax_ function > would help. > > pax_aslr_active(): > > I don't see why you need to pass "td" and "proc" (I looked at usage: you > pass proc only once). I think you could always pass proc to it, with > td->td_proc passed typically. > kern_pax_*: > > There's so many SYSCTLs I think people will have problem configuring it. > Pick reasonable value for all values and let users change them via > SYSCTL_INT (static sysctls) only for debugging. There are quite a few SYSCTLs, I agree. I'll talk with Oliver Pinter, one of the developers that is working with me on this ASLR implementation, to see if we can simplify this. > > I can imagine we won't want ASLR only
Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable
On 5/14/14, Shawn Webb wrote: > Hey All, > > [NOTE: crossposting between freebsd-current@, freebsd-security@, and > freebsd-stable@. Please forgive me if crossposting is frowned upon.] > > Address Space Layout Randomization, or ASLR for short, is an exploit > mitigation technology. It helps secure applications against low-level > exploits. A popular secure implementation is known as PaX ASLR, which is > a third-party patch for Linux. Our implementation is based off of PaX's. > > Oliver Pinter, Danilo Egea, and I have been working hard to bring more > features and robust stability to our ASLR patches. We've done extensive > testing on amd64. We'd like to get as many people testing these patches. > Given the nature of them, we'd also like as many eyeballs reviewing the > code as well. > > I have a Raspberry Pi and have noticed a few bugs. On ARM (at least, on > the RPI), when a parent forks a child, and the child gracefully exits, > the parent segfaults with the pc register pointing to 0xc000. That > address is always the same, no matter the application. If anyone knows > the ARM architecture well, and how FreeBSD ties into it, I'd like a > little guidance. > > I also have a sparc64 box, but I'm having trouble getting a vanilla > 11-current system to be stable on it. I ought to file a few PRs. > > You can find links to the patches below. > > Patch for 11-current: > http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-current-aslr-segvguard-SNAPSHOT.diff > > Patch for 10-stable: > http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-stable-10-aslr-segvguard-SNAPSHOT.diff > > Thanks, > > Shawn Webb > New round of patches are there: 11-CURRENT: http://www.crysys.hu/~op/freebsd/patches/20140524011327-freebsd-current-aslr-segvguard-SNAPSHOT.diff 10-STABLE: http://www.crysys.hu/~op/freebsd/patches/20140524011327-freebsd-stable-10-aslr-segvguard-SNAPSHOT.diff What's changed related to previous tag: 11-CURRENT: Oliver Pinter (17): PAX ASLR: update license in kern_pax_aslr.c PAX: update license in kern_pax.c PAX SEGVGUARD: update license in kern_pax_segvguard.c PAX: update license in pax.h PAX ASLR: remove unneeded parameter from pax_aslr_stack function PAX LOG: implement new logging subsystem PAX LOG: fix pax_ulog_segvguard PAX LOG: added sysctl's and tunables PAX ASLR: use PAX LOG PAX LOG: fix pax_ulog_##name() PAX LOG: fix prison init PAX LOG: fixed log and ulog sysctl PAX ASLR: fixed debug sysctl PAX: blacklist clang and related binaries from PIE support PAX ASLR: make ASLR by default opt-out Merge remote-tracking branch 'freebsd/master' into hardened/current/aslr Merge branch 'hardened/current/aslr' of github.com:HardenedBSD/hardenedBSD into hardened/current/aslr Shawn Webb (10): Remove CAN_PIE in preparation for NO_PIE Merge remote-tracking branch 'upstream/master' into hardened/current/aslr PAX ASLR: Blacklist the applications that don't support being built as a position-independent executable Merge remote-tracking branch 'upstream/master' into hardened/current/aslr Disable PAX_SEGVGUARD in LATT-ASLR kernel PAX ASLR: Lock the jail when initializing PAX per-jail PAX settings PAX ASLR: Fix bug with pax_aslr_active() PAX ASLR: Use a full kernel config for LATT-ASLR Revert "PAX: blacklist clang and related binaries from PIE support" Revert "Revert "PAX: blacklist clang and related binaries from PIE support"" 10-STABLE: Oliver Pinter (20): PAX ASLR: update license in kern_pax_aslr.c PAX: update license in kern_pax.c PAX SEGVGUARD: update license in kern_pax_segvguard.c PAX: update license in pax.h PAX ASLR: remove unneeded parameter from pax_aslr_stack function PAX LOG: implement new logging subsystem PAX LOG: fix pax_ulog_segvguard PAX LOG: added sysctl's and tunables PAX ASLR: use PAX LOG PAX LOG: fix pax_ulog_##name() PAX LOG: fix prison init PAX LOG: fixed log and ulog sysctl PAX ASLR: fixed debug sysctl Merge remote-tracking branch 'freebsd/stable/10' into hardened/10/aslr Merge remote-tracking branch 'freebsd/stable/10' into hardened/10/aslr added OPN-ASLR kernel config PAX: Remove CAN_PIE in preparation for NO_PIE from /bin/sh PAX: blacklist clang and related binaries from PIE support PAX ASLR: make ASLR by default opt-out Merge remote-tracking branch 'freebsd/stable/10' into hardened/10/aslr Shawn Webb (4): PAX: Remove CAN_PIE in preparation for NO_PIE PAX ASLR: Blacklist the applications that don't support being built as a position-independent executable PAX ASLR: Lock the jail when initializing PAX per-jail PAX settings PAX ASLR: Fix bug with pax_aslr_active() ___ freebsd-current@freebsd.org mailing list http://lists.freebs
Re: Change top's notion of idle processes / threads
On Friday, May 23, 2014 4:39:39 pm Poul-Henning Kamp wrote: > In message <201405231605.26312@freebsd.org>, John Baldwin writes: > > >In essence, top will consider any thread that has run on a CPU > >since the last update as non-idle. > > Sounds a lot more usable than the current heuristic. > > Wouldn't ki_rusage.ru_n[i]vcsw be more correct than ki_runtime ? Hmmm, possibly. ki_runtime in the kernel is basically TSC counts and gets updated on each context switch. OTOH, I think the exported version only has microsecond granularity which is probably too small. :( I can try your suggestion. -- John Baldwin ___ 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: Change top's notion of idle processes / threads
On 2014-05-23 16:05, John Baldwin wrote: > Right now, when top is set to not display idle processes or threads, it only > displays processes or threads that are currently in a runnable state or have > a > non-zero %cpu. However, our %cpu is quite imprecise. I have patch to change > top to instead compare the thread or processes runtime (ki_runtime in > kinfo_proc) against the runtime of the thread or process the last time data > was fetched. In essence, top will consider any thread that has run on a CPU > since the last update as non-idle. The end result is that mostly-idle > threads > and processes will now be visible in top's idle display. Personally, I find > this more useful (and find the current implementation completely useless). > The patch is at http://people.freebsd.org/~jhb/patches/top_idle.patch > > Comments? > I think this makes good sense. I would definitely prefer it. Would it make sense to maybe preserve the old behaviour behind a command line flag? -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: Change top's notion of idle processes / threads
In message <201405231605.26312@freebsd.org>, John Baldwin writes: >In essence, top will consider any thread that has run on a CPU >since the last update as non-idle. Sounds a lot more usable than the current heuristic. Wouldn't ki_rusage.ru_n[i]vcsw be more correct than ki_runtime ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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: [patch] Switch to text mode during efi boot
On 22 May 2014 11:32, Rafael Espíndola wrote:
>
> The ConsoleControl.h file is copied from
> EdkCompatibilityPkg/Foundation/Protocol/ConsoleControl in
> https://github.com/tianocore/edk2.
I'm not aware of the full ancestry of our EFI include files, but it
looks like the initial import made some attempt to bring them to
FreeBSD style. For example, our eficon.h is a version of
SimpleTextOut.h and efiser.h is SerialIo.h. For consistency with the
existing files I'll probably rename this one to eficonctl.h.
printf(" \n>> FreeBSD EFI boot block\n");
printf(" Loader path: %s\n", path);
+ EFI_BOOT_SERVICES *BS = systab->BootServices;
+ EFI_CONSOLE_CONTROL_PROTOCOL *ConsoleControl = NULL;
+ status = BS->LocateProtocol(&ConsoleControlGUID, NULL, (VOID
**)& ConsoleControl);
+ if (EFI_ERROR(status))
+ panic("No console control protocol located");
+
+ status = ConsoleControl->SetMode(ConsoleControl,
EfiConsoleControlScreenText);
+ if (EFI_ERROR(status))
+ panic("Could not switch to text mode");
I think we want to move the mode setting earlier so those printfs
work, and it probably makes sense to silently ignore failure from
LocateProtocol or SetMode. If we're already in text mode the failure
doesn't matter, and if we're not, the panic won't help diagnose the
problem.
Anyhow, I'll commit a version of this soon.
___
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: Change top's notion of idle processes / threads
On 05/23/2014 15:05, John Baldwin wrote: > Right now, when top is set to not display idle processes or threads, it only > displays processes or threads that are currently in a runnable state or have > a > non-zero %cpu. However, our %cpu is quite imprecise. I have patch to change > top to instead compare the thread or processes runtime (ki_runtime in > kinfo_proc) against the runtime of the thread or process the last time data > was fetched. In essence, top will consider any thread that has run on a CPU > since the last update as non-idle. The end result is that mostly-idle > threads > and processes will now be visible in top's idle display. Personally, I find > this more useful (and find the current implementation completely useless). > The patch is at http://people.freebsd.org/~jhb/patches/top_idle.patch > > Comments? I think I would much prefer the behavior with your patch. Eric ___ 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"
Change top's notion of idle processes / threads
Right now, when top is set to not display idle processes or threads, it only displays processes or threads that are currently in a runnable state or have a non-zero %cpu. However, our %cpu is quite imprecise. I have patch to change top to instead compare the thread or processes runtime (ki_runtime in kinfo_proc) against the runtime of the thread or process the last time data was fetched. In essence, top will consider any thread that has run on a CPU since the last update as non-idle. The end result is that mostly-idle threads and processes will now be visible in top's idle display. Personally, I find this more useful (and find the current implementation completely useless). The patch is at http://people.freebsd.org/~jhb/patches/top_idle.patch Comments? -- John Baldwin ___ 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, PIE, and segvguard on 11-current and 10-stable
On Wed, May 14, 2014 at 09:58:52AM -0400, Shawn Webb wrote: > Hey All, > > [NOTE: crossposting between freebsd-current@, freebsd-security@, and > freebsd-stable@. Please forgive me if crossposting is frowned upon.] > > Address Space Layout Randomization, or ASLR for short, is an exploit > mitigation technology. It helps secure applications against low-level > exploits. A popular secure implementation is known as PaX ASLR, which is > a third-party patch for Linux. Our implementation is based off of PaX's. > > Oliver Pinter, Danilo Egea, and I have been working hard to bring more > features and robust stability to our ASLR patches. We've done extensive > testing on amd64. We'd like to get as many people testing these patches. > Given the nature of them, we'd also like as many eyeballs reviewing the > code as well. > > I have a Raspberry Pi and have noticed a few bugs. On ARM (at least, on > the RPI), when a parent forks a child, and the child gracefully exits, > the parent segfaults with the pc register pointing to 0xc000. That > address is always the same, no matter the application. If anyone knows > the ARM architecture well, and how FreeBSD ties into it, I'd like a > little guidance. > > I also have a sparc64 box, but I'm having trouble getting a vanilla > 11-current system to be stable on it. I ought to file a few PRs. > > You can find links to the patches below. > > Patch for 11-current: > http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-current-aslr-segvguard-SNAPSHOT.diff > > Patch for 10-stable: > http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-stable-10-aslr-segvguard-SNAPSHOT.diff > Shawn I appreciate you working on this. We must have this in FreeBSD. I looked at the patch and I read, but not run it. Comments below. My personal opinion is that kern_pax.c should be compiled in by default. If it adds a lot of size, it'd be better to provide empty stub calls instead of #ifdef'ing everything. But security is very important especially in embeddded systems, so you can imagine you're writing the code that everybody wants and must have enabled for decent level of security. All modern systems run with ASLR turned on. I skipped user-space stuff. I don't think it's necessary in this commit and should be separated. There's a lot of lines of code for status showing. Not sure if we care that much: ASLR is either on or off. Not sure about more granularity. More below. Lots of files: You conditionally make .sv_pax_aslr_init method point to something else. I'd assume PAX function _pax_aslr_init32() always gets called and based on whether ASLR is on or not, it does something or not. This will simplify the code a lot, and the difference probably won't be measurable. You have: int a; int b; instead of: int a, b; And you miss spaces around "=" sometimes. kern_jail.c: something looks wrong here. Sounds like you need "pr->pax". But I don't understand why you need to have these pr_* values here. It seems unnecessary. kern_pax.c: I can't quickly tell what locking is using. Some ASSERTS() in pax_ function would help. pax_aslr_active(): I don't see why you need to pass "td" and "proc" (I looked at usage: you pass proc only once). I think you could always pass proc to it, with td->td_proc passed typically. kern_pax_*: There's so many SYSCTLs I think people will have problem configuring it. Pick reasonable value for all values and let users change them via SYSCTL_INT (static sysctls) only for debugging. I can imagine we won't want ASLR only temporarily, for ports which break and must be fixed. So we probably just need per-process ASLR on/off switch and a wrapper which could be used like: aslr off program The debug stuff I'd remove too. We could have additional CTR stubs used there, if necessary. segvguard part I didn't understand. Why do you keep a list of programs that failed? There was no ASSERTs, thus it was hard to understand the locking too. I'm trying to understand if randomization is done correctly. Do you think you could post the results? Program: http://pastebin.com/XTRHLhMg Results: cat > aslr.c gcc aslr.c -o aslr echo 1 2 3 4 5 | xargs -I % -n 1 echo "./aslr > aslr.%" | sh paste aslr.[12345] | column -t Linux with ASLR: http://pastebin.com/UuwW1JMN MacOSX: http://pastebin.com/kuQnYS4e Thanks, -- Wojciech A. Koszek wkos...@freebsd.czest.pl http://FreeBSD.czest.pl/~wkoszek/ ___ 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: panic: resource_list_add: resource entry is busy
On May 23, 2014, at 8:07 AM, John Baldwin wrote: > On Monday, May 19, 2014 4:12:50 pm Hans Petter Selasky wrote: >> On 05/18/14 23:03, Hans Petter Selasky wrote: >>> Hi, >>> >>> First call: >>> >>> resource_list_add: >> >> Hi, >> >> It appears that the /dev/pccard.X is opened and reading some CIS data >> from the device before any driver has been attached. The attached patch >> solves the panic I've seen. Not sure if the patch is correct. > > Oops, your patch was dropped in my reply, but it just disables > pccard_scan_cis() while a device is probing. Hmmm, that seems like it would break PC Card probing entirely… Otherwise, how would we get here? The stack traces earlier in the thread suggest that would be the case…. What’s the other thing reading /dev/pccard.X though? > Warner, the issue here is that pccard_scan_cis() can do a > bus_alloc_resource() > for SYS_RES_MEMORY rid 0 of a pccard device concurrently with > pccard_function_init(). Hans patch might be along the right track, though > we might want to make /dev/pccard.X block until pccard_function_init() > finishes rather than causing pccard_scan_cis() to fail. What do you think? Yes. I’d say it a bit differently. Only one pccard_scan_cis should be in flight at a time. http://people.freebsd.org/~imp/patch-queue/cismtx should do the trick. Warner signature.asc Description: Message signed with OpenPGP using GPGMail
Re: ports/INDEX building broken on 11.0-CURRENT
On May 13, 2014, at 5:04 PM, Don Lewis wrote:
> On 13 May, To: po...@freebsd.org wrote:
>> Please excuse the crosspost. I'm not sure if this is a ports problem or
>> a CURRENT problem.
>>
>> I just updated my 11.0-CURRENT machine to r265940 and can no longer
>> build ports/INDEX-11. My ports tree is r353903. I think this problem
>> is being caused by the recent changes to /usr/share/mk/*.
>>
>> # make index
>> Generating INDEX-11 - please wait..--- describe.accessibility ---
>> --- describe.arabic ---
>> --- describe.archivers ---
>> --- describe.astro ---
>> --- describe.audio ---
>> --- describe.benchmarks ---
>> --- describe.biology ---
>> --- describe.cad ---
>> --- describe.chinese ---
>> --- describe.comms ---
>> --- describe.converters ---
>> --- describe.databases ---
>> --- describe.deskutils ---
>> --- describe.devel ---
>> clang33: not found
>> make[5]: "/usr/share/mk/bsd.compiler.mk" line 24: warning: "clang33
>> --version" returned non-zero status
>> make[5]: "/usr/share/mk/bsd.compiler.mk" line 37: Unable to determine
>> compiler type for clang33. Consider setting COMPILER_TYPE.
>> ===> devel/ccons failed
>> *** [describe.devel] Error code 1
>>
>> make[2]: stopped in /usr/ports
>> 1 error
>>
>> make[2]: stopped in /usr/ports
>>
>>
>> Before reporting this error, verify that you are running a supported
>> version of FreeBSD (see http://www.FreeBSD.org/ports/) and that you
>> have a complete and up-to-date ports collection. (INDEX builds are
>> not supported with partial or out-of-date ports collections.
>> If that is the case, then
>> report the failure to po...@freebsd.org together with relevant
>> details of your ports configuration (including FreeBSD version,
>> your architecture, your environment, and your /etc/make.conf
>> settings, especially compiler flags and OPTIONS_SET/UNSET settings).
>>
>> Note: the latest pre-generated version of INDEX may be fetched
>> automatically with "make fetchindex".
>>
>>
>> *** Error code 1
>>
>> Stop.
>> make[1]: stopped in /usr/ports
>> *** Error code 1
>>
>> Stop.
>> make: stopped in /usr/ports
>>
>>
>> If I go to the offending port:
>>
>> # cd /usr/ports/devel/ccons/
>> # make describe
>> clang33: not found
>> make: "/usr/share/mk/bsd.compiler.mk" line 24: warning: "clang33 --version"
>> returned non-zero status
>> make: "/usr/share/mk/bsd.compiler.mk" line 37: Unable to determine compiler
>> type for clang33. Consider setting COMPILER_TYPE.
>>
>>
>> I don't have any problems building the INDEX file on 9.3-PRERELEASE
>> r265940.
>
> Various ports were setting CC to the following, which was causing the
> bsd.compiler.mk to barf:
> clang32
> clang33
> /usr/bin/gcc
> mingw32-gcc
> gcc
Yea, the actual problem is that it assumed that the CC you’d set actually
existed on the system. Not unreasonable in the building /usr/src context, but
less reasonable in this context...
> The patch below allowed me to successfully run "make index" and reduced
> the error spewage. It also greatly reduces the need to run
> ${CC} --version
> in order to set COMPILER_TYPE.
>
> It still seems like a great waste to run
> ${CC} --version
> for each port to set COMPILER_VERSION since only a handful of ports need
> this information.
Unfortunately, you can’t do that. You must know the version of the compiler
in the bsd.*.mk system now. It is unfortunate that ports system users this
aspect of tree, or at least that it slows things down a bit.
> Then there is this sort of circular dependency in some ports, like this
> one in textproc/ibus/Makefile:
>
> .if ${COMPILER_TYPE} == gcc && ${COMPILER_VERSION} < 46
> USE_GCC=yes
> .endif
>
> This will cause CC to be redefined, but COMPILER_TYPE and
> COMPILER_VERSION will still retain their old values.
This suggests that ports might be better served by another mechanism, since
this one doesn’t fit quite right….
> Index: share/mk/bsd.compiler.mk
> ===
> --- share/mk/bsd.compiler.mk (revision 265940)
> +++ share/mk/bsd.compiler.mk (working copy)
> @@ -21,23 +21,28 @@
> .if !target()
> :
>
> -_v!= ${CC} --version
> .if !defined(COMPILER_TYPE)
> -. if ${CC:T:Mgcc*}
> +. if ${CC:T:M*gcc*}
> COMPILER_TYPE:= gcc
> -. elif ${CC:T:Mclang}
> +. elif ${CC:T:Mclang*}
> COMPILER_TYPE:= clang
> -. elif ${_v:Mgcc}
> +. else
> +_v!= ${CC} --version
> +. if ${_v:Mgcc}
> COMPILER_TYPE:= gcc
> -. elif ${_v:M\(GCC\)}
> +. elif ${_v:M\(GCC\)}
> COMPILER_TYPE:= gcc
> -. elif ${_v:Mclang}
> +. elif ${_v:Mclang}
> COMPILER_TYPE:= clang
> -. else
> +. else
> .error Unable to determine compiler type for ${CC}. Consider setting
> COMPILER_TYPE.
> +. endif
> . endif
> .endif
> .if !defined(COMPILER_VERSION)
> +. if !defined(_v)
> +_v
Re: panic: resource_list_add: resource entry is busy
On Monday, May 19, 2014 4:12:50 pm Hans Petter Selasky wrote: > On 05/18/14 23:03, Hans Petter Selasky wrote: > > Hi, > > > > First call: > > > > resource_list_add: > > Hi, > > It appears that the /dev/pccard.X is opened and reading some CIS data > from the device before any driver has been attached. The attached patch > solves the panic I've seen. Not sure if the patch is correct. Oops, your patch was dropped in my reply, but it just disables pccard_scan_cis() while a device is probing. Warner, the issue here is that pccard_scan_cis() can do a bus_alloc_resource() for SYS_RES_MEMORY rid 0 of a pccard device concurrently with pccard_function_init(). Hans patch might be along the right track, though we might want to make /dev/pccard.X block until pccard_function_init() finishes rather than causing pccard_scan_cis() to fail. What do you think? -- John Baldwin ___ 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: Thinkpad T410: resume broken
On Wednesday, May 21, 2014 3:43:49 pm Jan Henrik Sylvester wrote: > On 05/21/2014 21:22, Hans Petter Selasky wrote: > > On 05/21/14 21:16, Jan Henrik Sylvester wrote: > >> Unfortunately, my USB mouse does not work anymore: After the first > >> resume, it took a few seconds until it worked again (the build in > >> touchpad was back immediately). After the second resume, it would not > >> work anymore at all, even after reconnecting it to a different EHCI > >> port. It does work at a XHCI, though, until the next resume. Anyhow, > >> this is obviously not related to the original problem. > > > > Hi, > > > > USB controller are being reset at resume, so I think this indicates a > > more fundamental PCI/BUS problem. > > Looking through dmesg, it seems that other USB devices (build-in) are > reappearing (Qualcomm Gobi 2000, Broadcom Bluetooth Device) after > resume, just not the mouse. > > Are these lines likely related? > > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.PEG_: > AE_BAD_PARAMETER > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP1: > AE_BAD_PARAMETER > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP2: > AE_BAD_PARAMETER > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP4: > AE_BAD_PARAMETER > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP5: > AE_BAD_PARAMETER These are probably not related. These man that your BIOS explicitly told the OS to power down these devices (PEG_ is probably your GPU, and EXP[1-5] are probably PCI-PCI bridges that represent the downstream ports of your PCI-e root complex) in the D2 state when suspending, but the devices don't actually support D2 (most PCI devices only support D0 (full on) and D3 (full off)). -- John Baldwin ___ 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: Thinkpad T410: resume broken
On 21.05.2014 21:43, Jan Henrik Sylvester wrote: > On 05/21/2014 21:22, Hans Petter Selasky wrote: >> On 05/21/14 21:16, Jan Henrik Sylvester wrote: >>> Unfortunately, my USB mouse does not work anymore: After the first >>> resume, it took a few seconds until it worked again (the build in >>> touchpad was back immediately). After the second resume, it would not >>> work anymore at all, even after reconnecting it to a different EHCI >>> port. It does work at a XHCI, though, until the next resume. Anyhow, >>> this is obviously not related to the original problem. >> >> Hi, >> >> USB controller are being reset at resume, so I think this indicates a >> more fundamental PCI/BUS problem. > > Looking through dmesg, it seems that other USB devices (build-in) are > reappearing (Qualcomm Gobi 2000, Broadcom Bluetooth Device) after > resume, just not the mouse. I can confirm this behavior. It already happened on 9.x. Devices plugged into the USB ports are not even powered. It's not just mouse, also USB hard disks for instance. > Are these lines likely related? > > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.PEG_: > AE_BAD_PARAMETER > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP1: > AE_BAD_PARAMETER > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP2: > AE_BAD_PARAMETER > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP4: > AE_BAD_PARAMETER > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP5: > AE_BAD_PARAMETER I don't remember seeing these lines in 9.x. That doesn't necessarily mean they are not related. -- Stefan ___ 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"
