Sponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
LWN.net Weekly Edition for July 6, 2006Interview: Jim Gettys (Part II) The first part of our interview with Jim Gettys covered many aspects of the "One Laptop Per Child" (OLPC) system. With the second and final installment, we look at a number of other issues, including the software which will run on the system, security issues, and more.LWN: Time for a few questions about the mix of software you envision running on the OLPC systems. To start with, it appears that the system will be based on a pared-down Fedora-based distribution?
To date, Red Hat are the ones who are putting serious engineering into
OLPC and doing most the heavy lifting on the base system, and have
assembled a first rate team, including Dave Woodhouse and Marcelo
Tosatti.
Red Hat is putting together a pared-down Fedora derivative distribution. The community being what it is, I expect others will put other distributions on the machine as well, given that the OLPC system is an open platform. I'm not sure such duplication is worthwhile, but I'm resigned to it. I *really* urge everyone to cooperate very strongly at the level of the software for the kids, no matter what the underlying distribution in the long term. This project is fundamentally about kids learning and helping the world; not about free software. That being said, *free software enables the kids to learn computing in a way that they cannot learn it on closed proprietary platforms*. We are therefore very much part of the free and open source software community. Chris' team is putting together a python based environment (into which conventional applications can be embedded) aimed at young children, temporarily called "sugar" (more information can be found in postings here, here, here, and here); conventional GUI's are not good for children still learning to read. I have a 8 year old son and an 11 year old daughter, and so have seen over the last few years first hand how unsuitable conventional desktops are for young children. The Sugar environment, by using the Avahi library (zeroconf/mdns technology), will show the presence of people on the network as a fundamental aid to building collaborative applications. Collaboration is fundamental to learning: most kids learn from their peer group, and teachers serve as the guides. Will the systems as shipped be 100% free software?
OLPC itself only plans to ship free software at this time.
If not, what other code do you think you might include?
Let me give a concrete example: some countries have coded some
educational content in Flash.
We are strongly recommending that future content not be created in closed format like Flash, whose format is closed, lack tools for manipulation, and present major problems for accessibility tools. But some countries have such content today, and need to use it immediately. And since there is so much flash content on the web, it would not surprise me if countries arrange for Flash to be installed, even if they do not have existing educational content in Flash. We are encouraging everyone to use open standards based formats, and to release useful content under appropriate free creative commons and free software licenses. Reality being what it is, even if we had veto power over software on the machine (which we certainly don't), we'll see such software included on the machine by the time it in children and teacher's hands; just not distributed from OLPC, but added on afterwords. Is it true that there will be no package manager on this system?
This is an area where we continue to have discussions. Whether it is
like conventional packaging systems or not is unclear right now. Time
will tell.
If so, will there be any provision for customizing the system software mix, installing localization data, or updating software?
Of course. There has to be. By middle school, kids are taking different
courses and languages. Some kids have special needs, either advanced or
the opposite. One of the major advantages that an OLPC has over
conventional books, is the possibility to bring much more content
appropriate for each child to that child, who live in places which lack
libraries we find in U.S. and other developed nation's schools.
A system like this clearly needs a good set of education applications - an area where free software has not traditionally been strong. What sort of applications are you looking at in this area, and might any missing pieces come from?
There is much software sold claiming to be "educational" software, which
isn't. The reality is that there aren't all that many good educational
applications on *any* platform. The pickings are pretty slim.
We believe all children learn by doing, and should be authoring content, not only passively reading unchangeable engraved in stone content. We are placing some major bets on wiki technology as a base for this. (Not wiki markup though!). I'd also like to draw your attention to a web site: logowiki.net. Content doesn't have to be static at all, and content can be programs, even programs for young children. The ability to run simulations and manipulate the starting conditions is a major tool to learning. And one more hardware feature is unique to our machine: you can choose to use the audio input as a direct analog input, allowing direct measurements be made with very cheap sensors (e.g. photodiodes, accelerometers, etc.). With the likes of Seymour Papert and Alan Kay involved, I think we're in for some fun stuff. For example I saw a demo this week of a wonderful music application called TamTam, that Jean Piche' et al in Canada and Ireland are building using the Csound synthesis software Barry Vercoe originally developed. Will the systems include a compiler, or, failing that, an interpreter for a language like Python?
Of course.
At a minimum, we expect Logo, javascript and python to be present, and compilers as well when needed by interested kids. Learning programming, though, is best done in interpreted language environment, rather than compiled languages. Certainly C++ should never be a child's first computer language. In general, is hacking one of the uses to which you think these machines will be put?
Hacking, in the original positive sense of the word
(see the Jargon File), we certainly
believe should be strongly encouraged in interested children: computing is a
fundamental skill in today's society. For others, computers will just be a tool;
their pen and paper.
Do you expect that the kids will have root access on their systems?
Yes: we want children to be able to learn computing, if they are interested. For the kid's
systems, we want them "easy to fix", rather than "hard to break". For the school's
servers, a shared resource, we want them to be "hard to break" *and* "easy to fix",
and are exploring technologies like those developed by Planetlab.
Being root on your own personal machine is fundamentally different than having any access to information on the network you should not have. Project Athena, at MIT (where such technologies as Kerberos, X11, the first network IM system, among others), demonstrated this even 20 years ago: on those systems having root access does not get you access to anything but the services you had access to as an individual user. The root password on those systems has been posted for years: it just doesn't matter, if you do your homework properly. The plan to use LinuxBIOS is interesting. Are there reasons driving that choice (beyond cost)?
Cost isn't a real factor in this decision. The royalty rate of a conventional BIOS
is in fact very low.
Capability:
Some years ago when I was working on Linux on the iPAQ, we had a 12 year old who was hacking on our boot loader, and learning tremendously as a result. Those outstanding kids should also have the opportunity to learn computing deeply. Is LinuxBIOS ready for this sort of deployment?
We think so. It's already deployed commercially at pretty high scale on a number
of products. And the very fast suspend/resume we may need to implement requires complete
freedom of action at all levels of the machine.
Millions of identical systems, mostly lacking professional administration, would seem like a magnet for malware authors. What sort of thought is being put into preventing these systems from becoming worm carriers and large-scale zombie networks?
I doubt they will be exactly identical (other than hardware): language is but one of
the obvious differences; children take different courses, and study different languages.
And if they need professional administration, we've failed. Our view is that systems cannot require professional administration at a local level: we could not deploy quickly on this scale and have sufficient expertise if this were required. Part of the IPv6 argument is exactly to allow administration to scale and to simplify administration. Eugene Kaspersky, who has been predicting Linux doom for years, is now saying that the OLPC will result in a new wave of malware from the developing world. Do you find this outcome plausible? Why or why not?
I don't find Mr. Kaspersky's arguments plausible, for a number of reasons.
We certainly are aware that security is a challenge: young children are not noted for choosing and keeping secure good passwords, and we are looking at other methods as a result. We expect to deploy SELinux protecting the "standard" network services on our machines to help protect against day-0 attacks, to prevent bad guys from successfully attacking our systems and prevent such people from using our systems as a point of attack. And keeping our systems up to date automatically is obviously essential. As far as malware from the developing world: malware for what? Malware is very rare on Linux or Apple's OS/X systems: both systems break out of the starting gate much less insecure than Windows, and writing malware for either is inherently more difficult. And if Mr. Kaspersky's worried about kids in the developing world writing malware on the OLPC systems to attack Windows, how are the kids going to test such Windows malware since our machines are running Linux? Malware authors working for profit (e.g. stealing passwords and accounts) are certainly going to be older than our kids, and will find a standard Windows system a much more productive development environment, and internet cafe's a much more anonymous place to launch attacks than our school environments. Lastly, both at the school servers, and the networks supporting them, we have good places to prevent, stop, and track down any such attacks, much better than you'd find in the anonymous world of Internet Cafe's where anyone can pay for anonymous usage. And high bandwidth back-haul from schools is unlikely to be very common, limiting the problem if it does occur. There are much better targets for zombies: e.g. systems all over the developed world where each machine has a high bandwidth broadband connection, rather than a kid's machine on a large shared mesh network back connected through a similar single connection. Per compromised machine, there may be a difference of a hundred to one of useful bandwidth. Seems to me that Mr. Kaspersky knows not what he writes of, and is trying to gain eyeballs on his stories by sensationalism. Given the state of the art, the chances of a security vulnerability turning up in the shipped OLPC systems must be near 100%. What happens then? How will OLPC users obtain and install security fixes?
Our challenge is not just the kid's machines and operating system, but also deployment
of server machines in all the schools, to cache distribute software and educational content to all of them.
We expect the kids machines to be updated from school servers, and possibly from other kid's systems. The closest management tools to what we need appears to be many of the technologies developed by PlanetLab: the commercial distributed content systems are unlikely to work, presuming as they do that systems are in data centers and always/usually available over high speed networks. At our scale, (and with the highly variable Internet connections we expect), a presumption of constant connectivity seems untenable. We'll know more as we look into this aspect of the project more fully over the next few months. Some commenters on LWN have expressed concerns that many of these systems may be stolen from the children and used for (or sold to fund) rather less wholesome ends. Is this an issue which the OLPC team has thought about?
Yes, we've thought about it quite a bit.
How could this risk be minimized?
First, we intend that the systems be instantly recognizable as kid's systems, not only so
that kids like them and value them more and take care of them carefully, but also so that
adults with machines in their possession may be asked questions about whether they
should have the machine. And these systems are physically sized for smaller children,
our primary "customers"; while adults can use them, it is less desirable than a bigger
machine might be.
Second, public education about these distinctive systems is a topic we've discussed with deployment countries as a deterrent. Third, by saturating each area during deployment, rather than distributing machines piecemeal, we can expect much better mesh networking performance, but also less child from child theft. Fourth, there will be a commercial version of the machine (that will look quite different) at some point in the project, to reduce the pressure for these unique systems. As I explained before, there are quite a few ways in which these machines are unique, so we'd like there to be fewer reasons for theft, by enabling a commercial version. These commercial machines may also help cross subsidize the children's machine, for as long as the market might bear such a price differential. Fifth, by its nature, there is a network MAC address in each machine that can aid its tracing, in the case of theft, once a system is recovered. We are, however, very concerned about the child's privacy and safety, and so don't want the systems to go around broadcasting the hardware MAC address in the normal case. And we're exploring some other possible identity systems as well that may help in this area. A huge "thank you" is due to Jim, who clearly took a great deal of time to respond to LWN's questions in such detail.
A software patent attack on Red Hat Red Hat is long been a likely target of legal attacks; the company has a high profile, customers who can be threatened, and a bank balance which is worth the trouble of coveting. So it is not entirely surprising that a small company called FireStar chose Red Hat as the target for a software patent suit. It is unlikely to be the last.The patent in question is US patent 6,101,502, which is said to be infringed by the "Hibernate" product acquired with JBoss. This patent, filed in 1998, asserts the following claim:
A method for interfacing an object oriented software application
with a relational database, comprising the steps of:
In other words, this is a patent on an object-oriented wrapper for data in a relational database management system. To say that this idea is obvious is to understate the case. The first thing any object-oriented programmer does is to create classes to encapsulate the data to be manipulated; of course such a programmer would create a series of objects to represent relations in an RDBMS. One would expect that it would be possible to examine a large number of object-oriented programs which work with RDBMS systems and not find a single one which lacks this sort of impedance-matching layer. So the world did not need to wait until 1998 for the authors of this patent to come up with this idea. Thus, if Red Hat puts up a suitable level of resistance, it should be able to get this patent invalidated. But there is little comfort to be found there. There are thousands of these patents in circulation and no shortage of trolls willing to exploit them to line their own pockets. One such case can be beaten down; but there will be more than one. Perhaps many more. Software patents have long been seen as a serious threat to free software; now we are beginning to see this threat come to life. [As an aside, there have been some allegations that at least one Red Hat employee engaged in pro-patent lobbying in Europe last year, and that, as a result, this suit represents a sort of poetic justice. See this week's Letters Page for a discussion of both sides of this issue. The statement from FFII found there would appear to establish that Red Hat's position on software patents has been clear and consistent.]
SCO: the end gets closer Your editor misses the Good Old Days, when outlandish SCO court filings were a daily occurrence, Darl McBride's fulminations were daily press fodder, and the occasional corporate teleconference could be counted upon to keep blood pressures high in the community. One could almost get nostalgic about plowing through yet another blurry PDF file filled with bizarre legalese. The world feels a little lonely now that Chris Sontag no longer shows his face in public.Actually, the above paragraph is a bunch of hot air; LWN is more fun without the SCO Group on the front page. But a certain morbid interest suggests that the SCO end game should occasionally be chronicled as important milestones unfold. One of those milestones was passed on June 28, when Judge Wells issued an order in SCO v. IBM. For those of us who have been patiently (or, perhaps, not so patiently) waiting for SCO to feel the consequences of its lack of discretion in public and its lack of any actual evidence of wrongdoing, the time has finally come. The SCO Group, remember, has been under court order for some time to disclose "with specificity" exactly what it thinks IBM did wrong. SCO's final answer took the form of 294 "specifics," described in a sealed filing. IBM responded with a motion saying that most of SCO's claims lacked the required level of specificity and should simply be thrown out, regardless of whether they might have any merit or not. Judge Wells's order was the court's response to this motion. After reviewing (at length) SCO's history in the case, Judge Wells concluded that SCO's claims were, indeed, not specific enough. Not enough for the court, but also not up to the level that SCO expected from IBM. Thus:
Given SCO's track record in this case, the court is certain that if
IBM had simply provided line information without version and file
information for "methods," SCO would have filed motions to compel
complaining about IBM's lack of specificity. The court cannot find
any reason why SCO should not be held to the same level of
accountability that SCO held IBM to. Thus, SCO should have supplied
not only line but version and file information for whatever claims
form the basis of SCO's case against IBM.
Failure to meet the specificity requirement is not enough to throw the claims out, however; a couple of other criteria must be met. One is that the failure was willful - that SCO deliberately failed to disclose that information. According to Judge Wells, that is, indeed, the case:
There is no evidence before the court to indicate that SCO lacked
the ability to comply with the court's orders. In fact, given SCO's
own public statements outlined in part supra, it would
appear that SCO had more than enough evidence to comply with the
court's orders....
Based on the foregoing, the court finds that SCO has had ample opportunity to articulate, identify and substantiate its claims against SCO. The court further finds that such failure was intentional and therefore willful based on SCO's disregard of the court's orders and failure to seek clarification. In the view of the court it is almost like SCO sought to hide its case until the ninth inning in hopes of gaining an unfair advantage despite being repeatedly told to put "all evidence . . . on the table." One might well argue that this is a charitable view of SCO's behavior. But it makes one thing clear: the court has noticed the discrepancy between SCO's public bluster and the evidence it has actually put forward in the trial. Finally, IBM had to show that it was being hurt by SCO's failure. The court had no trouble buying IBM's argument that it would be hard put to defend a case where it is unaware of what it has done wrong. The troubles go beyond that, though:
Without more specificity than SCO has provided some very important
questions that could materially impact this case are nearly
impossible to answer. For example, is the code that comprised the
method or concept still in use in Linux? If not, then damages may
become nominal instead of in the billions. Or, it may be possible
that the code comprising a method or concept was already disclosed
pursuant to some other license such as the BSD License.... Without
the code, however, there is no way to ascertain exactly what the
impact is of prior disclosures that may involve the code at issue
in the instant case.
The end result is that IBM won big: 182 of SCO's claims have been summarily tossed out - just ten short of what IBM had asked for. On the order of 100 claims remain. This ruling is clearly a major blow to SCO's case, but just how major is hard to say: since SCO's claims remain under seal, we cannot know which ones have survived. But it is clearly a much shorter list, with much of the "methods and concepts" vapor removed. And, just as importantly, the court appears to have concluded that SCO has been given plenty of rope at this point; with luck, this whole episode might just reach a conclusion sometime soon.
Page editor: Jonathan Corbet Security Prelink and address space randomization Prelink (PDF) is a popular tool used to decrease program load time, shortening system boot time and making applications start faster. Developed by Jakob Jelinek at Red Hat, prelink relocates libraries on disk to save dynamic linking time. When the dynamic linker loads a dynamically linked ELF binary, it has to also load and link all of the libraries before executing the program's entry point, _main(). This process involves relocating libraries—changing all addresses referenced in the library to reflect the actual addresses in memory. Relocating libraries involves iterating through each address in the library and replacing it with the real address as determined by the library's location in the process's virtual address space. Most relocations happen in the symbol table and PLT; but in rare cases there are also .text relocations which require fixed-position executable code to be patched in a slightly slower process. The relocation process will slow down an application's launch. In order to speed up the process, prelink relocates the libraries ahead of time. This is done by scanning every executable to be prelinked, generating a graph of libraries that will be loaded at the same time as other libraries, and then calculating target addresses for each library at such that it will never be loaded at the same address as other libraries. These offsets are then stored in the shared object files themselves, and the symbol tables and segment addresses are all adjusted to reflect addresses based on the chosen base address. Once prelink has done its job, the dynamic linker no longer has to concern itself with relocation. Libraries are loaded at the address specified in the library header and the symbol table is already correct. If anything forces the library to be loaded at a different address, then the library is relocated appropriately as usual; otherwise we can say goodbye to the load-time overhead of relocating libraries. Kernel facilities supplying address space layout randomization for libraries cannot be used in conjunction with prelink; to do so would require relocating the libraries, defeating the purpose of prelinking. Address space randomization is a core feature of secure systems such as OpenBSD, Adamantix, Hardened Gentoo, Fedora Core, and Red Hat Enterprise Linux. It has appeared as part of PaX as well as part of Ingo Molnar's Exec Shield, and has been accepted into the mainline kernel as of 2.6.12 after submission by Arjan van de Ven. The simple purpose of address space randomization is to make it more difficult to perform certain classes of attacks by changing where in memory important segments for the attack are loaded. If an attacker wants to execute injected shell code or manipulate the program to execute out of order, he obviously has to know where that code is. By shuffling memory segments around, these attacks become quite difficult; the chances of successful attack are mathematically described in the PaX documentation and Wikipedia. In an attempt to restore some of the benefits of address space randomization, prelink is capable of randomly selecting the addresses used for prelinking. This makes it more difficult to perform certain attacks on a system, because the addresses used are unique to that system. This approach is, however, less effective than per-process randomization because the addresses stay constant until prelink is run again. There is another implication that has to be examined with prelink. To understand this implication, let us first review a feature of prelink by examining the load address of the C standard library in two processes: a user-owned 'cat' and a root-owned 'bash'. The C standard library is interesting because, in practice, virtually all return-to-libc attacks utilize it exclusively. user@icebox:~$ cat /proc/self/maps | grep libc | grep r-xp 4df2e000-4e053000 r-xp 00000000 08:07 81197 /lib/tls/i686/cmov/libc-2.3.6.so user@icebox:~$ sudo -s root@icebox:/home/user# cat /proc/$$/maps | grep libc | grep r-xp 4df2e000-4e053000 r-xp 00000000 08:07 81197 /lib/tls/i686/cmov/libc-2.3.6.so Closely examining these quickly verifies that the address of glibc's executable code is the same between these two processes; this is consistent with the behavior of prelink. Because the library itself is relocated ahead of time, there is a preference for the dynamic linker to load it at that address. Examination of libc itself yields the below. user@icebox:~$ readelf -S /lib/tls/i686/cmov/libc-2.3.6.so | head -n 6 There are 64 section headers, starting at offset 0x12d114: Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .note.ABI-tag NOTE 4df2e154 000154 000020 00 A 0 0 4 Computing 4df2e154 - 154, the address and offset taken from any given non-NULL segment, yields 4df2e000, the base address of libc. This makes sense; prelink rewrites the segment and symbol addresses for the library based on a specific load address, and the dynamic linker loads the library at that address to avoid relocating it. Further, any program that links with libc has to be able to read libc, and will thus be able to derive the same information. All of this means that any program on the system using any prelinked library will be able to leak information about higher privileged tasks using the same library. This allows any attacker able to gain any form of local access—or more directly any ability to read libc—to gain information about the address space layout of higher privileged processes, including the load address of libc. As we know, this information is extremely valuable to an attacker wanting to exploit a privileged process without brute forcing library load addresses. This vulnerability only applies to attackers with local access; but this is not an unreasonable requirement. Many web hosting companies give local shell access or allow PHP; either of these can be used to remotely fetch a copy of libc. Due to the nature of the dynamic linker and sane security design, the dynamic linker is exactly as privileged as the process it is starting; therefor, even the most stringent mandatory access policies on systems such as SELinux, grsecurity, or AppArmor cannot prevent this attack. Besides avoiding prelinking, there is one other way to prevent this information leak from being exploited. All processes linked to a prelinked library need access to the library file and load that library at the same address; the point of exposure is the use of the same copy of the library. In order to prevent information leaking, then, you must have separate copy of each library common between any two programs you don't want to leak information about each other. This can be done with Xen, chroot jails, UML, or simply isolated machines, as long as the directory hierarchies are individually prelinked with prelink randomization. Each system will have a different set of addresses from every other system in this scheme. This of course requires more hardware, more disk space, more management, more memory, and more work. The direct implications of this information leak depend on your exact security concerns. A web hosting company, for example, may not want to run prelink on its servers, given the risk of effectively losing the benefit of address space randomization. A home desktop, on the other hand, may only have to worry about a trojan using the information leak to stage an attack on a system service such as cups or dbus—and should probably worry about /proc/PID/maps first. While these are both essentially the concern of an attacker with local access, the likelihood of attack and the value of potential damages are different. The prelink tool gives a useful decrease in program load time, and can help users reach their desktop and the programs they need to run more quickly. It does however have some unfortunate repercussions that must be examined, especially in security-sensitive environments relying on address space randomization.
New vulnerabilities acroread: unspecified security problems
kernel: denial of service
kiax: arbitrary code execution
openoffice.org: several vulnerabilities
opera: integer overflow and SSL spoof
tikiwiki: multiple vulnerabilities
Updated vulnerabilities asterisk: buffer overflow
binutils: buffer overflow
busybox: insecure password generation
bzip2: race condition and infinite loop
ktools: buffer overflow
courier: denial of service
cpio: arbitrary code execution
vixie-cron: privilege escalation
Cyrus-SASL: DIGEST-MD5 Pre-Authentication Denial of Service
EnergyMech: denial of service
freetype: integer overflows
gdb: multiple vulnerabilities
gdm: improper file permissions
gnupg: remote denial of service
gzip: arbitrary command execution
Hashcash: possible heap overflow
horde: missing input sanitizing
ImageMagick: heap overflow vulnerability
kdebase: local root vulnerability
kdebase: privilege escalation
kdelibs: kate backup file permission leak
kernel: multiple vulnerabilities
kernel: netfilter memory corruption
kernel: multiple vulnerabilities
kernel: information disclosure
libgadu: memory alignment bug
libgd2: denial of service
libmms: buffer overflows
libpam-ldap: authentication bypass
libtiff: buffer overflow
mozilla products have multiple vulnerabilities
mpg123: buffer overflows
mutt: IMAP namespace buffer overflow
mysql: denial of service
MySQL: logging bypass
ntp: uses wrong gid
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||