Kernel Traffic #148 For 31 Dec 2001

Microsoft patents loading a trusted OS into a trusted CPU. The OS prevents untrusted applications from accessing Rights Managed Data.

http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2= HITOFF&p=1&u=/netahtml/search-adv.htm&r=1&f=G&l=50&d= CR99&S1=5,892,900.UREF.&OS=ref/5,892,900&RS=REF/5,892,900

I warned everybody the stuff was coming down the pipes. This is their method of dealing with content protection and it is going to pollute the hardware! The next thing down the pipes will be a requirement for IPC hardware encryption.

CPU(crypto)<->Memory(crypto)<->Framebuffer(crypto)
ata(clean)<->diskcontroller(crypto)<->Memory(crypto)<->CPU(crypto)
scsi(crypto)<->diskcontroller(crypto)<->Memory(crypto)<->CPU(crypto)
CPU(crypto)<->Bridge(crypto)<->Memory(crypto)

Just watch and see!

So you cant tap the data anywhere.

Think

encrypted music fed to an encrypted audio controller to speakers which decrypt and add watermarks

encrypted video decrypted and macrovision + watermarked only in buffers the CPU cant access

audio input that has legally mandated watermark checks and wont record watermarked data.

That is the dream these people have. They'd also like the OS to scan for "illicit" material and phone the law if you do, and to have a mandatory remote shutdown of your box

(and if you read the MS media player license anyone who agrees to it signed up to that)

I suggest you reread what happened to the implementor of DeCSS since you've obviously forgotten.

Whilst it's not practical for authorities to go 'get' every user of such things, there are several real world examples where they've gone after implementors, and distributors of such technology.

In a hypothetical scenario where we have sound drivers that provide ways to bypass watermarking and the likes (or even failure to implement whatever technology is deemed "necessary"), kernel.org becomes a distributor of "software to bypass access controls".

Amazing, just a few days since the Sklyarov release, and already people are forgetting this is a very real problem.

Who's forgetting? The scary part is that corporate fascism is basically the political reality in the U.S. (who is pushing very hard to export it to the rest of the world, for obvious reasons) today. Note that SSSCA failed not because of any freedom concerns, but because Microsoft and Intel didn't want the gov't to tell them what to do.

I don't say this lightly. However, I really think that the U.S. no longer is classifiable as a democracy, but rather as a plutocracy.

The Hotplug CPU patch for 2.5.0 is uploaded.

http://sourceforge.net/projects/lhcs/

This patch works on s390, s390x, x86 and ia64 architectures. It can also be applied against 2.4.16 with a little modification.

Down CPU
echo 0 > /proc/sys/kernel/cpu/<id>/online

Up CPU
echo 1 > /proc/sys/kernel/cpu/<id>/online

For ia64, number of CPUs to be initialized can be specified with "initcpus=<num>" option for elilo. With using the option, you can test real hot-add CPU function without a HW ready for hotplug.

One problem with following kernel development is that new APIs are nowhere really summarized outside of the list thread where they are developed (if there is a thread at all). So maybe there's this great new function that simplifies something in your driver, but you don't know about it and only stumble across it much later (like 50 dev kernel revisions) and wish you'd known earlier.

So someone should just collect the changes and post a summary to linux-kernel, now wouldn't that be useful ...

[Silence, far away keyboards can be heard having "So I take it you volun..." typed on them.]

... and I will try to do that for the kernel 2.5 revisions.

I have collected the API changes in 2.5.1 and summarized below. I just read the patch for all the *.h files, so I may have confused something (like not realizing something just moved instead of being new). I also don't know much about most of the areas I'm summarizing, any corrections are welcome.

These summaries won't serve as documentation except when it's short and simple. If there are big changes, I won't list every detail (I just remind you that there is something, you can read the source yourself). I will list changes which are global or at least apply to a whole subsystem.

You'll also find stuff that's pretty much the talk of the week on linux-kernel and therefore well known, but these summaries should also serve as a overview ("when was what introduced") in combination with the kernel changelogs for those who get into 2.5 later (yes, I will archive these summaries on the web when I get a few together).

So, here it goes:

include/linux/types.h:

Typedef sector_t for block device sector numbers introduced to allow making its size an option.

include/linux/cache.h:

New macro __cacheline_aligned_in_smp that expands to __cacheline_aligned on SMP and to nothing on UP.

include/linux/kernel.h:

New macro BUG_ON(condition) which is equivalent to
if (condition) BUG();

The condition is also hinted "unlikely" to the compiler, which gives better optimization on recent gcc versions even while decreasing typing work. (And if you update your code today, we'll throw in this set of kitchen knives which will stay sharp as a razor forever...)

include/linux/genhd.h:

get_start_sect() and get_nr_sects() on kdev_t introduced.

include/linux/mempool.h (new):

Memory buffer pools introduced. "Such pools are mostly used for guaranteed, deadlock-free memory allocations during extreme VM load."

include/linux/bio.h (new):
include/linux/blkdev.h:
include/linux/fs.h:
include/linux/highmem.h:

New block IO layer introduced.

include/linux/device.h (new):
include/linux/driverfs_fs.h (new):

Centralized driver model introduced.

drivers/scsi/hosts.h:

Scsi_Host_Template and Scsi_Host include new flag highmem_io, the flag use_new_eh_code is removed along with the old error handling interface.

drivers/scsi/scsi.h:

New sg list allocation functions scsi_alloc_sgtable() and scsi_free_sgtable(). Function initialize_merge_fn() renamed to scsi_initialize_merge_fn(). Function recount_segments() removed, scsi_init_io() added.

drivers/usb/hid.h:

HID class defines and functions added.

include/linux/usb.h:

Yes, there are lots of changes. I haven't sorted them out yet.

GENERAL CHANGES:

include/linux/cache.h:

New macro __cacheline_aligned_in_smp that expands to __cacheline_aligned on SMP and to nothing on UP.

include/linux/kernel.h:

New macro BUG_ON(condition) which is equivalent to
if (condition) BUG();

The condition is also hinted "unlikely" to the compiler, which gives better optimization on recent gcc versions even while decreasing typing work. (And if you update your code today, we'll throw in this set of kitchen knives which will stay sharp as a razor forever...)

include/linux/mempool.h (new):

Memory buffer pools introduced. "Such pools are mostly used for guaranteed, deadlock-free memory allocations during extreme VM load."

include/linux/device.h (new):
include/linux/driverfs_fs.h (new):

Centralized driver model introduced. This allows all devices independent of bus to be registered in a common tree and to improve power management. See Documentation/driver-model.txt.

BLOCK DEVICES:

include/linux/types.h:

Typedef sector_t for block device sector numbers introduced to allow making its size an option.

include/linux/genhd.h:

get_start_sect() and get_nr_sects() on kdev_t introduced.

include/linux/bio.h (new):
include/linux/blkdev.h:
include/linux/fs.h:
include/linux/highmem.h:

New block IO layer introduced.

SCSI:

drivers/scsi/hosts.h:

Scsi_Host_Template and Scsi_Host include new flag highmem_io, the flag use_new_eh_code is removed along with the old error handling interface.

drivers/scsi/scsi.h:

• New sg list allocation functions scsi_alloc_sgtable() and scsi_free_sgtable().
• Function initialize_merge_fn() renamed to scsi_initialize_merge_fn(). Function recount_segments() removed, scsi_init_io() added.

USB:

include/linux/usb.h:

• Lots of documentation added. Not really an API change but you might want to know.
• HID specific defines and functions moved into include/linux/usb.h.
• FILL_BULK_URB_TO and FILL_INT_URB_TO macros removed as they were not being used.
• New inline functions usb_fill_control_urb(), usb_fill_bulk_urb() and usb_fill_int_urb() replace the FILL_*_URB macros.

drivers/usb/hid.h:

HID class defines and functions moved here.

I looked into this a little while ago... never got a patch working 100% correctly...there was some discussions about it on the SGI Linux Scalability list (as far as i can tell, it was the -only- discussion on the SGI list, as the IBM list started about the same time.. ahhh, orphaned mailing lists..).. It was a quick-n-dirty hack, and only the beginnings of one at that...

i put a quick page up about it at http://www.deater.net/john/processorgroups.html

Conclusion: Could be done, not worth it for miniscule speed gains, could be much more of a benefit on NUMA machines, but the linux scalable scheduler's out there are probably a much better approach to doing the same thing...

anything lower than -O1 simply doesn't inline functions with an "inline" attribute. The result is that the inline functions in header files won't get inlined and the compiler will complain about missing functions at link time (or module insert time).

I'm actually surprised that 2.2 can be compiled with -O, AFAIK linux-2.2 also has a lot of inline functions in headers. I know from experience that -Os works for 2.4 kernels on ARM, I haven't tested it with 2.2 or x86.

http://www.treblig.org/Linux_kernel_source_finder.html

At this address you can find a web page where I'm trying to list the source of kernel source for all architectures and platforms. I'm currently missing a good reference for the s390 and cris architectures and some of the others are guesses on my part.

I'd be greatful for any suggestions/corrections/additions.

I intend to also add pointers to binutils/gcc/etc versions required. For those architectures which primarily use CVS I'd like to add some instructions for how to get a 'known good' set of sources (as opposed to current hackiest).