Bugzilla Bug 149307

emerge of nvidia-drivers-1.0.8762-r1 (probably also other versions)
under kernel 2.6.18-mm1 resulted in a sandbox violation.

ACCESS DENIED unlink:    /usr/src/linux-2.6.18-mm1/astest11374.out
rm: cannot remove `astest11374.out': Permission denied

-------------------------- ACCESS VIOLATION SUMMARY --------------------------
LOG FILE =
"/var/log/sandbox/sandbox-x11-drivers_-_nvidia-drivers-1.0.8762-r1-11140.log"

open_wr:   /usr/src/linux-2.6.18-mm1/astest11374.out
unlink:    /usr/src/linux-2.6.18-mm1/astest11374.out
------------------------------------------------------------------------------

main line kernel up to 2.6.18 is working.

Reproduce:
  emerge nvidia-kernel under 2.6.18-mm1


Discussion & Solution:
  2.6.18-mm1 introduces a certain test in scripts/Kbuild.include.
  This test ("as-instr") creates a temporary file in the kernel source
directory. (see -mm patch x86_64-mm-detect-cfi.patch) Due to sandbox
restrictions this is forbidden.

 1. disable sandbox is okay in this case, as file is created by kernel and
temporary. Or
 2. comment out lines in containg the "as-instr" test in
scripts/Kbuild.include.
    (Not sure about impact of this)

 NOTE: Probably other external built kernel modules are affected of this,
because of using the KBuild system.

I can confirm that other kernel-modules are also affected by this.
Been having the same problem with my wireless-drivers...

Created an attachment (id=98519) [details]
Patch for fixing sandbox violations when compiling external modules for
2.6.18-mm1

This patch send the output of AS to /dev/null instead of a file which isn't
used and later removed...
Tested and working with nvidia-drivers

I can confirm this on -mm1, -mm2, and -mm3 as well.  I created a similar patch
for these kernels and the build is OK - however I have only actually tested
running the -mm2, and haven't been any major problems with this kernel in 5
days of uptime.

Has anyone contacted upstream about this?

Yes I already did. The maintainer of Kbuild system is looking into it.

*** Bug 150985 has been marked as a duplicate of this bug. ***

Suggest changing topic, happens with anything newer than .18 - so, .19
prepatches are also affected
sth like "with >= 2.6.18-mm1" ;-)

Any news from upstream on this? I noticed that 2.6.19-rc1 is affected :(

Indeed it is. No further response from upstream until now.
I suggest waiting for -rc2 and possibly remind again.
S.Ravnborg said there are other places in kernel similar to the described one.
So maybe he's checking all of them.

2.6.19-rc2 is also affected, so i guess it was not fixed

*** Bug 151456 has been marked as a duplicate of this bug. ***

*** Bug 151750 has been marked as a duplicate of this bug. ***

*** Bug 151913 has been marked as a duplicate of this bug. ***

Created an attachment (id=100051) [details]
as-instr-sandbox-fix-2.6.19_rc2-mm1.patch

This is an updated patch that applies to 2.6.19_rc2-mm1; they changed the
function to use mktemp (1) to make the temporary file now, instead of just not
having one...

I tried the patch but it doesn't work with mm-sources-2.6.19_rc2-r1.
vmware-modules denied to be compiled!!!

linux-2.6.19_rc2-mm2 still has the same bug

The patch for 2.6.18-mm1 works fine for mainline 2.6.19-rc2, too. The mktemp
change didn't make it there yet.

Unfortunately, there are no new comments in the LKML thread on this
(http://groups.google.com/group/linux.kernel/browse_thread/thread/26c390ec5ee7c9e1/e27f33d4c2fd1f09);
maybe the patch creators (Jan Peter den Heijer for 2.6.18-mm1 and 2.6.19-rc*
mainline, Calvin Walton for 2.6.19-rc2-mm1) should post their patches directly
there? Talking about a solution there is nice (dsd already did this), but
submitting a ready-to-apply patch usually has a better chance to be included in
the kernel.

The problem with submitting these patches is they do not actually solve the
issue at hand - the code that was added was clearly specifically designed to be
a failure log (it writes the output of a test to a file, then deletes the file
if the test was successful).  They are merely workarounds of the issue,
specific to sandbox.  This could probably be dealt with properly by modifying
the patch to change output to somewhere in $PWD instead of /dev/null -
(hopefully) writing the log to the work directory instead of the illegal
(/usr/src/linux-version) directory.  Though I admit I'm not familiar with the
internals of the kbuild system, except as far as hacking together the /dev/null
fix in the first place.

I'll try this method out later, when I have more time.

*** Bug 152893 has been marked as a duplicate of this bug. ***

Nick, I disagree (comment #18). The astest*.out files are being deleted
unconditionally, they cannot be examined later anyways. Up to now I have not
seen a reasonable argument for not using -o /dev/null at all.

Besides this, your idea (storing the tmp files in a better place than the
kernel tree) has already been implemented [1], but this implementation is
broken currently (see my LKML post on this [2]). Hopefully this makes it into
the mainline tree before 2.6.19 gets released...

[1]http://www.kernel.org/git/?p=linux/kernel/git/smurf/linux-trees.git;a=commit;h=51a4c9f79252752b82bc8cf6d4a856bbb81488c4
[2]http://groups.google.com/group/linux.kernel/browse_thread/thread/e55fd55506fbe840/2a7a69dbcc78232a

Okay, now I know the reason why they don't use -o /dev/null: "Because then when
the compilation runs as root some as versions will delete /dev/null on a error.
This has happened in the past." (Andi Kleen in
http://groups.google.com/group/linux.kernel/browse_thread/thread/e55fd55506fbe840/2a7a69dbcc78232a?tvc=2#msg_96d24319838d3868)

Okay, so if neither /dev/null nor the current solution work, what about Nick
Bowler  suggestion in comment #18, $PWD that is.

I think this solution would be relatively clean and expect it to be working.

Daniel, that's what's in the mainline githead ATM, it uses -o astest$$.out, ie.
writes to the CWD (cf.
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;h=4f5ff19b992b1f8a8db6f28a96cbace409db3baa;hb=209ad53bc19667a128d9c51beba873a5c62bff6e;f=scripts/Kbuild.include).

We rather need to get a path to the external module build tree ($(build-dir)?
Unfortunately this isn't defined yet when scripts/Kbuild.include is being
included in the main kernel Makefile, this would need to be changed, too...) --
or just do what the -mm implementation does: write to $TMPDIR (or /tmp if
$TMPDIR is empty).

Is using $(M) practical?

No need to make unrelated bugs depend on this one.. we know that all external
modules will fail with this problem until it is fixed

2.6.19-rc4-mm1 still fails.
I tested with vmware-modules.

Hamlet, without getting details on how vmware-modules "fail" for you, I can
just guess this is unrelated to this bug. There's a separate bug report on this
(bug #152322).

Well, I tested also with rtl8187.
Both failed same way as before, when I tested with 2.6.18-mm1.
Already deleted the kernel.
Next time, I will post the error message as well.
Sorry.

I just successfully emerged nvidia-drivers-1.0.9626 against an unpatched
2.6.19-rc4-mm1 with no violations.  Kernel boots and X starts.

Portage 2.1.2_rc1-r2 (default-linux/amd64/2006.1/desktop, gcc-4.1.1,
glibc-2.5-r0, 2.6.19-rc4-mm1 x86_64)
=================================================================
System uname: 2.6.19-rc4-mm1 x86_64 AMD Athlon(tm) 64 Processor 3200+
Gentoo Base System version 1.12.6
Last Sync: Thu, 02 Nov 2006 18:30:01 +0000
ccache version 2.4 [enabled]
app-admin/eselect-compiler: [Not Present]
dev-java/java-config: 1.3.7, 2.0.30
dev-lang/python:     2.4.3-r4
dev-python/pycrypto: 2.0.1-r5
dev-util/ccache:     2.4-r6
dev-util/confcache:  [Not Present]
sys-apps/sandbox:    1.2.18.1
sys-devel/autoconf:  2.13, 2.60
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10
sys-devel/binutils:  2.17
sys-devel/gcc-config: 1.3.14
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.17-r1
ACCEPT_KEYWORDS="amd64 ~amd64"
AUTOCLEAN="yes"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -march=k8 -pipe -fomit-frame-pointer"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config
/usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config"
CONFIG_PROTECT_MASK="/etc/env.d/binutils /etc/env.d/gcc /etc/env.d/java/
/etc/eselect/compiler /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild
/etc/terminfo /etc/texmf/web2c"
CXXFLAGS="-O2 -march=k8 -pipe -fomit-frame-pointer"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig ccache distlocks metadata-transfer parallel-fetch sandbox
sfperms strict"
GENTOO_MIRRORS="ftp://mirror.datapipe.net/gentoo"
LANG="en_CA.UTF-8"
LINGUAS="en ja"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress
--force --whole-file --delete --delete-after --stats --timeout=180
--exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage /usr/local/xfce44rc1"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="amd64 X a52 aac aalib acpi alsa audiofile bash-completion berkdb
bitmap-fonts bzip2 cairo cdr cgi cjk cli cracklib cups curl dmx dri dts dvd
dvdr dvdread elibc_glibc emboss encode exo expat fam fastcgi fbcon ffmpeg fifo
flac fontconfig fortran gd gdbm gif glitz glut gmp gpm gstreamer gtk gtk2
gtkhtml guile howl icecast iconv idn imagemagick imlib input_devices_evdev
input_devices_keyboard input_devices_mouse ipv6 isdnlog java jpeg jpeg2k junit
kernel_linux lcms libcaca libg++ linguas_en linguas_ja lua mad matroska mikmod
mng mouse mozilla mp3 mpeg musepack mysql ncurses nls nptl nptlonly nvidia ogg
openal opengl pam pcre perl php png posix pppd pulseaudio python quicktime
readline reflection ruby samba sdl session speex spell spl ssl
startup-notification svg sysfs tcpd tetex theora thunar-vfs tiff truetype
truetype-fonts type1-fonts udev unicode userland_GNU video_cards_nvidia
video_cards_tdfx video_cards_vesa vorbis x264 xine xinerama xml xml2 xorg xpm
xscreensaver xv xvid xvmc zlib"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LDFLAGS,
PORTAGE_RSYNC_EXTRA_OPTS

OK, then I will download mm patch again.
Maybe I made a mistake, or both vmware-modules and rtl8187 have some issue.
I will post the result later, maybe next week.
Thank you Nick for the info.

*** Bug 154478 has been marked as a duplicate of this bug. ***

*** Bug 154820 has been marked as a duplicate of this bug. ***

*** Bug 155157 has been marked as a duplicate of this bug. ***

I guess this is still not solved with 2.6.19-rc6?

True.

*** Bug 155638 has been marked as a duplicate of this bug. ***

*** Bug 155863 has been marked as a duplicate of this bug. ***

*** Bug 156264 has been marked as a duplicate of this bug. ***

*** Bug 156412 has been marked as a duplicate of this bug. ***

(In reply to comment #34)
> I guess this is still not solved with 2.6.19-rc6?
> 

it's not

Fixed in gentoo-sources-2.6.19 (genpatches-2.6.19-1)

So vanilla sources are not going to work?

No, we don't patch that kernel, sorry.

However (assuming no problems or objections appear) the patch will be merged
upstream sometime soon.

So you did send the patch to the LKML already? Can you give me a hint, so i
find that posting and the reactions?

(In reply to comment #44)
> So you did send the patch to the LKML already? Can you give me a hint, so i
> find that posting and the reactions?
>

http://lkml.org/lkml/2006/9/27/165

I didn't send the latest patch on yet, I am giving it a few days of testing in
gentoo-sources first. You can find it in the genpatches-base tarball.
http://dev.gentoo.org/~dsd/genpatches

*** Bug 156807 has been marked as a duplicate of this bug. ***

I have got the same problem (ACCESS VIOLATION ...) for app-misc/lirc-0.8.0-r7
after emerging sys-kernel/gentoo-sources-2.6.19. alsa-driver and nvidia-drivers
were installed without problems.

Must I report new lirc-related bug?

(In reply to comment #48) 
> Must I report new lirc-related bug?
> 
I did that and it was marked a duplicate of this bug, comment 47.

*** Bug 156839 has been marked as a duplicate of this bug. ***

(In reply to comment #41)
> Fixed in gentoo-sources-2.6.19 (genpatches-2.6.19-1)

I'm still getting the same sandbox violation with lirc-0.8.0-r7 and
gentoo-sources-2.6.19. I re-emerged gentoo-sources to make sure I had the
latest patches but it's still the same.

*** Bug 156889 has been marked as a duplicate of this bug. ***

*** Bug 150548 has been marked as a duplicate of this bug. ***

*** Bug 156899 has been marked as a duplicate of this bug. ***

*** Bug 156991 has been marked as a duplicate of this bug. ***

*** Bug 156994 has been marked as a duplicate of this bug. ***

*** Bug 157120 has been marked as a duplicate of this bug. ***

(In reply to comment #49)
> (In reply to comment #48) 
> > Must I report new lirc-related bug?
> > 
> I did that and it was marked a duplicate of this bug, comment 47.

As far i can see it's no longer a duplicate (but bugzilla doesn't remove the
comments), see bug 156807, should be solved by now.

(In reply to comment #21)
> Okay, now I know the reason why they don't use -o /dev/null: "Because then when
> the compilation runs as root some as versions will delete /dev/null on a error.
> This has happened in the past."

in case it makes our patch simpler, the Gentoo toolchains have all been fixed
to handle this properly (both binutils and gcc had this "feature")

*** Bug 157172 has been marked as a duplicate of this bug. ***

*** Bug 103100 has been marked as a duplicate of this bug. ***

This bug doesn't seem to be fixed, even with 2.6.19-r1 I am still getting
sandbox violations with pcmcia-cs

--------------------------- ACCESS VIOLATION SUMMARY
---------------------------LOG FILE =
"/var/log/sandbox/sandbox-sys-apps_-_pcmcia-cs-3.2.9_pre20050614-27835.log"

open_wr:   /usr/src/linux-2.6.19-gentoo-r1/astest27936.out
unlink:    /usr/src/linux-2.6.19-gentoo-r1/astest27936.out
open_wr:   /usr/src/linux-2.6.19-gentoo-r1/astest27940.out
unlink:    /usr/src/linux-2.6.19-gentoo-r1/astest27940.out
open_wr:   /usr/src/linux-2.6.19-gentoo-r1/astest27947.out
unlink:    /usr/src/linux-2.6.19-gentoo-r1/astest27947.out
open_wr:   /usr/src/linux-2.6.19-gentoo-r1/astest27951.out
unlink:    /usr/src/linux-2.6.19-gentoo-r1/astest27951.out
--------------------------------------------------------------------------------

Then file a bug for pcmcia-cs. Some packages such as lirc and
linux-wlan-ng-modules have needed additional fixing

bugs do get filed for other packages -- and immediate closed as a dupe of this
bug.  someone please make up their mind.

In general the bugs are dupes, and only in exceptional cases is the package
broken. If there is one for pcmcia-cs just reopen it.

Created an attachment (id=103496) [details]
linux-info.eclass patch

This patch against /usr/portage/eclass/linux-info.eclass is needed in some
situations.

I'd be really grateful for any testing here, including if things are currently
working for you. Apply this patch, then compile a few of your favorite modules
against gentoo-sources-2.6.19, and post success/failure reports here.

(In reply to comment #66)
> Created an attachment (id=103496) [edit] [details]
> linux-info.eclass patch
> 
> against gentoo-sources-2.6.19, and post success/failure reports here.
> 
It worked for me: gentoo-sources-2.6.19-r1 with these modules:
  =media-tv/v4l-dvb-hg-0.1-r2
  =app-emulation/kqemu-1.3.0_pre9
  =app-misc/usbirboy-0.2.1-r1
  =media-video/em84xx-modules-0.2.1
  =x11-drivers/nvidia-drivers-1.0.9631
  =media-sound/alsa-driver-1.0.14_pre20061130

added that patch to portage

*** Bug 157610 has been marked as a duplicate of this bug. ***

http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=347a00fb4ad2200f8f8331f8b366b1d84eff577d
should finally resolve the problem for vanilla kernels from 2.6.20 on.

*** Bug 157985 has been marked as a duplicate of this bug. ***

(In reply to comment #70)
> http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=347a00fb4ad2200f8f8331f8b366b1d84eff577d
> should finally resolve the problem for vanilla kernels from 2.6.20 on.

Downloaded patch, applied it to 2.6.19.1 and it works perfect!
Hooray!

*** Bug 158225 has been marked as a duplicate of this bug. ***

(In reply to comment #72)
> (In reply to comment #70)
> > http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=347a00fb4ad2200f8f8331f8b366b1d84eff577d
> > should finally resolve the problem for vanilla kernels from 2.6.20 on.
> 
> Downloaded patch, applied it to 2.6.19.1 and it works perfect!
> Hooray!
> 


can we merge this as a standard patch into the vanilla kernel, applied by
portage?

(In reply to comment #74)
> can we merge this as a standard patch into the vanilla kernel, applied by
> portage?

If you mean patching Gentoo's vanilla-sources then no, people expect it to be
indentical to kernel.org's release.

If you mean getting the patch into kernel.org's kernel then that's already
done; the next version (2.6.20) will include it.

(In reply to comment #74)
> can we merge this as a standard patch into the vanilla kernel, applied by
> portage?

It's _vanilla_, thats a codename for 'none of our patches, only what upstream
provide' ;) If you don't like it, use gentoo-sources

Please note that vanilla-sources is an unsupported kernel, if there are
non-ebuild bugs in it (of any kind) we will not fix it.

(In reply to comment #74)
> can we merge this as a standard patch into the vanilla kernel, applied by
> portage?

Just be patient a few days, 2.6.19.2 will contain the patch, too (thanks to
dsd).
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=blob;h=15afd3efc50a45689a8cb1160f9a0e66727d561f;hb=b0b06dc5239c4105d49c81291bd4d11e586384a3;f=queue-2.6.19/kbuild-don-t-put-temp-files-in-source.patch

*** Bug 158238 has been marked as a duplicate of this bug. ***

*** Bug 158532 has been marked as a duplicate of this bug. ***

*** Bug 159150 has been marked as a duplicate of this bug. ***

On amd64, I get with any 2.6.19 kernel I tried (including the most current
hardened-sources-2.6.19-r3 which runs fine with x86) always the same sandbox
violation.
I guess the patch had "only" fixed the x86 variant, and amd64 uses another
place to create the tempfile (apparently, the tempfile also has another name):
With all ebuilds containing kernel modules, I get the error:

--------------------------- ACCESS VIOLATION SUMMARY ----------------
LOG FILE = "/var/log/sandbox/[... snipped ...]"

open_wr:   /usr/src/linux-2.6.19-hardened-r3/-.gcda
open_wr:   /usr/src/linux-2.6.19-hardened-r3/-.gcda
--------------------------------------------------------------------------------

Of course, FEATURES=-usersandbox avoids the problem.

I am not sure whether I should open a new bug, because I am not able to reopen
this one...

(In reply to comment #82)
> On amd64, I get with any 2.6.19 kernel I tried (including the most current
> hardened-sources-2.6.19-r3 which runs fine with x86) always the same sandbox
> violation.
>...
I have exactly the same problem, every kernel >2.6.18.x still produces 
sandbox violations when emerging external modules.
Well, i'm also on ~amd64.

Please file a new bug for the gcda violation. It's not related to the bug
described here.

*** Bug 159714 has been marked as a duplicate of this bug. ***

*** Bug 159905 has been marked as a duplicate of this bug. ***

*** Bug 160078 has been marked as a duplicate of this bug. ***

*** Bug 160395 has been marked as a duplicate of this bug. ***

*** Bug 160511 has been marked as a duplicate of this bug. ***

Regarding Comment #70 , is there somewhere else I can get that file, I have
tried for days to get it and am always told the server load is too high. Also,
I'm curious, this bug is marked fix but from what I can tell it's not? Just a
thought.

Cheers!

Like ftp://ftp.muni.cz/pub/linux/kernel/v2.6/testing/linux-2.6.20-rc3.tar.bz2
dated Jan 1 2007?

(In reply to comment #90)
> I'm curious, this bug is marked fix but from what I can tell it's not? Just a
> thought.

gentoo-sources-2.6.19 is fixed, hence the bug is closed.

(In reply to comment #90)
> Regarding Comment #70 , is there somewhere else I can get that file, I have
> tried for days to get it and am always told the server load is too high.

http://overlays.gentoo.org/svn/dev/nelchael/sys-kernel/nelchael-sources/files/2.6.19-modules.patch

2.6.19.2 will be out Monday or Tuesday, and it'll contain the fix. Patience...
;-)

*** Bug 167785 has been marked as a duplicate of this bug. ***

vanilla 2.6.22.x is still failing for me.

anyone has the same issue?