Re: Fwd: [PATCH v2 3/4] x86, head_32/64.S: Enable SMEP
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. Looking forward to hear from you. pgpYcKGUj9rIq.pgp Description: PGP signature
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: Freebsd on the sun x4440
On Tue, 17 May 2011, krad wrote: On 17 May 2012 01:34, Mark Saad wrote: All I am setting up 3 sun x4440 with freebsd 7.3 amd64 . The severs have 4x 4-core opterons and 128G of ram each . Once the servers boot they are a good fit for what we are doing and preform well . The odd thing I am seeing is a long delay in boot up . Once in the initial loading of the kernel at the "|" for 1-2 mins . Then again shortly after printing the kernel banner "freebsd 7.3-release etc etc etc" . This delay is about 1-2 mins as well. So my question does any one know what I could do to speed up the boot up ? I suspect the first delay is due to a serial device probe the second is a mystery . also the bios load up time is about 5 mins on this box does anyone have any ideas on speeding that up ? mark saad Nonesuch@longcount.org___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" why 7.3? You might have better luck with 8.2. Not I real answer but sometimes its easier to go around issues As Sean Bruno said in the other thread, this is probably the ~useless "memory check" done at boot; you can find the full thread where it was recently discussed here: http://lists.freebsd.org/pipermail/freebsd-arch/2011-March/011198.html --kaduk ___ 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: NFS mount inside jail fails
On 5/17/11 1:17 PM, Alexander Leidinger wrote: On Tue, 17 May 2011 12:56:40 -0700 Sean Bruno wrote: Silly thing I ran into today. User wanted to NFS mount a dir inside a jail. After I groaned about the security implication of this, I noted that there is a sysctl that looks like it should allow this. Namely, security.jail.mount_allowed. I noted that setting this follows a path that *should* have allowed this silly thing to happen, except that the credentials in the nfsclient were not setup correctly. As you noticed, this is supposed to allow to mount inside a jail, IF the FS you want to mount is marked as secure/safe to do so. Nearly no FS is marked as such, as nobody wants to guarantee that it is safe (root in a jail should not be able to panic a system by trying to mount a corrupt/malicious FS-image) and secure (not possible to get elevated access/privileges). For NFS there is theoretically the problem that the outgoing address on requests could be the one of the physical host instead of the IP of the jail. If this is true in practice, I do not know. This could be the reason why NFS is not marked with VFCF_JAIL. a vimage jail would not have that problem if we've done it right. Bye, Alexander. ___ 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: NFS mount inside jail fails
On Tue, 17 May 2011 12:56:40 -0700 Sean Bruno wrote: > Silly thing I ran into today. User wanted to NFS mount a dir inside a > jail. After I groaned about the security implication of this, I noted > that there is a sysctl that looks like it should allow this. Namely, > security.jail.mount_allowed. I noted that setting this follows a path > that *should* have allowed this silly thing to happen, except that the > credentials in the nfsclient were not setup correctly. As you noticed, this is supposed to allow to mount inside a jail, IF the FS you want to mount is marked as secure/safe to do so. Nearly no FS is marked as such, as nobody wants to guarantee that it is safe (root in a jail should not be able to panic a system by trying to mount a corrupt/malicious FS-image) and secure (not possible to get elevated access/privileges). For NFS there is theoretically the problem that the outgoing address on requests could be the one of the physical host instead of the IP of the jail. If this is true in practice, I do not know. This could be the reason why NFS is not marked with VFCF_JAIL. Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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"
NFS mount inside jail fails
Silly thing I ran into today. User wanted to NFS mount a dir inside a jail. After I groaned about the security implication of this, I noted that there is a sysctl that looks like it should allow this. Namely, security.jail.mount_allowed. I noted that setting this follows a path that *should* have allowed this silly thing to happen, except that the credentials in the nfsclient were not setup correctly. e.g. VFS_SET(nfs_vfsops, oldnfs, VFCF_NETWORK); -- I changed this to: VFS_SET(nfs_vfsops, oldnfs, VFCF_NETWORK|VFCF_JAIL); This seems to allow the user's desired effect after setting security.jail.mount_allowed=1 I *think* this is the correct behavior, if a bit silly when taking into account the purpose of a jail. Thoughts? Sean ___ 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: OpenGrok for FreeBSD
On 5/17/11 1:35 AM, Zafer Aydoğan wrote: 2011/5/13 Zafer Aydoğan: Zafer. Hmm... there seems to be very little interest so far. Although this tool is mainly useful for developers, what is the correct mailing list to announce it ? The service seems to be good but most people who are developers have their own ways of acting with the sources already and asking them to change their habits built up over many years is hard to do.. people who are looking at sources using a web sute are probably already using fxr.watson.org that doesn't mean that it's not useful, just that it takes people a while to start using a new service.. how does it disambiguate teh same finction names in a kernel and in a /bin program? Zafer. ___ 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 on the sun x4440
On 17 May 2012 01:34, Mark Saad wrote: > All > I am setting up 3 sun x4440 with freebsd 7.3 amd64 . The severs have 4x > 4-core opterons and 128G of ram each . Once the servers boot they are a good > fit for what we are doing and preform well . The odd thing I am seeing is a > long delay in boot up . Once in the initial loading of the kernel at the "|" > for 1-2 mins . Then again shortly after printing the kernel banner "freebsd > 7.3-release etc etc etc" . This delay is about 1-2 mins as well. So my > question does any one know what I could do to speed up the boot up ? I > suspect the first delay is due to a serial device probe the second is a > mystery . also the bios load up time is about 5 mins on this box does anyone > have any ideas on speeding that up ? > > > mark saad > Nonesuch@longcount.org___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" > why 7.3? You might have better luck with 8.2. Not I real answer but sometimes its easier to go around issues ___ 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: OpenGrok for FreeBSD
2011/5/17 Vitaly Magerya : > Zafer Aydoğan wrote: >> Hmm... there seems to be very little interest so far. > > FWIW, I find this tool useful, but since it's most helpful when you > need to dig into a previously unknown portion of code, which doesn't > happen that often, it's reasonable to expect infrequent usage -- don't > mistake that for lack of interest (i.e. I bookmarked the thing, but > don't know when I'll get a chance to need it). > >> Although this tool is mainly useful for developers, >> what is the correct mailing list to announce it ? > > This would be the correct list, I guess. > > PS. The history pages are hard to decode; they are sorted by something > other than date or revision number; and which branch do they show? > Compare [1] and [2]; revisions starting from 1.6.2.5 are not from the > same branch, are they? > > [1] http://fxr.aydogan.net/history/src/usr.sbin/powerd/powerd.c > [2] http://svnweb.freebsd.org/base/head/usr.sbin/powerd/powerd.c?view=log > The branches are sorted below HEAD. Its hard to say which branch, unless its noted in the commit log. This is done by opengrok. Its a feature, I guess. Zafer. ___ 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: OpenGrok for FreeBSD
Zafer Aydoğan wrote: > Hmm... there seems to be very little interest so far. FWIW, I find this tool useful, but since it's most helpful when you need to dig into a previously unknown portion of code, which doesn't happen that often, it's reasonable to expect infrequent usage -- don't mistake that for lack of interest (i.e. I bookmarked the thing, but don't know when I'll get a chance to need it). > Although this tool is mainly useful for developers, > what is the correct mailing list to announce it ? This would be the correct list, I guess. PS. The history pages are hard to decode; they are sorted by something other than date or revision number; and which branch do they show? Compare [1] and [2]; revisions starting from 1.6.2.5 are not from the same branch, are they? [1] http://fxr.aydogan.net/history/src/usr.sbin/powerd/powerd.c [2] http://svnweb.freebsd.org/base/head/usr.sbin/powerd/powerd.c?view=log ___ 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: MD ROOT and image size limitation (makes kernel panic)
> Hi, > > On Mon, May 16, 2011 at 11:36 AM, wrote: > > I have a 4 GB or ram, so why kernel panic with my MD ROOT, if larger then > > ~40 MB? > > I've tried to split up root in 20MB image and usr in 160 MB > > Via loader.conf root becomes md0 and usr md1 and panic occurs even when > > they are split > > > > I had to get rid of md1, to be able to boot with md0 as a root. > > > > What exactly imposes limitation, inside kernel's code to SIZE of an image? > > My hardware definatelly isn't ... > > > > Is this different on amd64? > > I've tested this, only with i386. > > > > We hit this problem at work and the solution was to increase NKPT. > > If you are using -current then NKPT is already a kernel config option. > With 8.x you will need to modify . Well ..., it looks like my 8.2 RELEASE src, has it, but ONLY for i386 # less /usr/src/sys/i386/conf/NOTES -- # # Number of initial kernel page table pages used for early bootstrap. # This number should include enough pages to map the kernel, any # modules or other data loaded with the kernel by the loader, and data # structures allocated before the VM system is initialized such as the # vm_page_t array. Each page table page maps 4MB (2MB with PAE). # options NKPT=31 -- So, that would be 124 MB for kernel and it's modules or other data loaded with the kernel by the loader (i.e; md image) In those nums, md image has only about ~45 MB for itself. Kernel itself and it's ..., needs ~80 MB I'll build a custom kernel, for "lifting" md image ... Domagoj Smolčić ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: OpenGrok for FreeBSD
2011/5/13 Zafer Aydoğan : > 2011/5/13 Gleb Kurtsou : >> On (12/05/2011 22:45), Zafer Aydoğan wrote: >>> Hello List, >>> >>> I've set up an OpenGrok service for the FreeBSD sources (current). >>> OpenGrok is a source code search engine and cross reference. >>> I'm updating the sources once a day. I'm a NetBSD developer and I'm >>> also maintaining http://nxr.netbsd.org >>> >>> Feel free to use it: >>> http://fxr.aydogan.net >> Thanks! >> >> What do you think about having index for different kernels in one place >> like now defunct http://grok.x12.su/source/ or >> http://fxr.watson.org/fxr/source/?v=HEAD >> > > That's possible, but OpenGrok contains the whole source tree > and not only the kernel. > Therefore I would group it with ports/, projects/, www/. etc. > > I didn't know about grok.x12.su, but I see its broken anyway. > > Zafer. > Hmm... there seems to be very little interest so far. Although this tool is mainly useful for developers, what is the correct mailing list to announce it ? Zafer. ___ 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"
