Re: [Beowulf] RHEL7 kernel update for L1TF vulnerability breaks RDMA
Thank you On August 19, 2018, at 2:10 PM, Chris Samuel wrote: On Monday, 20 August 2018 6:32:26 AM AEST Jonathan Engwall wrote: > I am not shocked that my previous message may have been removed. To clarify: nothing has been removed to my knowledge. Your email is in the list archives. http://beowulf.org/pipermail/beowulf/2018-August/035219.html All the best, Chris (just woken up) -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC ___ Beowulf mailing list, Beowulf@beowulf.org sponsored by Penguin Computing To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf ___ Beowulf mailing list, Beowulf@beowulf.org sponsored by Penguin Computing To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
Re: [Beowulf] RHEL7 kernel update for L1TF vulnerability breaks RDMA
On Monday, 20 August 2018 6:32:26 AM AEST Jonathan Engwall wrote: > I am not shocked that my previous message may have been removed. To clarify: nothing has been removed to my knowledge. Your email is in the list archives. http://beowulf.org/pipermail/beowulf/2018-August/035219.html All the best, Chris (just woken up) -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC ___ Beowulf mailing list, Beowulf@beowulf.org sponsored by Penguin Computing To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
Re: [Beowulf] RHEL7 kernel update for L1TF vulnerability breaks RDMA
Dear all, whereas I am accepting that no system is 100% secure ans bug-free, I am beginning to wonder whether the current problems we are having are actually design flaws and whether, and that is the more important bit, Intel and other vendors did know about it. I am thinking of the famous 'diesel-engine' scandal and, continuing this line of thought, dragging the vendors into the limelight and get them to pay for this. I mean, we have to sort out the mess the company was making in the first place, have to judge whether to apply a patch which might decrease the performance of our systems (I am doing HPC, hence my InfiniBand question) versus security. Where will it stop? Given the current and previous 'bugs' are clearly design flaws IMHO, what are the chances of a law suite? The any compensation here should go to Open Source projects, in my opinion, which are making software more secure. Any comments here? All the best Jörg Am Sonntag, 19. August 2018, 06:11:16 BST schrieb John Hearns via Beowulf: > Rather more seriously, this is a topic which is well worth discussing, > What are best practices on patching HPC systems? > Perhaps we need a separate thread here. > > I will throw in one thought, which I honestly do not want to see happening. > I recently took a trip to Bletchley Park in the UK. On display there was an > IBM punch card machine and sample punch cards Back in the day one prepared > a 'job deck' which was collected by an operator in a metal hopper then > wheeled off to the mainframe. You did not ever touch the mainframe. So > effectively an air gapped system. A system like that would in these days > kill productivity. > However should there be 'virus checking' of executables before they are > run on compute nodes. > One of the advantages lauded for Linux systems is of course that anti-virus > programs are not needed. > > Also I should ask - in the jargon of anti-virus is there a 'signature' for > any of these exploit codes? One would guess that bad actors copy the > example codes already published and use these almost in a cut and paste > fashion. So the signature would be tight loops repeatedly reading or > writing to the same memory locations. Can that be distinguished from > innocent code? > > On Sun, 19 Aug 2018 at 05:59, John Hearns wrote: > > *To patch, or not to patch, that is the question:* Whether 'tis nobler in > > the mind to suffer > > The loops and branches of speculative execution, > > Or to take arms against a sea of exploits > > And by opposing end them. To die—to sleep, > > No more; and by a sleep to say we end > > The heart-ache and the thousand natural shocks > > That HPC is heir to: 'tis a consummation > > Devoutly to be wish'd. To die, to sleep > > > > On Sun, 19 Aug 2018 at 02:31, Chris Samuel wrote: > >> On Sunday, 19 August 2018 5:19:07 AM AEST Jeff Johnson wrote: > >> > With the spate of security flaws over the past year and the impacts > >> > >> their > >> > >> > fixes have on performance and functionality it might be worthwhile to > >> > >> just > >> > >> > run airgapped. > >> > >> For me none of the HPC systems I've been involved with here in Australia > >> would > >> have had that option. Virtually all have external users and/or reliance > >> on > >> external data for some of the work they are used for (and the sysadmins > >> don't > >> usually have control over the projects & people who get to use them). > >> > >> All the best, > >> Chris > >> -- > >> > >> Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC > >> > >> ___ > >> Beowulf mailing list, Beowulf@beowulf.org sponsored by Penguin Computing > >> To change your subscription (digest mode or unsubscribe) visit > >> http://www.beowulf.org/mailman/listinfo/beowulf ___ Beowulf mailing list, Beowulf@beowulf.org sponsored by Penguin Computing To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
Re: [Beowulf] RHEL7 kernel update for L1TF vulnerability breaks RDMA
As far as vulnerabilities go, here is a terrible idea: Write a little login patch that grabs your own email address and uses it to attempt to login to Facebook without a password 1000 times per second. Kill the script after two seconds. You want to read the Facebook head first so you can kick all the noise to /dev/null. It is brute force based on a query. On August 18, 2018, at 10:12 PM, John Hearns via Beowulf wrote: Rather more seriously, this is a topic which is well worth discussing, What are best practices on patching HPC systems? Perhaps we need a separate thread here. I will throw in one thought, which I honestly do not want to see happening. I recently took a trip to Bletchley Park in the UK. On display there was an IBM punch card machine and sample punch cards Back in the day one prepared a 'job deck' which was collected by an operator in a metal hopper then wheeled off to the mainframe. You did not ever touch the mainframe. So effectively an air gapped system. A system like that would in these days kill productivity. However should there be 'virus checking' of executables before they are run on compute nodes. One of the advantages lauded for Linux systems is of course that anti-virus programs are not needed. Also I should ask - in the jargon of anti-virus is there a 'signature' for any of these exploit codes? One would guess that bad actors copy the example codes already published and use these almost in a cut and paste fashion. So the signature would be tight loops repeatedly reading or writing to the same memory locations. Can that be distinguished from innocent code? On Sun, 19 Aug 2018 at 05:59, John Hearns wrote: To patch, or not to patch, that is the question: Whether 'tis nobler in the mind to suffer The loops and branches of speculative execution, Or to take arms against a sea of exploits And by opposing end them. To die—to sleep, No more; and by a sleep to say we end The heart-ache and the thousand natural shocks That HPC is heir to: 'tis a consummation Devoutly to be wish'd. To die, to sleep On Sun, 19 Aug 2018 at 02:31, Chris Samuel wrote: On Sunday, 19 August 2018 5:19:07 AM AEST Jeff Johnson wrote: > With the spate of security flaws over the past year and the impacts their > fixes have on performance and functionality it might be worthwhile to just > run airgapped. For me none of the HPC systems I've been involved with here in Australia would have had that option. Virtually all have external users and/or reliance on external data for some of the work they are used for (and the sysadmins don't usually have control over the projects & people who get to use them). All the best, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC ___ Beowulf mailing list, Beowulf@beowulf.org sponsored by Penguin Computing To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf ___ Beowulf mailing list, Beowulf@beowulf.org sponsored by Penguin Computing To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
