Re: bash_profile, tcshrc, etc... Oh My!
On 9/28/13, Teske, Devin wrote: > "Trying to use /bin/sh" thread inspired me to check my home-dir goodies into > CVS: > > http://druidbsd.cvs.sf.net/viewvc/druidbsd/home/ > > Just thought I'd share. There's some cool stuff if you want to have some > fun. > -- > Cheers, > Devin FYI: https://github.com/opntr/freebsd-user-env > > _ > The information contained in this message is proprietary and/or > confidential. If you are not the intended recipient, please: (i) delete the > message and all copies; (ii) do not disclose, distribute or use the message > in any manner; and (iii) notify the sender immediately. In addition, please > be aware that any message addressed to our domain is subject to archiving > and review by persons other than the intended recipient. Thank you. > ___ > 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: expanding amd64 past the 1TB limit
On 6/27/13, Chris Torek wrote: > OK, I wasted :-) way too much time, but here's a text file that > can be comment-ified or stored somewhere alongside the code or > whatever... > > (While drawing this I realized that there's at least one "wasted" > page if the machine has .5 TB or less: we can just leave zero > slots in the corresponding L4 direct-map entries. But that would > require switching to the bcopy() method also mentioned below. Or > indexing into vmspace0.vm_pmap.pm_pml4, which is basically the > same thing.) > > Chris > > - > > There are six -- or sometimes five -- sets of pages allocated here > at boot time to map physical memory in two ways. Note that each > page, regardless of level, stores 512 PTEs (or PDEs or PDPs, but > let's just use PTE here and prefix it with "level" as needed: 4, > 3, 2, or 1.) > > There is one page for the top level, L4, page table entries. Each > L4 PTE maps 512 GB of space. Unless it's marked "invalid", no L4 > PTE can be marked "stop here": it either is marked as "this > address is invalid", or it points to one physically-adressed page > full of L3 PTEs. Eventually, those L3 PTEs will map-or-reject > half a terabyte. 512 entries, each mapping .5 TB, allow us to map > 256 TB, which is as much as the hardware supports (there are, in > effect, only 48 virtual address bits: the top 16 bits must match > the 47th bit). > > The L4 entry halfway down, at PML4PML4I, is set to point back to > this page itself; that's the "recursive page table" for user > space, which we do nothing else with at boot time. > > We need (up to) NDMPML4E pages, each holding 512 L3 PTEs, for the > direct map space. If the processor supports 1 GB pages, an L3 PTE > can be marked with "stop here" and these L3 PTEs each grant (or > forbid) access to 1 GB of physical space at a time. A system > with, say, 3 GB of RAM starting at 0 can map it all with three L3 > PTEs: "address 0 is valid for 1GB", "address 1GB is valid for > 1GB", "address 2GB is valid for 1GB". The remaining L3 PTEs are > zero, making the remaining address space invalid. > > If the processor does not support 1 GB pages, or if there is less > than 1 GB of RAM "at the end" (e.g., if the system has 4.5 GB), > the L3 PTEs may need to point to more pages holding L2 PTEs. > These L2 PTEs always support 2 MB pages. Each page of L2 PTEs > maps 1 GB. So a machine with 4.5 GB and 1 GB mappings needs one L3 > page with four valid 1 GB L3 PTEs and then one L3 PTE pointing to > one page of L2 PTEs. That one page of L2 PTEs is half-filled, > containing 256 2MB-sized PTEs, mapping the 512 MB. The remaining > half of that page is zero, making the remaining addresses invalid. > > Pictorially, and adding the names of the physical page(s), thus > far we have this. (Note, the L4 PTE page is drawn more than twice > as tall as the L3 and L2 pages, just to get space for arrows.) > > LEVEL 4:LEVEL 3: LEVEL 2: > _._ > KPML4phys v \ > +-+ | > | 0: | | > |-| | > | 1: | | DMPDPphys DMPDphys > ( ... ) |.-> +-+ ++ > | 127:| | /| 0: 0GB | .-> | 0: 4GB| > |-| | | | 1: 1GB |/| 1: 4GB+2MB| > PML4PML4I: | 128: *--|--/ | | 2: 2GB | / | 2: 4GB+4MB| > |-| | | 3: 3GB | / ( ... ) > | 129:| | | 4: *--|-/ | 255: 4.5GB-2MB | > | ... | | | 5: | | 256: | > |-| | ( ... ) | 257: | > / DMPML4I: | *--|-/ | 511:| ( ... ) > NDMPML4E|-| +-+ ++ > \ | *--|-> | 0:| > |-| | 1:| >| | | 2:| (These are used only > |-| | 3:| if the system has more > | ... | ( ... ) than 512 GB) > ( |-| )| 509:| > ( | 510: see below )| 510:| > ( |-| )| 511:| > ( | 511: see below )+-+ >+-+ > > If the hardware supports 1GB pages, "ndm1g" is the number of > gigabyte entries (4 in the example above). Otherwise it's just > zero. Meanwhile "ndmpdp" is the number of gigabytes of RAM that > need to be mapped, in this case 5. Thus, if ndmpdp > ndm1g, we > need ndmpdp-ndm1g pages to hold some L2 PTEs. > > Now we get to the weirder case of the kernel itself (both its > non-direct-mapped dynamically allocated virtual memory, and its > text/data/bss). The branch offset limitations encourage the > placement of the kern
Re: A way to switch off nVidia discrete cards ?
On 6/8/13, Florent Peterschmitt wrote: > Hi, > > I've absolutely no skill in system development but I think, based on > bbswitch (which is part of bumblebee project), that doing such a think > would not be too difficult. > > I have a 9.1-RELEASE FreeBSD which I'm going to upgrade to -current, for > testing and developing purpose so, is there any documentation or little > how-to of how to develop for FreeBSD, in the kernel, using access to > hardware and ACPI ? p@pandora-test ~> sysctl -d hw.pci.do_power_nodriver hw.pci.do_power_nodriver: Place a function into D3 state when no driver attaches to it. 0 means disable. 1 means conservatively place devices into D3 state. 2 means agressively place devices into D3 state. 3 means put absolutely everything in D3 state. > > 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" > ___ 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: syscall to userland interface
On 5/11/13, Alfred Perlstein wrote: > On 5/11/13 1:23 AM, Karl Dreger wrote: >> >> I am feeling rather stupid at the moment, but I can't find the assembler >> >> files that you are referring to. Do you mean that every syscall under >> >> sys/kern/*.c has a corresponding .S file in src/lib/libc/? > > Nope, the .S files are under the object directory: > >> When you build the system a whole bunch of assembler files are >> automatically generated that define the functions you are looking for. >> >> Look for .S files under the object directory. >> >> Those assembler files have the magic to cause a system call to happen. >> >> example: src/lib/libc/getauid.S (note, this file is GENERATED, it's not >> part of src.) > > > >> >> >> The actual transition from user to kernelland and back probably takes >> >> place via the assembler routines in sys/i386/i386. Most notably >> exception.s >> >> for my i386 cpu. >> >> >> What my question boils down to is this: when running fork and friends >> >> from userland they are invoked as: >> >> fork();, open();, read();, close(); ... >> >> >> but are defined as: >> >> sys_fork(), sys_open(), sys_read(), sys_close(), ... >> >> in their actual c definition. >> >> If the assembler files that you spoke about answer this discrepancy, >> >> then the reason why the penny hasn't dropped yet is because I haven't >> found them. >> >> > Again, they are generated as part of build. You will NOT find them > during a checkout. cd /usr/obj/*/lib/libc/ ls *.S > > -Alfred > ___ > 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: copyinstr()
On 4/9/13, Vijay Singh wrote: > Hi, I was looking for some help with copyinstr() on an amd64 platform. > > My from address happens to be in the kernel (stack). I am getting an > EFAULT, and I am wondering how to fix that. > > Would using memory from malloc() make a difference? The copyinstr check the address before do anything. amd64/support.S: /* * copyinstr(from, to, maxlen, int *lencopied) - MP SAFE * %rdi, %rsi, %rdx, %rcx * * copy a string from from to to, stop when a 0 character is reached. * return ENAMETOOLONG if string is longer than maxlen, and * EFAULT on protection violations. If lencopied is non-zero, * return the actual length in *lencopied. */ ENTRY(copyinstr) movq%rdx,%r8/* %r8 = maxlen */ movq%rcx,%r9/* %r9 = *len */ xchgq %rdi,%rsi /* %rdi = from, %rsi = to */ movqPCPU(CURPCB),%rcx movq$cpystrflt,PCB_ONFAULT(%rcx) movq$VM_MAXUSER_ADDRESS,%rax /* make sure 'from' is within bounds */ subq%rsi,%rax jbe cpystrfl [...] cpystrflt: movq$EFAULT,%rax [...] Try copyout() instead of copyinstr(), as there in amd64 are no copyoutstr(). > > -vijay > ___ > 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: FreeBSD ZFS source
http://svnweb.freebsd.org/base/head/sys/cddl/contrib/opensolaris/common/ http://svnweb.freebsd.org/base/head/cddl/contrib/opensolaris/lib/ On 8/2/12, Fredrik wrote: > Hello, > > Excuse me for this newb question but exactly where are the current ZFS files > located? I have been looking at the CVS on freebsd.org under > /src/contrib/opensolaris/ but that does not seem to be the current ones. Is > this correct? > > Regards___ > 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"
[Phrack Mag.] The false kingdom of jemalloc, or On exploiting the jemalloc memory manager
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: Fwd: my git development snapshot(s)
On 5/12/12, Ulrich Spörlein wrote: > On Fri, 2012-05-11 at 16:49:42 -0400, Arnaud Lacombe wrote: >> Hi, >> >> On Sun, Dec 11, 2011 at 8:08 AM, Ulrich Spörlein >> wrote: >> > On Sun, 2011-12-04 at 18:42:38 -0500, Arnaud Lacombe wrote: >> >> On Fri, Oct 7, 2011 at 6:28 AM, Ulrich Spörlein >> >> wrote: >> >> > On Fri, 2011-09-30 at 15:41:41 -0400, Arnaud Lacombe wrote: >> >> >> On Mon, Sep 26, 2011 at 2:23 PM, Arnaud Lacombe >> >> >> wrote: >> >> >> > FWIW, how comes that there is not yet any `stable/9' branch on the >> >> >> > github tree ? >> >> >> > >> >> >> Ulrich, ping ? >> >> > >> >> > Oops, sorry for the delay! Fixed now, thanks for bringing it to my >> >> > attention. I missed the push --all flag. :/ >> >> > >> >> FWIW, the github mirror[0] of the completed SVN tree has not seen any >> >> upgrade for a week now. Did some script broke ? >> >> >> >> Thanks, >> >> - Arnaud >> >> >> >> [0]: https://github.com/freebsd/freebsd >> > >> > Yeah, sorry about that. Monitoring is not that great, so you should >> > always ping me directly. >> > >> > The problem is that people dump files at random places in the >> > Subversion >> > tree and that cannot easily be translated to branches. This time it was >> > /vendor/flex/FreeBSD-Xlist >> > >> It would seem the full SVN mirror on github is out-of-sync again, at >> least, the `user/imp/extern_cc' is missing. > > user/ isn't pushed to github (and I consider also not pushing projects/ > into it), as their webfrontend often craps out with too many branches. > > You can get it from git.freebsd.org directly. git.freebsd.org ? > > Uli > ___ > 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"
geom_aes
Hi all! What is geom_aes (sys/geom/geom_aes.*) (wherein differs form geli, besides useses fewer geom layer and has a compiled in key), and who can I find something from this geom module/layer? How can I use this geom layer? Only added option geom_aes to kernel config? ___ 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: CUDA porting effort?
CC: Oliver Hartmann On 2/15/12, Eric McCorkle wrote: > Given that NVidia is releasing the CUDA platform source on a limited > basis, is anyone actively working to port it to FreeBSD? The reason I > ask is that to get access to the source, you have to submit a request > explaining what you intend to use it for. It might be a good idea to > get ahold of the source on behalf of FreeBSD, so that interested people > could work on porting it. I could devote a small amount of time to such > an effort; I'm wondering if there's interest from anyone else. > > ___ 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: CPUTYPE and friends, from 'make.conf' benchmark
On 12/5/11, rank1see...@gmail.com wrote:
> I've took machine and installed binary FreeBSD(amd64 8.2-p4 GENERIC) on it.
> Then I've installed 'benchmarks/unixbench' port.
>
> So everything is a default generic binary install ('make.conf' empty - no
> CPU optimization flags)
>
> After running: '# time unixbench', final score was:
> 394.2
> Completed in 22.8 min
>
>
> Then I've recompiled everything, from src, world and kernel, with
> 'make.conf':
> --
> CPUTYPE?=core2
> CFLAGS+=-march=native
> NO_CPU_CFLAGS=yes
> COPTFLAGS+=-march=native
> NO_CPU_COPTFLAGS=yes
> --
>
> After reboot, I've run: '# time unixbench', final score was:
> 313.5
> Completed in 26.7 min
>
> I'm getting worse result, with optimized FreeBSD's binaries?!?
> How come?
What is the test environment?
All tests running after a reboot? (if not, then do...)
Run all test in single user, when freebsd reboots, after the system
become up, than we have a running bgfsck (fixme).
And run the tests in multiple time, example with make.conf setting 5X
and without make.conf setting 5X.
>
>
> 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"
>
___
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"
Flash FS for NetBSD
Hi all! Today found this procejt: http://chewiefs.sed.hu/ When I good remember, Arounld searched flash fs for bsd, so cc-d. ___ 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: Clustering server in freebsd
see hastd(8) On 10/10/11, elman wrote: > Dear all > > I have plan to cluster server with freebsd 8.2 for mailserver. But I'm > confusing with the software for clustering. Do you have a reference for me, > or do you have blog and I can see your blog for reference to create > clustering with freebsd. > > Thanks hacker > Best regards. > Mr. L > Powered by Telkomsel BlackBerry® ___ 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] fake pre-processor macros when building on non-FreeBSD system
On 7/12/11, Robert Millan wrote:
> 2011/7/12 Oliver Pinter :
>> +.if ${OPSYS} != "FreeBSD"
>>
>> and what's the status example on NetBSD?
>
> I didn't think of it. There are some instances of __NetBSD__ and also
> __OpenBSD__ in the kernel tree, and the same problem can be fixed for
> these two systems with minimal effort.
>
> Here's a new version of the patch, which also adds -U__NetBSD__ and
> -U__OpenBSD__ to CFLAGS.
>
> --
> Robert Millan
>
This seem like an ugly hack..
Please keep in your mind, FreeBSD is not linux; and I hope, never be
___
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: Fwd: [PATCH v2 3/4] x86, head_32/64.S: Enable SMEP
On 5/18/11, Kostik Belousov wrote: > On Wed, May 18, 2011 at 10:50:30AM -0400, John Baldwin wrote: >> On Wednesday, May 18, 2011 8:31:15 am Oliver Pinter wrote: >> > On 5/18/11, Kostik Belousov wrote: >> > > On Wed, May 18, 2011 at 02:03:07AM +0200, Oliver Pinter wrote: >> > >> -- Forwarded message -- >> > >> From: Fenghua Yu >> > >> Date: Mon, 16 May 2011 14:34:44 -0700 >> > >> Subject: [PATCH v2 3/4] x86, head_32/64.S: Enable SMEP >> > >> To: Ingo Molnar , Thomas Gleixner >> > >> , >> > >> H Peter Anvin , Asit K Mallick >> > >> , Linus Torvalds >> > >> , Avi Kivity , Arjan >> > >> van de Ven , Andrew Morton >> > >> , Andi Kleen >> > >> Cc: linux-kernel , Fenghua Yu >> > >> >> > >> >> > >> From: Fenghua Yu >> > >> >> > >> Enable newly documented SMEP (Supervisor Mode Execution Protection) >> > >> CPU >> > >> feature in kernel. >> > >> >> > >> SMEP prevents the CPU in kernel-mode to jump to an executable page >> > >> that >> > >> does >> > >> not have the kernel/system flag set in the pte. This prevents the >> > >> kernel >> > >> from executing user-space code accidentally or maliciously, so it for >> > >> example >> > >> prevents kernel exploits from jumping to specially prepared user-mode >> > >> shell >> > >> code. The violation will cause page fault #PF and will have error >> > >> code >> > >> identical to XD violation. >> > >> >> > >> CR4.SMEP (bit 20) is 0 at power-on. If the feature is supported by >> > >> CPU >> > >> (X86_FEATURE_SMEP), enable SMEP by setting CR4.SMEP. New kernel >> > >> option nosmep disables the feature even if the feature is supported >> > >> by >> > >> CPU. >> > >> >> > >> Signed-off-by: Fenghua Yu >> > > >> > > So, where is the mentioned documentation for SMEP ? Rev. 38 of the >> > > Intel(R) 64 and IA-32 Architectures Software Developer's Manual does >> > > not contain the description, at least at the places where I looked and >> > > expected to find it. >> > >> > http://www.intel.com/Assets/PDF/manual/325384.pdf >> > >> > Intel? 64 and IA-32 Architectures Software Developer?s Manual >> >Volume 3 (3A & 3B): >> > System Programming Guide >> >> Which revision? It is not documented in revision 38 from April 2011. >> >> I just downloaded that link, and it is still revision 38 and has no >> mention no, under the original intel link i find rev.39 Order Number: 325384-039US May 2011 uploaded here: http://oliverp.teteny.bme.hu/up/325384.pdf >> 'SMEP'. Also, bit 20 of CR4 is still marked as Reserved in that manual >> (section 2.5). > This is exactly what I said about rev. 38 in my original reply. > ___ 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: Fwd: [PATCH v2 3/4] x86, head_32/64.S: Enable SMEP
On 5/18/11, Kostik Belousov wrote: > On Wed, May 18, 2011 at 02:03:07AM +0200, Oliver Pinter wrote: >> -- Forwarded message -- >> From: Fenghua Yu >> Date: Mon, 16 May 2011 14:34:44 -0700 >> Subject: [PATCH v2 3/4] x86, head_32/64.S: Enable SMEP >> To: Ingo Molnar , Thomas Gleixner , >> H Peter Anvin , Asit K Mallick >> , Linus Torvalds >> , Avi Kivity , Arjan >> van de Ven , Andrew Morton >> , Andi Kleen >> Cc: linux-kernel , Fenghua Yu >> >> >> From: Fenghua Yu >> >> Enable newly documented SMEP (Supervisor Mode Execution Protection) CPU >> feature in kernel. >> >> SMEP prevents the CPU in kernel-mode to jump to an executable page that >> does >> not have the kernel/system flag set in the pte. This prevents the kernel >> from executing user-space code accidentally or maliciously, so it for >> example >> prevents kernel exploits from jumping to specially prepared user-mode >> shell >> code. The violation will cause page fault #PF and will have error code >> identical to XD violation. >> >> CR4.SMEP (bit 20) is 0 at power-on. If the feature is supported by CPU >> (X86_FEATURE_SMEP), enable SMEP by setting CR4.SMEP. New kernel >> option nosmep disables the feature even if the feature is supported by >> CPU. >> >> Signed-off-by: Fenghua Yu > > So, where is the mentioned documentation for SMEP ? Rev. 38 of the > Intel(R) 64 and IA-32 Architectures Software Developer's Manual does > not contain the description, at least at the places where I looked and > expected to find it. http://www.intel.com/Assets/PDF/manual/325384.pdf Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 3 (3A & 3B): System Programming Guide > > Looking forward to hear from you. > > ___ 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"
Fwd: [PATCH v2 3/4] x86, head_32/64.S: Enable SMEP
-- Forwarded message -- From: Fenghua Yu Date: Mon, 16 May 2011 14:34:44 -0700 Subject: [PATCH v2 3/4] x86, head_32/64.S: Enable SMEP To: Ingo Molnar , Thomas Gleixner , H Peter Anvin , Asit K Mallick , Linus Torvalds , Avi Kivity , Arjan van de Ven , Andrew Morton , Andi Kleen Cc: linux-kernel , Fenghua Yu From: Fenghua Yu Enable newly documented SMEP (Supervisor Mode Execution Protection) CPU feature in kernel. SMEP prevents the CPU in kernel-mode to jump to an executable page that does not have the kernel/system flag set in the pte. This prevents the kernel from executing user-space code accidentally or maliciously, so it for example prevents kernel exploits from jumping to specially prepared user-mode shell code. The violation will cause page fault #PF and will have error code identical to XD violation. CR4.SMEP (bit 20) is 0 at power-on. If the feature is supported by CPU (X86_FEATURE_SMEP), enable SMEP by setting CR4.SMEP. New kernel option nosmep disables the feature even if the feature is supported by CPU. Signed-off-by: Fenghua Yu --- arch/x86/kernel/head_32.S | 17 + arch/x86/kernel/head_64.S | 13 +++-- 2 files changed, 24 insertions(+), 6 deletions(-) diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S index ce0be7c..5325c02 100644 --- a/arch/x86/kernel/head_32.S +++ b/arch/x86/kernel/head_32.S @@ -308,11 +308,20 @@ default_entry: movl cr4_bits,%edx andl %edx,%edx jz 6f - movl %cr4,%eax # Turn on paging options (PSE,PAE,..) - orl %edx,%eax - movl %eax,%cr4 + movl %cr4,%edi # Turn on paging options (PSE,PAE,..) + orl %edx,%edi - testb $X86_CR4_PAE, %al # check if PAE is enabled + /* Check if SMEP is supported by the processor */ + movl $0x7, %eax + movl $0, %ecx + cpuid + btl $7, %ebx + jnc 1f + /* Enable SMEP */ + orl $(X86_CR4_SMEP), %edi +1: movl %edi, %cr4 + + test $X86_CR4_PAE, %di # check if PAE is enabled jz 6f /* Check if extended functions are implemented */ diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S index e11e394..220ec5f 100644 --- a/arch/x86/kernel/head_64.S +++ b/arch/x86/kernel/head_64.S @@ -161,8 +161,17 @@ ENTRY(secondary_startup_64) */ /* Enable PAE mode and PGE */ - movl$(X86_CR4_PAE | X86_CR4_PGE), %eax - movq%rax, %cr4 + movl$(X86_CR4_PAE | X86_CR4_PGE), %edi + + /* Check if SMEP is supported by the processor */ + movl$0x7, %eax + movl$0, %ecx + cpuid + btl $7, %ebx + jnc 1f + /* Enable PAE mode, PGE, and SMEP */ + movl$(X86_CR4_PAE | X86_CR4_PGE | X86_CR4_SMEP), %edi +1: movq%rdi, %cr4 /* Setup early boot stage 4 level pagetables. */ movq$(init_level4_pgt - __START_KERNEL_map), %rax -- 1.7.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ ___ 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: Question about sysctl-ing coretemp module values
http://oliverp.teteny.bme.hu/git/?p=base/AiBoost-sensord.git;a=blob;f=aiboost-sensord.c;h=349b612066eb0514a2d5c3035908e7418ca71500;hb=HEAD On 1/15/11, Harald Servat wrote: > Hello, > > First of all, forgive if this is not the appropiate list to ask this. > Could you point me the correct list if so? > > I'm writing a small program to capture the temperature reported by the > coretemp kernel module. I'm doing this by using the sysctl API. However, I'm > facing a problem when reading that value (dev.cpu.0.temperature, for > example). > > man 3 sysctl has an example (labeled as "To retrieve the standard search > path for the system utilities:") which seems great to me to know the length > of the OID it wants to read before running the "real" sysctl. I wrote a > similar example (attached) based on that, but it does not work appropiately. > The 1st call tells me that len = 4 (whereas the value for > dev.cpu.0.temperature is "37.0C" which should be 5 if \0 is not counted). > > Can anyone shed some light on what I'm doing wrong? > > Thank you very much! > -- > _ > Fry: You can see how I lived before I met you. > Bender: You lived before you met me?! > Fry: Yeah, lots of people did. > Bender: Really?! > ___ 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: kernel patch needed for wine?
CC pipacs and Hunger ;) On 7/1/10, Uffe Jakobsen wrote: > > Garrett writes: >>> Also, is there perhaps a sideeffect dealing with the size of a char on >>> FreeBSD vs Linux? >>> >>> That's a pretty badass way to load assembler instructions on the stack >>> :). >>> > > I may be totally wrong here - but could it be NX/XD/XN protection ? > > /Uffe > > > ___ > 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: something fails with svn
hmmm, it's look like this: http://lists-archives.org/git/707921-git-svn-memoize-conversion-of-svn-merge-ticket-info-to-git-commit-ranges.html git releated change is the source of the warnings.. and the git is updated at Dec 28 20:39 ll /usr/local/bin/git -rwxr-xr-x 95 root wheel 1066766 Dec 28 20:39 /usr/local/bin/git so i have this workaround: --8<-- alias src_update '(cd /usr/data/source/git/7-STABLE.git; '\ 'git svn rebase' \ '| grep -E -v "^Couldn.t find revmap for svn://svn\.freebsd\.org/base/stable/7";' \ 'cd ~/src;' \ 'git pull)' \ '|& less' --8<-- and sorry for noise.. ps.: added the git patch author to cc On 1/2/10, Oliver Pinter wrote: > yeah, but svn.freebsd.org/base/stable/7/head don't exist. > > git svn log -v > > some of broken infos find in this commit: > > r200570 | stas | 2009-12-15 11:34:05 +0100 (Tue, 15 Dec 2009) | 23 lines > Changed paths: >M share/man/man4/bge.4 >M sys/dev/bge/if_bge.c >M sys/dev/bge/if_bgereg.h > > - MFC r197832, r197834, r197837: > - Add support for new BGE chips (5761, 5784 and 57780). These chips uses > new > BGE_PCI_PRODID_ASICREV register to store the chip identifier and its > revisio > n. > - Add new grouping macro for 7575+ chips (BGE_IS_5755_PLUS). > - Add IDs for Fujitsu-branded Broadcom adapters. >> PR:If a GNATS PR is affected by the change. >> Submitted by: If someone else sent in the change. >> Reviewed by: If someone else reviewed your modification. >> Approved by: If you needed approval for this commit. >> Obtained from: If the change is from a third party. >> MFC after: N [day[s]|week[s]|month[s]]. Request a reminder email. >> Security: Vulnerability reference (one per line) or description. >> Empty fields above will be automatically removed. > > _M 7/share/man/man4 > M7/share/man/man4/bge.4 > _M 7/sys > M7/sys/dev/bge/if_bgereg.h > M7/sys/dev/bge/if_bge.c > _M 7/sys/contrib/pf > _M 7/sys/contrib/dev/acpica > _M 7/sys/cddl/contrib/opensolaris > > > On 1/2/10, Ryan Stone wrote: >>> the git config is: >>> >>> [core] >>>repositoryformatversion = 0 >>>filemode = true >>>bare = false >>>logallrefupdates = true >>> [svn-remote "svn"] >>>>>>>url = svn://svn.freebsd.org/base/stable/7 <<<< >>>fetch = :refs/remotes/git-svn >>> >> >> It looks like the error is on the line I've highlighted(note that it's >> trying to fetch files under svn://svn.freebsd.org/base/stable/7/head, >> which clearly won't work). I don't know anything about git so I can't >> give advice as to how to accomplish what you're trying to do. >> > ___ 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: something fails with svn
yeah, but svn.freebsd.org/base/stable/7/head don't exist. git svn log -v some of broken infos find in this commit: r200570 | stas | 2009-12-15 11:34:05 +0100 (Tue, 15 Dec 2009) | 23 lines Changed paths: M share/man/man4/bge.4 M sys/dev/bge/if_bge.c M sys/dev/bge/if_bgereg.h - MFC r197832, r197834, r197837: - Add support for new BGE chips (5761, 5784 and 57780). These chips uses new BGE_PCI_PRODID_ASICREV register to store the chip identifier and its revisio n. - Add new grouping macro for 7575+ chips (BGE_IS_5755_PLUS). - Add IDs for Fujitsu-branded Broadcom adapters. > PR:If a GNATS PR is affected by the change. > Submitted by: If someone else sent in the change. > Reviewed by: If someone else reviewed your modification. > Approved by: If you needed approval for this commit. > Obtained from: If the change is from a third party. > MFC after: N [day[s]|week[s]|month[s]]. Request a reminder email. > Security: Vulnerability reference (one per line) or description. > Empty fields above will be automatically removed. _M 7/share/man/man4 M7/share/man/man4/bge.4 _M 7/sys M7/sys/dev/bge/if_bgereg.h M7/sys/dev/bge/if_bge.c _M 7/sys/contrib/pf _M 7/sys/contrib/dev/acpica _M 7/sys/cddl/contrib/opensolaris On 1/2/10, Ryan Stone wrote: >> the git config is: >> >> [core] >> repositoryformatversion = 0 >> filemode = true >> bare = false >> logallrefupdates = true >> [svn-remote "svn"] >> url = svn://svn.freebsd.org/base/stable/7 >> fetch = :refs/remotes/git-svn >> > > It looks like the error is on the line I've highlighted(note that it's > trying to fetch files under svn://svn.freebsd.org/base/stable/7/head, > which clearly won't work). I don't know anything about git so I can't > give advice as to how to accomplish what you're trying to do. > ___ 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: something fails with svn
and the newest log: M COPYRIGHT r201336 = a1f0e71ec85d326f0cb79b829129279961a36ed9 (refs/remotes/git-svn) M lib/libc/gen/time.3 M lib/libc/sys/clock_gettime.2 Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/lib/libc/stdtime Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/vendor/tzcode/dist/libc/stdtime Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/lib/libc Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/vendor/tzcode/dist/libc r201363 = b04276d84884164bf0878eb7d11f3100bcdcd3a0 (refs/remotes/git-svn) Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/sys/cddl/contrib/opensolaris Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/sys Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/stable/8/sys Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/user/kmacy/releng_7_2_fcs/sys Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/user/peter/kinfo/sys Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/sys/contrib/dev/acpica Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/sys/contrib/pf Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/stable/8/sys/contrib/pf Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/user/peter/kinfo/sys/contrib/pf r201365 = 4ad205e7e4ca78fc6ac8e5e9ea81b2199339917f (refs/remotes/git-svn) First, rewinding head to replay your work on top of it... Fast-forwarded master to refs/remotes/git-svn. >From /usr/data/source/git/7-STABLE 00e48c1..4ad205e master -> origin/master Merge made by recursive. COPYRIGHT|2 +- lib/libc/gen/time.3 |1 + lib/libc/sys/clock_gettime.2 | 55 + 3 files changed, 46 insertions(+), 12 deletions(-) the master local git repo don't touched, only synced with freebsd's svn repo, and the local commit are in second git tree commited, say it as: ~/src/, and the master is /usr/data/source/git/7-STABLE - this is a simple _git svn rebase_ based git tree. the command with synced the tree is: alias src_update '(cd /usr/data/source/git/7-STABLE.git; git svn rebase; cd ~/src; git pull) |& less' so, the all process show as this: 1) cd /usr/data/source/git/7-STABLE.git # can't comment.. 2) git svn rebase # this fetched the source from svn://svn.freebsd.org/base/stable/7, and then updated the git repo 3) cd ~/src # can't comment.. 4) git pull # this fetched from the GIT repo the source, this runned without error So, the error is somewhere in process 2). And the errors in log is recently this files: svn://svn.freebsd.org/base/stable/7/head/lib/libc/stdtime svn://svn.freebsd.org/base/stable/7/vendor/tzcode/dist/libc/stdtime svn://svn.freebsd.org/base/stable/7/head svn://svn.freebsd.org/base/stable/7/head/lib/libc svn://svn.freebsd.org/base/stable/7/vendor/tzcode/dist/libc svn://svn.freebsd.org/base/stable/7/head/sys/cddl/contrib/opensolaris svn://svn.freebsd.org/base/stable/7/head/sys svn://svn.freebsd.org/base/stable/7/stable/8/sys svn://svn.freebsd.org/base/stable/7/user/kmacy/releng_7_2_fcs/sys svn://svn.freebsd.org/base/stable/7/user/peter/kinfo/sys svn://svn.freebsd.org/base/stable/7/head/sys/contrib/dev/acpica svn://svn.freebsd.org/base/stable/7/head/sys/contrib/pf svn://svn.freebsd.org/base/stable/7/stable/8/sys/contrib/pf svn://svn.freebsd.org/base/stable/7/user/peter/kinfo/sys/contrib/pf when you see the PATHs, then its showed as: 7-STABLE_base_path+"do something else" and at the end, i synced with this process my source code over one year, but it showed since ~1 week, as the first mail wroted.. On 1/2/10, Oliver Pinter wrote: > the problem is at a standstill above always, only I did not see a > sense so since I did not receive constructive feedback véáaszolni... > otherwise i tested more things, but the situation did not change. > > // sorry for bad english, but I never learned it.. > > On 1/2/10, jhell wrote: >> On 1/1/2010 6:24 AM, Ed Schouten wrote: >>> * jhell wrote: >>>> With those remarks I will leave it up to your honed skills to figure >>>> out. >>> >>> If you don't have anything constructive to say, please refrain from >>> responding to any message on these lists. The purpose of these lists is >>> to help each other. >>> >> >> You know really... I did not see anything that you have replied with to >> be constructive criticism "At all". >> >> And personally if you really want to reply with remarks of "Would you >> mind sharing your findings Sherlock Holmes" You can then keep your >> comm
Re: something fails with svn
the problem is at a standstill above always, only I did not see a sense so since I did not receive constructive feedback véáaszolni... otherwise i tested more things, but the situation did not change. // sorry for bad english, but I never learned it.. On 1/2/10, jhell wrote: > On 1/1/2010 6:24 AM, Ed Schouten wrote: >> * jhell wrote: >>> With those remarks I will leave it up to your honed skills to figure out. >> >> If you don't have anything constructive to say, please refrain from >> responding to any message on these lists. The purpose of these lists is >> to help each other. >> > > You know really... I did not see anything that you have replied with to > be constructive criticism "At all". > > And personally if you really want to reply with remarks of "Would you > mind sharing your findings Sherlock Holmes" You can then keep your > comments to your self as I do not find them useful and my name is not > Sherlock Holmes. > > Secondly I would expect a much more intelligent remark to come from > someone with your background but I guess that comes with age. > > So my suggestion in constructiveness to you would be to think harder > before you critique a post of the very same nature as the one you posted. > > As regards to the OP the email was meant as a confirmation to the author > that the problem did lye on his end and that by paying closer attention > to "the paths" that were displayed in the OP would have revealed the > problem. > > -- > > jhell > ___ 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"
something fails with svn
Hi list! Something fails, when updated the FreeBSD's svn repo to git. Since yesterday I get this warning: $ git svn rebase ... M sys/boot/pc98/kgzldr/crt.s Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/sys/cddl/contrib/opensolaris Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/sys Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/stable/8/sys Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/user/kmacy/releng_7_2_fcs/sys Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/user/peter/kinfo/sys Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/sys/contrib/dev/acpica Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/sys/contrib/pf Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/stable/8/sys/contrib/pf Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/user/peter/kinfo/sys/contrib/pf r201153 = 2a0c8903699f2e4ff17312c753e335424eeac5e3 (refs/remotes/git-svn) M sys/powerpc/conf/DEFAULTS M sys/sparc64/conf/DEFAULTS M sys/ia64/conf/DEFAULTS M sys/sun4v/conf/DEFAULTS M sys/pc98/conf/DEFAULTS M sys/i386/conf/DEFAULTS M sys/amd64/conf/DEFAULTS Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/sys/cddl/contrib/opensolaris Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/sys/contrib/dev/acpica Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/sys Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/sys/contrib/pf r201164 = c4051399b1b56820b010acba9f5f0e2953f5be70 (refs/remotes/git-svn) M etc/rc.d/named M etc/mtree/BIND.chroot.dist M etc/namedb/named.conf Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/etc r201173 = d70d011b0c38f8a35845a3a63e6ba60f2f04774b (refs/remotes/git-svn) M usr.sbin/zic/Theory M lib/libc/stdtime/tzfile.5 Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/vendor/tzcode/dist/libc/stdtime Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/lib/libc Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/vendor/tzcode/dist/libc Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/usr.sbin/zic Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/vendor/tzcode/dist Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/vendor/tzcode/dist/zic r201184 = 47c9db23979a71f805ff5f11d0574ae1ed83a581 (refs/remotes/git-svn) ... the git config is: [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true [svn-remote "svn"] url = svn://svn.freebsd.org/base/stable/7 fetch = :refs/remotes/git-svn Is this a user error (my), or it's an mismerge or repo fail git / or freebsd's svn? ___ 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: Common interface for sensors/health monitoring
Hello! When I good know, no common interface exisit in current freebsd kernel, but some other sysctl interfece exisit: coretemp, aiboost ... ~> sysctl dev.coretemp dev.coretemp.0.%desc: CPU On-Die Thermal Sensors dev.coretemp.0.%driver: coretemp dev.coretemp.0.%parent: cpu0 dev.coretemp.1.%desc: CPU On-Die Thermal Sensors dev.coretemp.1.%driver: coretemp dev.coretemp.1.%parent: cpu1 dev.coretemp.2.%desc: CPU On-Die Thermal Sensors dev.coretemp.2.%driver: coretemp dev.coretemp.2.%parent: cpu2 dev.coretemp.3.%desc: CPU On-Die Thermal Sensors dev.coretemp.3.%driver: coretemp dev.coretemp.3.%parent: cpu3 ~> sysctl dev.acpi_aiboost dev.acpi_aiboost.0.%desc: ASUStek AIBOOSTER dev.acpi_aiboost.0.%driver: acpi_aiboost dev.acpi_aiboost.0.%location: handle=\_SB_.PCI0.SBRG.ASOC dev.acpi_aiboost.0.%pnpinfo: _HID=ATK0110 _UID=16843024 dev.acpi_aiboost.0.%parent: acpi0 dev.acpi_aiboost.0.temp0: 190 dev.acpi_aiboost.0.temp1: 300 dev.acpi_aiboost.0.volt0: 1144 dev.acpi_aiboost.0.volt1: 3328 dev.acpi_aiboost.0.volt2: 5064 dev.acpi_aiboost.0.volt3: 12096 dev.acpi_aiboost.0.fan0: 1962 dev.acpi_aiboost.0.fan1: 1180 dev.acpi_aiboost.0.fan2: 1278 dev.acpi_aiboost.0.fan3: 0 dev.acpi_aiboost.0.fan4: 0 but no common if.. On 8/22/09, Aurélien Méré wrote: > Hi, > > I've been using FreeBSD for years in all my servers, but I'm facing a big > problem today. All servers are under monitoring using a couple of > applications and scripts. Monitored items for each server especially are > CPU/mobo/UPS/HDD temperatures, CPU load, memory use, fans speed, PSU/UPS > voltages, HDD/RAID status&usage, network connectivity, UPS load, battery > status & runtime, ... > > My concern today, excepted that there is no way to gather all the data > through a unique interface and that consequently we have to change the > scripts depending on hardware, is that some information are no longer > available at all, especially concerning the MB IC, ie. temperatures, > voltages & fan speed. Actually, some SMBus controllers (like from 2006 or > so) are not supported by any driver and I didn't find any port updated to > access the IC directly (if even possible). Currently, I sometimes have to > use mbmon with direct I/O, sometimes mbmon with SMBus, sometimes healthd and > sometimes nothing works (PR 137668 or 136762 as examples in my case). > > Besides that, I was quite surprised that these information are available in > OpenBSD through a very simple and unique sysctl interface, with up-to-date > drivers, working on all my servers with a generic install. I know that below > this presentation layer, this may be much less perfect, and by digging in, I > found that a 2007 GSoC project for porting the OpenBSD sensor framework was > realised and planned to be put in HEAD. I also read hundreds of mails > concerning this project, and why finally it was not commited. > > As developer, I fully understand some of the concerns in these threads and > that there are probably lots of things to change and work on, integrate it > in a cleaner repository like snmp or whatever; and I'd be glad to help in > any > possible way to improve this. But in the meantime, as netadmin, this kind of > information can be very important to prevent or diagnose major problems; so > I'd like to know what is being planned/done on this subject, as I didn't > find any > more information related to this than a discussion during bsdcan 2008. > > Thanks for your help and time, > Aurélien > > > > > ___ > 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: Security: information leaks in /proc enable keystroke recovery
On 8/16/09, David Wagner wrote: > At Usenix Security 2009, two researchers announced last week a new > security vulnerability in multi-user Linux systems. They demonstrated > that one user can, in many cases, recover partial information about > the keystrokes that another user types into applications running on > that system. For instance, they demonstrate how a malicious user can > recover partial information about SSH passwords typed by other users, > reducing the password search space by a factor of 250-2000x in > their experiments. Thus, this could facilitate password recovery. > > Question: Are there any plans to modify the Linux kernel to defend > against this kind of attack? > > The paper is here: > > http://www.usenix.org/events/sec09/tech/full_papers/zhang.pdf > > In a nutshell, they exploit the fact that many files in /proc are > world-readable yet contain sensitive information that can leak information > about inter-keystroke timings. For instance, /proc/$PID/stat reveals the > ESP and EIP registers of the associated process, and is world-readable. > /proc/pid/status is also mentioned as revealing information that could > be exploited in these attacks. > > Based on my understanding of their work, it sounds like some of > the information on those files should perhaps not be world-readable. > It's not clear to me that it's reasonable for the kernel to reveal ESP, > EIP, and other sensitive information about process behavior to everyone > on the same system. > > Are folks already aware of these vulnerabilities? Is there any work > underway to try to address the issues identified in the Usenix Security > paper? > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > [snip] 6.2 Information Leaks in the Procfs of Other UNIX-like Systems Besides Linux, most other UNIX-like systems also im- plement procfs. These implementations vary from case to case, and as a result, their susceptibilities to side- channel attacks also differ. Here we discuss such privacy risks on two systems, FreeBSD and OpenSolaris. FreeBSD manages its process files more cautiously than Linux12 : it puts all register values into the file /proc/pid/regs that can only be read by the owner of a process, which blocks the information used by our attack. However, we found that other informa- tion released by the procfs can lead to similar attacks. A prominent example is the system time reported by /proc/pid/status, a file open to every user. Fig- ure 11 shows the correlations between the time con- sumed by vim and the keystrokes it received, as ob- served in our research. This demonstrates that keystroke events within the process can be identified from the change of its system time, which makes keystroke eaves- dropping possible. A problem here is that we may not be able to detect special keys a user enters, for example, “MOV CURSOR”, which is determined from ESP/EIP in- formation on Linux. A possible solution is using the dis- crepancies of system-time increments triggered by dif- ferent keys being entered to fingerprint these individual keys. Further study of this technique is left to our future research. [/snip] ___ 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"
breaked kde3
[New Thread 0x800a020b0 (LWP 100411)] [Switching to Thread 0x800a020b0 (LWP 100411)] [KCrash handler] #6 0x00080ca93364 in jpeg_CreateDecompress () from /usr/local/lib/compat/pkg/libjpeg.so.9 #7 0x000807744490 in read_jpeg_image () from /usr/local/lib/libqt-mt.so.3 #8 0x000807514890 in QImageIO::read () from /usr/local/lib/libqt-mt.so.3 #9 0x000807514fc3 in QImage::load () from /usr/local/lib/libqt-mt.so.3 #10 0x00080d449ac1 in KBackgroundRenderer::doWallpaper () from /usr/local/lib/libkdeinit_kdesktop.so #11 0x00080d44a6fb in KBackgroundRenderer::render () from /usr/local/lib/libkdeinit_kdesktop.so #12 0x00080d44a9e5 in KBackgroundRenderer::qt_invoke () from /usr/local/lib/libkdeinit_kdesktop.so #13 0x00080753a16e in QObject::activate_signal () from /usr/local/lib/libqt-mt.so.3 #14 0x00080753adb9 in QObject::activate_signal () from /usr/local/lib/libqt-mt.so.3 #15 0x0008075560ca in QTimer::event () from /usr/local/lib/libqt-mt.so.3 #16 0x0008074ec149 in QApplication::internalNotify () from /usr/local/lib/libqt-mt.so.3 #17 0x0008074ecb11 in QApplication::notify () from /usr/local/lib/libqt-mt.so.3 #18 0x00080b5a62c6 in KApplication::notify () from /usr/local/lib/libkdecore.so.6 #19 0x0008074e386f in QEventLoop::activateTimers () from /usr/local/lib/libqt-mt.so.3 #20 0x0008074a992d in QEventLoop::processEvents () from /usr/local/lib/libqt-mt.so.3 #21 0x0008074ff24a in QEventLoop::enterLoop () from /usr/local/lib/libqt-mt.so.3 #22 0x0008074ff12e in QEventLoop::exec () from /usr/local/lib/libqt-mt.so.3 #23 0x00080d40d0e1 in kdemain () from /usr/local/lib/libkdeinit_kdesktop.so #24 0x004079d0 in execpath_avoid_loops () #25 0x004081a7 in execpath_avoid_loops () #26 0x004086f5 in execpath_avoid_loops () #27 0x00408f2b in main () ___ 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"
ZFS: freebsd-current vs osol2009.06
http://209.85.129.132/translate_c?hl=en&u=http://suckit.blog.hu/2009/07/16/zfs_sebesseg_freebsd_vs_opensolaris&rurl=translate.google.com&usg=ALkJrhhn2z8lEDw1hZEUEqAiCZ330Gw41w ___ 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: FYI Lighttpd 1.4.23 /kernel (trailing '/' on regular file symlink) vulnerability
Hi! This is a redefinitions of PARAMASK in the patch, that you attached ---8<- ... #definePARAMASK0x0e00 /* mask of parameter descriptors */ +#defineTRAILINGSLASH 0x1000 /* path ended in a slash */ +#definePARAMASK0x1e00 /* mask of parameter descriptors */ ... ---8<- On 5/27/09, Dag-Erling Smørgrav wrote: > Eygene Ryabinkin writes: >> [new three-part patch] > > I committed the namei.h cleanup patch and the vfs_lookup.c comment > patch. > > I made a number of changes to the trailing-slash patch. Can you > double-check it before I commit it? > > DES > -- > Dag-Erling Smørgrav - d...@des.no > > ___ 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"
NetBSD 5.0 statistics
Is the FreeBSD's FS management so slow? http://www.netbsd.org/~ad/50/img15.html Or so big is the difference between the two cpu scheduler? http://www.netbsd.org/~ad/50/img0.html ___ 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: WANTED! board models with Marvell 61XX chips
Hi ASUS P5Q-E has 88SE6121 On 1/26/09, Søren Schmidt wrote: > Hi there! > > I thought I finally had a motherboard using one of the Marvell SATA/ > PATA chips coming in, but unfortunately the delivery has been > postponed to some unspecified date, oh well.. > > Thats where you come into the picture as I'd like to get another one, > but finding boards that uses these is a bit tricky as most vendors > doesn't write such unimportant stuff on their web pages (hell it works > in windows!). > > If you have a motherboard using one of the following Marvell chips, or > know for certain a model that does, please send me a private mail with > make and model as there is no need to pollute the lists (which I dont > follow closely for the time being btw). > > The chips in question are: > > Marvell 6111, 6121, 6141 or 6145 > > It is also important that there is physical access to both the SATA > and the PATA port(s) as some boards only utilize one or the other. > > I know of one PCI-express add-in board that uses the 6145, so if > anybody knows how to get ahold of one, that would be very welcomed as > well. The board in question is this: > http://www.sunix.com.tw/it/en/Product_Detail.php?cate=2&class_a_id=35&sid=538 > So far I've only found shops in South Africa that has it available, > but none of them ships outside the country. > > So if you have any useful info on this topic please get in touch with > me, thanks! > > > -Søren > -- > > > > > > > > > > ___ > freebsd-curr...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-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"
