From cs_files.cpp:

457	// called at startup to ensure that if the client
458	// thinks a file is there, it actually is, and is the right size
459	//
460	void CLIENT_STATE::check_file_existence() {
461	    unsigned int i;
462	    char path[MAXPATHLEN];
463	
464	    for (i=0; i<file_infos.size(); i++) {
465	        FILE_INFO* fip = file_infos[i];
466	        if (fip->status == FILE_PRESENT) {
467	            get_pathname(fip, path, sizeof(path));
468	            double size;
469	            int retval = file_size(path, size);
470	            if (retval || (fip->nbytes && (size != fip->nbytes))) {
471	                delete_project_owned_file(path, true);
472	                fip->status = FILE_NOT_PRESENT;
473	                msg_printf(NULL, MSG_INFO, "file %s not found", path);
474	            }
475	        }
476	    }
477	}

Assuming the file exists and getting it's size always succeeds. The test in line 470 will be false if nbytes is 0 and the file will not be re-downloaded. If nbytes is something other than 0 the file's size must match that otherwise it will be re-downloaded.

Really? David has said that BOINC only checks the checksum on the initial download.

Well, that is correct* :P

* partially

In that case it looks like we either need to add a feature to BOINC, or send a zero sized file rather than a template.

---

That checking of file size was added last February, see changesets 25222, 25224, and 25225. BOINC 6.12.x and earlier don't have it.

                                                                    Joe

Remember that no BOINC project ever sends you work - you ask for it. How much you ask for is under your control.

How I wish it would be so.... ;)

Really? David has said that BOINC only checks the checksum on the initial download. Anyone know if that happens with the astropulse cmdline.txt file as well?

I edited AP config and it was persistent.
Perhaps wrong tag for this config file in descriptive xml ?

Really? David has said that BOINC only checks the checksum on the initial download. Anyone know if that happens with the astropulse cmdline.txt file as well?

I edited AP config and it was persistent.
Perhaps wrong tag for this config file in descriptive xml ?

The two config files are different.

Yours is supplied empty, and the user has to fill it in for himself or herself.

The CUDA file is supplied with content - a manual in the form of comment lines, and commented-out pro-forma suggested configurations.

BOINC handles them differently, and we're working through the implications with David now.

Does it account the fact that after editing AP config file will be non-zero too?

Also, is it really wise to ask for signature on such text, changeable files ?

Does it account the fact that after editing AP config file will be non-zero too?

Also, is it really wise to ask for signature on such text, changeable files ?

It doesn't ask for a signature, Eric has chosen to supply one.

The alternative <md5_cksum> would also detect "tampered with" - i.e. edited - files. Same problem.

Does it account the fact that after editing AP config file will be non-zero too?

Also, is it really wise to ask for signature on such text, changeable files ?

It doesn't ask for a signature, Eric has chosen to supply one.

The alternative <md5_cksum> would also detect "tampered with" - i.e. edited - files. Same problem.

Sure the same. What I trying to say - why we need to check these files integrity AFTER downloading. It's text files, not executables so viral threat not important.
As I read before in this thread MD5 checked only on download. Well, fine!
Download it unchanged then change. MD5 can still be in place but signature not needed!

Does it account the fact that after editing AP config file will be non-zero too?

Also, is it really wise to ask for signature on such text, changeable files ?

It doesn't ask for a signature, Eric has chosen to supply one.

I assumed xml creator was Eric ;) So, was it really wise to ask for signature in xml?
[I noticed that only now cause AP config not encountered this problem. But signature there just as unneeded as here!]

Maybe you should read about some of the reasons why security has been built into BOINC from the ground up?

http://boinc.berkeley.edu/trac/wiki/SecurityIssues

Maybe you should read about some of the reasons why security has been built into BOINC from the ground up?

http://boinc.berkeley.edu/trac/wiki/SecurityIssues

Richard, we speak about not data files, not executable files, we speak about TEXT CONFIG files. Please, highlight what of listed security issues applies to such files?

The single threat is buffer overran caused by specifically prepared binary file that will be substituted instead of text config file. If such buffer overrun will be done right app would perform some malicious code indeed. But it's not possible to allow file modification _AND_ protection from such modification. And this question should be considered on AP config introduction actually. Either project allows editable files or not.

Also, take into account that app_info anonymous mechanism allows to perform the same even more easy. So I really don't see how digital signature of SUCH type of files can improve security in any way?

EDIT: again, such kind of file, not task data file, not result file, not executable, not DLL...

Maybe you should read about some of the reasons why security has been built into BOINC from the ground up?

http://boinc.berkeley.edu/trac/wiki/SecurityIssues

Richard, we speak about not data files, not executable files, we speak about TEXT CONFIG files. Please, highlight what of listed security issues applies to such files?

The single threat is buffer overran caused by specifically prepared binary file that will be substituted instead of text config file. If such buffer overrun will be done right app would perform some malicious code indeed. But it's not possible to allow file modification _AND_ protection from such modification. And this question should be considered on AP config introduction actually. Either project allows editable files or not.

Also, take into account that app_info anonymous mechanism allows to perform the same even more easy. So I really don't see how digital signature of SUCH type of files can improve security in any way?

EDIT: again, such kind of file, not task data file, not result file, not executable, not DLL...

Yes, that's exactly the point that we (by which I include Eric, myself, and others) are discussing with David. BOINC has been designed so thoroughly with security in mind that the distinction between those classes - I agree, signature on code, MD5 on data - hasn't been extended to include editable text - which some security experts might describe as a loophole, if present.

If the project wants to go down the route which both you and Jason are pushing - with editable configuration of stock distribution applications, for optimisation without users taking full responsibility under anonymous platform, then BOINC has to do some serious thinking about the balancing point for security.

Ok, I'm glad that this question under discussion already with David.

Now I was able to download cuda22-based variant so more "practical" reports:

02/10/2012 18:40:31 SETI@home Beta Test [sched_op_debug] Server version 701
02/10/2012 18:40:31 SETI@home Beta Test Message from server: NVIDIA GPU: Upgrade to the latest driver to process tasks using your computer's GPU
02/10/2012 18:40:31 SETI@home Beta Test Project requested delay of 7 seconds

I use 263.06 driver. It's CUDA 3.2 compatible one.
So I was very surprised when got such statement (in red) from server.
Later server offered cuda22 flavors (as should be).
So, do we need such messages (disguising ones) from server? My driver OK.
Yes, it can't be used for cuda42 plan class. But others exist for this app.
Is it possible to do something with such false alarms or it's inevitable price for having few plan classes?

Yes, I got that message as well. It appears the BOINC thinks you should update your driver if your compute capability is to high for an app version, and I'd guess it also sends the same message if your driver revision is too high, too.

---

Running 0.99CPU + ...
This CUDA app requires so much CPU or it was unintentionally?
On my 2core CPU 1 NV GPU this 0.99 leads to nothing - 2 CPU tasks running + 1 GPU one (as should be IMHO cause CPU usage quite low). But with 2 tasks per GPU or 2 GPUs installed this would reserve full CPU core, right? Is it really needed for CUDA apps (instead of OpenCL CUDA can lower its CPU consumption, not?)

Raistmer wrote:

Ok, I'm glad that this question under discussion already with David.

Now I was able to download cuda22-based variant so more "practical" reports:

02/10/2012 18:40:31 SETI@home Beta Test [sched_op_debug] Server version 701
02/10/2012 18:40:31 SETI@home Beta Test Message from server: NVIDIA GPU: Upgrade to the latest driver to process tasks using your computer's GPU
02/10/2012 18:40:31 SETI@home Beta Test Project requested delay of 7 seconds

I use 263.06 driver. It's CUDA 3.2 compatible one.
So I was very surprised when got such statement (in red) from server.
Later server offered cuda22 flavors (as should be).
So, do we need such messages (disguising ones) from server? My driver OK.
Yes, it can't be used for cuda42 plan class. But others exist for this app.
Is it possible to do something with such false alarms or it's inevitable price for having few plan classes?

Eric J Korpela wrote:

Yes, I got that message as well. It appears the BOINC thinks you should update your driver if your compute capability is to high for an app version, and I'd guess it also sends the same message if your driver revision is too high, too.

If I remember correct, after I installed the latest recommended NVIDIA driver (306.23 WHQL) BOINC never got again this above red message.

With NVIDIA driver 275.33 my machine got the cuda22, 23 & 32 app.
After upgrade to 306.23 the cuda42 app was downloaded.


- Best regards! :-) - Sutaru Tsureku, team seti.international founder. - Optimize your PC for higher RAC (@ SETI@home Main). - SETI@home needs your help. -

---

Raistmer wrote:

Running 0.99CPU + ...
This CUDA app requires so much CPU or it was unintentionally?
On my 2core CPU 1 NV GPU this 0.99 leads to nothing - 2 CPU tasks running + 1 GPU one (as should be IMHO cause CPU usage quite low). But with 2 tasks per GPU or 2 GPUs installed this would reserve full CPU core, right? Is it really needed for CUDA apps (instead of OpenCL CUDA can lower its CPU consumption, not?)

On my machine (Intel Core2 Duo E7600 + GTX260 O/C, WinXP 32bit) it's *0.984 CPU + 1 NV GPU*.


- Best regards! :-) - Sutaru Tsureku, team seti.international founder. - Optimize your PC for higher RAC (@ SETI@home Main). - SETI@home needs your help. -

---

Finally I got quite exotic config running http://setiweb.ssl.berkeley.edu/beta/show_host_detail.php?hostid=25613
(as always - most issues were with BOINC client itself).

Host with AMD Winchester CPU (SSE2-only) and GT9400 (low end one) in PCI (!) slot (using PCI-E -> PCI adaptor).
It downloaded cuda32 flavor (I have 306.23 driver, CUDA 5 one, so all variants should be possible). And it works OK so far. Window redraw slowed but acceptable for internet browsing (maybe should disable GPU processing on video watching or tweak app params, will see).

Already have some suggestion for improvement:

In cudaAcc_initializeDevice(): Boinc passed DevPref 1
setiathome_CUDA: CUDA Device 1 specified, checking...
Device 1: GeForce 9400 GT is okay
SETI@home using CUDA accelerated device GeForce 9400 GT
pulsefind: blocks per SM 1 (Pre-Fermi default)
pulsefind: periods per launch 100 (default)
Priority of process set to BELOW_NORMAL (default) successfully
Priority of worker thread set successfully
Restarted at 1.32 percent, with Lunatics x41z, Cuda 3.20
Detected setiathome_enhanced_v7 task. Autocorrelations enabled, size 128k elements.
VRAM: cudaMalloc((void**) &dev_cx_DataArray, 1048576x 8bytes = 8388608bytes, offs256=0, rtotal= 8388608bytes
VRAM: cudaMalloc((void**) &dev_cx_ChirpDataArray, 1179648x 8bytes = 9437184bytes, offs256=0, rtotal= 17825792bytes
VRAM: cudaMalloc((void**) &dev_flag, 1x 8bytes = 8bytes, offs256=0, rtotal= 17825800bytes
VRAM: cudaMalloc((void**) &dev_WorkData, 1179648x 8bytes = 9437184bytes, offs256=0, rtotal= 27262984bytes
VRAM: cudaMalloc((void**) &dev_PowerSpectrum, 1048576x 4bytes = 4194304bytes, offs256=0, rtotal= 31457288bytes
VRAM: cudaMalloc((void**) &dev_t_PowerSpectrum, 1048584x 4bytes = 1048608bytes, offs256=0, rtotal= 32505896bytes
VRAM: cudaMalloc((void**) &dev_GaussFitResults, 1048576x 16bytes = 16777216bytes, offs256=0, rtotal= 49283112bytes
VRAM: cudaMalloc((void**) &dev_PoT, 1572864x 4bytes = 6291456bytes, offs256=0, rtotal= 55574568bytes
VRAM: cudaMalloc((void**) &dev_PoTPrefixSum, 1572864x 4bytes = 6291456bytes, offs256=0, rtotal= 61866024bytes
VRAM: cudaMalloc((void**) &dev_NormMaxPower, 16384x 4bytes = 65536bytes, offs256=0, rtotal= 61931560bytes
VRAM: cudaMalloc((void**) &dev_flagged, 1048576x 4bytes = 4194304bytes, offs256=0, rtotal= 66125864bytes
VRAM: cudaMalloc((void**) &dev_outputposition, 1048576x 4bytes = 4194304bytes, offs256=0, rtotal= 70320168bytes
VRAM: cudaMalloc((void**) &dev_PowerSpectrumSumMax, 262144x 12bytes = 3145728bytes, offs256=0, rtotal= 73465896bytes
VRAM: cudaMallocArray( &dev_gauss_dof_lcgf_cache, 1x 8192bytes = 8192bytes, offs256=56, rtotal= 73474088bytes
VRAM: cudaMallocArray( &dev_null_dof_lcgf_cache, 1x 8192bytes = 8192bytes, offs256=72, rtotal= 73482280bytes
VRAM: cudaMalloc((void**) &dev_find_pulse_flag, 1x 8bytes = 8bytes, offs256=0, rtotal= 73482288bytes
VRAM: cudaMalloc((void**) &dev_t_funct_cache, 1966081x 4bytes = 7864324bytes, offs256=0, rtotal= 81346612bytes
re-using dev_GaussFitResults array for dev_AutoCorrIn, 4194304 bytes
re-using dev_GaussFitResults+524288x8 array for dev_AutoCorrOut, 4194304 bytes

Perhaps, memory requirements for task remain the same since initial start. And case of changing app during single task run is rare case.
So, maybe it's worth to remove VRAM allocation listing from log when task was restarted and to print it only on initial start?
If we still care about size of stderr log ;)