Re: [Hampshire] Kernel compilation
2009/9/17 Graeme Hilton : > Hi, > > This is one for the kernel hackers amongst you. > > I've got a system [1] on which I have installed CentOS 5.2. > Everything I need to use works out of the box with kernel 2.6.18-92. > > However, I've recently been asked to add the ability to synchronise > the internal clock with a GPS time source and have it keep very > accurate and precise time. So I bought a PXI GPS card [2]. This > presents itself as a serial port to Linux and provides data to > programs such as gpsd. This sounds good until you realise that the > timestamps provided are only accurate to about 0.5s - not good enough! > > The GPS also provides an output called PPS - pulse per second which is > accurate and precise to within 1us. This is connected to the DCD pin > on the serial port. > > The latest kernel 2.6.31 has just included some code to utilise this PPS > signal. > > So, I need to get this kernel compiled to work on my system. This > isn't proving to be easy! As I said earlier the 2.6.18 kernel from > CentOS works fine so I took this as the starting point and set about > compiling subsequent versions. Everything up to 2.6.27 works fine > using the default options. On 2.6.27 the kernel can't find the root > filesystem and so cannot complete booting. I think this is either due > to a missing SATA driver (although there's only one disk and grub > manages to get started from it) or a missing filesystem (I use only > ext3, which is compiled in). > > Attached is the boot sequence captured on the serial port from kernel > 2.6.27. It doesn't include the text that only appears on the screen > that refers to the kernel being unable to find a root filesystem. > > Any hints on how to get more information out of the kernel or on what > I should be looking for are more than welcome. > With regards to the timing, I am involved in the Galileo project, that is a European Global Positioning system like the USA's GPS. You have to maybe relax your accuracy expectations. Linking a PPS serial input to a non-real time Linux system is not going to give you an excellent result. What you are dealing with is in some ways similar to an IRIG-B signal. In order to get accurate time, one has to have three things 1) A precise free running clock. 2) The PPS signal to calibrate the clock. 3) A timestamp attached to the PPS signal (tells one which second the pulse is for) One uses the PPS signal to take a sample timestamp from the precise free running clock. This timestamp will not be too accurate on a Linux box because one has interrupt latency affecting when the PPS signal triggers a timestamp sample. This can be improved on embedded platforms, because one can remove hardware that might contribute to interrupt latency. (HDs and graphics cards, DMA transfers) So, over time, one has a number of timestamps taken at 1 second intervals. One then uses various filtering algorithms to arrive at correction values to apply to the free running clock. Then one uses free-running-clock, corrected with correction values = accurate time. Where is your "precise free running clock" ? Your final accurate time will only be as phase accurate as the free running clock. If your free-running-clock is not too accurate, all that the PPS signal will give you is accurate to +-1 second over the entire year. I.e. The accuracy will not drift over the year. free-running-clocks drift over time, which is why one's digital watch is only accurate to about +-10seconds per month. I just wanted to make sure that you understood what the PPS signal would give you. It does not make the time more instantaneously accurate, it reduces "drift". You need a better free-running-clock to make it more accurate instantaneously, which is why atomic clocks are used when one needs more accurate instantaneous time value. I would have opted instead for a stand alone GPS to NTP box, and simply used NTP on your Linux box. The end result is likely to be very similar. Kind Regards James -- Please post to: Hampshire@mailman.lug.org.uk Web Interface: https://mailman.lug.org.uk/mailman/listinfo/hampshire LUG URL: http://www.hantslug.org.uk --
Re: [Hampshire] New Linux-based phone
On Sat, Sep 26, 2009 at 12:00:17PM +0100, Alan Pope wrote: > 2009/9/25 Chris Simmonds : > > So, I stick by my original premise: the future of mobile devices is Linux. > > Which is a good thing. It is my hope that as time goes by they will become > > more open until we get to the point that you by the phone and then load > > whatever software you want onto it - just like a PC. We are a way off that > > but there are already some open platforms such as the Nokia webpads > > N777-N900 that have already been mentioned in this thread and of course the > > OpenMoko. > > > > Ahhh OpenMoko. > > Can you make calls on those reliably yet? Not that I'm aware of. > I had one for a while, and it was abysmal. A hackers plaything, not a phone. After seeing someone take 15 minutes (including a reboot) to (a) fail to make a call, and (b) extract a phone number from the thing so that I could make the call on my phone, I concur. Granted, he wasn't running the latest version of the OS, but still... My boss has one, and *does* have the latest OS on it, but it still sounds appallingly bad. It's not all bad news, though -- Android is available for the OM hardware. He's going to put that on it, just to see if it's any better. I'll report back. I think the major problem with the OpenMoko is the management at OpenMoko, Inc. They have a very good line in positive, uplifting, inspirational waffle that means absolutely nothing. They also seem (in the year or so that I was on the OM mailing lists) to be in the habit of changing the company strategy every month or two, and almost certainly caused the departure of at least one of their top technical people through a failure of management. I'm not surprised that a confused and barely-usable OS has resulted from such an environment. Hugo. -- === Hugo Mills: h...@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- What part of "gestalt" don't you understand? --- signature.asc Description: Digital signature -- Please post to: Hampshire@mailman.lug.org.uk Web Interface: https://mailman.lug.org.uk/mailman/listinfo/hampshire LUG URL: http://www.hantslug.org.uk --
Re: [Hampshire] New Linux-based phone
2009/9/26 Chris Dennis : > James Courtier-Dutton wrote: >>... >> Conclusion: A 3G phone should still be able to fall back to do GSM based >> GPRS. > > Thanks for that James. > > Is GPRS unusably slow for things like GPS (where the relevant bit of map > gets downloaded as you go)? > Depends how fast you're moving :) Cheers, Al. -- Please post to: Hampshire@mailman.lug.org.uk Web Interface: https://mailman.lug.org.uk/mailman/listinfo/hampshire LUG URL: http://www.hantslug.org.uk --
Re: [Hampshire] New Linux-based phone
2009/9/25 Chris Simmonds : > Actually I very much doubt that MS Windows Mobile has any significant device > support at all. http://en.wikipedia.org/wiki/Smartphone Symbian OS from Symbian Ltd. (50.3% Market Share Sales Q2 2009) RIM BlackBerry operating system (20.9% Market Share Sales Q4 2009) iPhone OS from Apple Inc. (13.7% Market Share Sales Q2 2009) Windows Mobile from Microsoft (9% Market Share Sales Q2 2009) Android from Google Inc. (2.8% Market Share Sales Q2 2009) http://en.wikipedia.org/wiki/Mobile_operating_system Symbian OS from Symbian Ltd. (46.6% Market Share Sales Q3 2008 iPhone OS from Apple Inc. (17.3% Market Share Sales Q3 2008) BlackBerry OS from RIM (15.2% Market Share Sales Q3 2008) Windows Mobile from Microsoft (13.6% Market Share Sales Q3 2008) Linux operating system (5.1% Market Share Sales Q3 2008) That looks "significant" to me. Whilst I don't disagree that Linux certainly has a place in the future mobile market, I don't think we should dismiss Symbian and WiMo as non-runners, given they have such market dominance. > So, I stick by my original premise: the future of mobile devices is Linux. > Which is a good thing. It is my hope that as time goes by they will become > more open until we get to the point that you by the phone and then load > whatever software you want onto it - just like a PC. We are a way off that > but there are already some open platforms such as the Nokia webpads > N777-N900 that have already been mentioned in this thread and of course the > OpenMoko. > Ahhh OpenMoko. Can you make calls on those reliably yet? I had one for a while, and it was abysmal. A hackers plaything, not a phone. Cheers, Al. -- Please post to: Hampshire@mailman.lug.org.uk Web Interface: https://mailman.lug.org.uk/mailman/listinfo/hampshire LUG URL: http://www.hantslug.org.uk --
Re: [Hampshire] New Linux-based phone
2009/9/25 Chris Dennis : > > One question, somewhat off-topic: how well do these high-tech phones > manage with accessing the internet over GPRS rather than 3G? Vodafone's > 3G coverage is pretty much absent out here in the frontier-land of the > Hampshire/Dorset border: will that make something like the N900 > pretty-much useless? > I have worked for a mobile network manufacturer in the past so I know a bit about this. GMS is the old style mobile phone standard. GMS networks support a packet service called GPRS. GPRS just stands for General Packet Radio Service. The newer standard is generally called 3G, but is standard based name is 3GPP or UMTS. Ref: http://www.3gpp.org/ 3G supports all the older services found on GMS, but introduces some new signalling and codecs, whereby it can send more data to the handset. So, for 3G, the packet service is still GPRS, it just has bigger bandwidth to play with and sometimes called HSDPA. 3G is designed to be able to fall back gracefully to GSM, so any 3G phone should be able to work in GMS mode without any problem. In fact, one should be able to start a phone call on 3G, and have the phone move to GSM without cutting off the call, but in practice, it might not work. Conclusion: A 3G phone should still be able to fall back to do GSM based GPRS. -- Please post to: Hampshire@mailman.lug.org.uk Web Interface: https://mailman.lug.org.uk/mailman/listinfo/hampshire LUG URL: http://www.hantslug.org.uk --
Re: [Hampshire] New Linux-based phone
Alan Pope wrote: > 2009/9/26 Chris Dennis : >> James Courtier-Dutton wrote: >>> ... >>> Conclusion: A 3G phone should still be able to fall back to do GSM based >>> GPRS. >> Thanks for that James. >> >> Is GPRS unusably slow for things like GPS (where the relevant bit of map >> gets downloaded as you go)? >> > > Depends how fast you're moving :) > > Cheers, > Al. > OK then, a different question: Given that Google are good at maps, would an Android phone be better at GPS than a Maemo or LiMo one? Yes, I know it all depends on what applications get developed. Does anyone have experience of this sort of technology? cheers Chris -- Chris Dennis cgden...@btinternet.com Fordingbridge, Hampshire, UK -- Please post to: Hampshire@mailman.lug.org.uk Web Interface: https://mailman.lug.org.uk/mailman/listinfo/hampshire LUG URL: http://www.hantslug.org.uk --
Re: [Hampshire] New Linux-based phone
James Courtier-Dutton wrote: >... > Conclusion: A 3G phone should still be able to fall back to do GSM based GPRS. Thanks for that James. Is GPRS unusably slow for things like GPS (where the relevant bit of map gets downloaded as you go)? cheers Chris -- Chris Dennis cgden...@btinternet.com Fordingbridge, Hampshire, UK -- Please post to: Hampshire@mailman.lug.org.uk Web Interface: https://mailman.lug.org.uk/mailman/listinfo/hampshire LUG URL: http://www.hantslug.org.uk --
Re: [Hampshire] New Linux-based phone
2009/9/26 Chris Dennis : > James Courtier-Dutton wrote: >>... >> Conclusion: A 3G phone should still be able to fall back to do GSM based >> GPRS. > > Thanks for that James. > > Is GPRS unusably slow for things like GPS (where the relevant bit of map > gets downloaded as you go)? > GPRS on GSM is slow but still works. A better option is to use a pre-installed map, like tomtom and garmin use, instead of google maps that load as they go. -- Please post to: Hampshire@mailman.lug.org.uk Web Interface: https://mailman.lug.org.uk/mailman/listinfo/hampshire LUG URL: http://www.hantslug.org.uk --
[Hampshire] How should the Open Source world handle new vulnerabilities?
When you first see this: "Linux Kernel 'sock_sendpage()' NULL Pointer Dereference Vulnerability" in an email or twitter it does not mean much at first glance. When you realise this is a kernel issue if you are a Linux systems administrator you will start scanning, thinking and then you read some more and realise this is serious. Then after 10 minutes the ramifications hit home depending on the systems you maintain and responsibility level on a scale between 1 (a single NetBook running UNR) and 10, plus some off the scale, some may know what I mean. My sentiments towards the Google security team are ambivalent. They were doing a job and did it well. I feel that the Open Source universe (and propriety) does not have a satisfactory model for announcing and fixing serious security vulnerabilities. The impact on users, business's, code maintainers, managers all the way through the various components of the producer to consumer can be heavy and I believe the process of announcement to fix could be much much better. The Google security team announcement on the 13th September will have had a negative impact on Open Source communities, like any accident does, but it seems that lessons ought to be learnt. A simple model could be: 1) Security vulnerability found. 2) Developer(s) contacted privately before announcement is made public. 3) Developer fix privately forwarded to major vendors. 4) Major vendors generate patch and make it available. 5) Public announcement is made. This point will have been made time and again, could or should a protocol be made law? If a vulnerability has taken a team of top security experts to discover then the likelihood of an individual or organisation finding the same vulnerability in the same amount of time must be slight in general. I find it difficult to see the benefits of making a vulnerability public before contacting the developer at least. Should a large multi-national like Google be allowed to uncover an error then tell the whole world when it feels like it? Is that ethical? Could it be seen as an act of aggression? >From now on I'm going to make a point of reading more about this process and following moves to change the current vulnerability discovery announce protocol. Any thoughts or information? Damian -- WWW http://www.diaser.org.uk - Open Source Data Vault Application - beta-1 RSS http://sourceforge.net/export/rss2_projnews.php?group_id=258272 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- Please post to: Hampshire@mailman.lug.org.uk Web Interface: https://mailman.lug.org.uk/mailman/listinfo/hampshire LUG URL: http://www.hantslug.org.uk --
Re: [Hampshire] How should the Open Source world handle new vulnerabilities?
2009/9/26 Damian Brasher : > > The Google security team announcement on the 13th September will have had a > negative impact on Open Source communities, like any accident does, but it > seems that lessons ought to be learnt. > > A simple model could be: > > 1) Security vulnerability found. > 2) Developer(s) contacted privately before announcement is made public. > 3) Developer fix privately forwarded to major vendors. > 4) Major vendors generate patch and make it available. > 5) Public announcement is made. > > This point will have been made time and again, could or should a protocol be > made law? If a vulnerability has taken a team of top security experts to > discover then the likelihood of an individual or organisation finding the > same vulnerability in the same amount of time must be slight in general. > As a kernel developer I can assure you that a lot of discussion occurs regarding security vulnerabilities, but most of it is never made public. Fixes go into the kernel without them being highlighted too obviously in the changelog. -- Please post to: Hampshire@mailman.lug.org.uk Web Interface: https://mailman.lug.org.uk/mailman/listinfo/hampshire LUG URL: http://www.hantslug.org.uk --
Re: [Hampshire] How should the Open Source world handle new vulnerabilities?
On 26/09/09 18:43, Damian Brasher wrote: > When you first see this: "Linux Kernel 'sock_sendpage()' NULL Pointer > Dereference Vulnerability" in an email or twitter it does not mean much at > first glance. > > A simple model could be: > > 1) Security vulnerability found. > 2) Developer(s) contacted privately before announcement is made public. > 3) Developer fix privately forwarded to major vendors. > 4) Major vendors generate patch and make it available. > 5) Public announcement is made. > > I find it difficult to see the benefits of making a vulnerability public > before contacting the developer at least. Should a large multi-national like > Google be allowed to uncover an error then tell the whole world when it feels > like it? Is that ethical? Could it be seen as an act of aggression? > Not all vulnerabilities are published immediately like this one. The recent DNS issue was carefully coordinated to allow fixes to be in place. However, even careful planning went wrong when someone leaked it :- http://www.schneier.com/blog/archives/2008/07/the_dns_vulnera.html I've posted on Julien Tinnes's blog asking why they didn't inform the kernel maintainers first, as you would think anyone serious about security would do. -- -- Discover Linux - Open Source Solutions to Business and Schools http://discoverlinux.co.uk -- -- Please post to: Hampshire@mailman.lug.org.uk Web Interface: https://mailman.lug.org.uk/mailman/listinfo/hampshire LUG URL: http://www.hantslug.org.uk --
Re: [Hampshire] New Linux-based phone
At 16:25 26/09/2009, you wrote: >2009/9/26 Chris Dennis : > > James Courtier-Dutton wrote: > >>... > >> Conclusion: A 3G phone should still be able to fall back to do > GSM based GPRS. > > > > Thanks for that James. > > > > Is GPRS unusably slow for things like GPS (where the relevant bit of map > > gets downloaded as you go)? > > > >GPRS on GSM is slow but still works. A better option is to use a >pre-installed map, like tomtom and garmin use, instead of google maps >that load as they go. People seem to have missed out Palms new WebOS that is supposed to based on Linux. The app store equivalent is supposedly closed off to developers apart from 1 exclusive company for now though. According to the NNsquad email list google have sent a cease and desist order against the main alternative ROM hacker so we will have to see if android remains as open as it once was. Martin N Owner of the bwfc yahoogroup and Co-Moderator of MiniDisc and amithlonopen yahoo groups. -- Please post to: Hampshire@mailman.lug.org.uk Web Interface: https://mailman.lug.org.uk/mailman/listinfo/hampshire LUG URL: http://www.hantslug.org.uk --
Re: [Hampshire] How should the Open Source world handle new vulnerabilities?
On Sat, Sep 26, 2009 at 06:43:18PM +0100, Damian Brasher wrote: > The Google security team announcement on the 13th September will have had a > negative impact on Open Source communities, like any accident does, but it > seems that lessons ought to be learnt. They first disclosed it to vendor-sec which is supposed to be a private list where such bugs are discussed and the timescales for public announcement are agreed. Unfortunately someone leaked the information and an exploit appeared in the wild. The Google employees concerned did not just announce it publicly. http://www.linux.com/news/software/linux-kernel/34926-linux-2631-rc6-released : "What was perhaps an interesting (if trivial) detail is that if it hadn't been for vendor-sec apparently leaking like a sieve, we'd have delayed the fix until the next -rc due to trying to be polite to vendors. So this may be one of the few time I'm actually happy about vendor-sec (even if it's because it failed to work the way it's supposed to ;), since I heartily dislike embargoes. [...] Linus" > A simple model could be: > > 1) Security vulnerability found. > 2) Developer(s) contacted privately before announcement is made public. > 3) Developer fix privately forwarded to major vendors. > 4) Major vendors generate patch and make it available. > 5) Public announcement is made. Unfortunately "developer(s)/vendor(s)" is a large group of people and it inevitably leaks. Additionally, many vendors handle reports badly, and various Linux vendors and even sometimes the Linux kernel developers have at times passed off potential code execution bugs as "denial of service" just because at first glance it looks like all you can do is crash the kernel. When a changelog appears with such a "denial of service" fix in it, this draws attention to exactly what the bug was and it has happened before that code execution has been possible after all. http://lwn.net/Articles/191080/ : "Reading the description above, some system administrators may feel that there is no particular urgency in applying this update. The risk that a rogue user would fill up a disk with core dump files may seem small, so an update fixing the problem - and which requires a system reboot to be effective - can maybe be deferred for a while. After all, the Linux kernel core dump code takes pains to avoid overwriting files with core dumps, so the real potential for harm is small. It's a denial of service bug. Except that it's not. All that is required is to create a program containing a string in the format understood by cron, send it over to /etc/cron.d, and use the bug to create a core dump there. Eventually cron will wander along, helpfully pick the line it understands out of the surrounding binary junk, and execute (as root) the commands found there. It is a simple and straightforward local root exploit; an example implementation has been posted to the full-disclosure list." So at every level there is potential for non-malicious (accident, incompetence, ...) mistakes to be made. I would suggest this happens far more often than people just shouting about exploits they have created. In this specific case, from leaked vendor-sec conversations, even Linus was not convinced that the bug was anything but a denial of service inherent in the Linux kernel design until after it leaked and someone made a local root exploit out of it. We can assume that Linus was not being dishonest or malicious but instead just didn't spot the potential implications until later on. > This point will have been made time and again, could or should a protocol be > made law? If a vulnerability has taken a team of top security experts to > discover then the likelihood of an individual or organisation finding the > same vulnerability in the same amount of time must be slight in general. No, in my opinion the procedure of reporting security bugs should not be codified in law, since (a) the threat of full disclosure is required to force some vendors into action, and (b) there are plenty of places in the world without laws so why make the life of legitimate law-abiding white hats that much harder. Black hats will do what they do regardless. Andy -- http://bitfolk.com/ -- No-nonsense VPS hosting You dont have to be illiterate to use the Internet, but it help's. -- Mike Bristow signature.asc Description: Digital signature -- Please post to: Hampshire@mailman.lug.org.uk Web Interface: https://mailman.lug.org.uk/mailman/listinfo/hampshire LUG URL: http://www.hantslug.org.uk --
