Friday, May 25, 2018

Digest for comp.lang.c++@googlegroups.com - 14 updates in 6 topics

Juha Nieminen <nospam@thanks.invalid>: May 25 05:24AM

> Spectre, Meltdown et al have become possible because of the desire to
> let the C programmers to continue to falsely believe they are
> programming in a low-level language.
 
That sounds like the most insane non-sequitur ever. Do I even want to
read that article?
Paavo Helde <myfirstname@osa.pri.ee>: May 25 05:19PM +0300

On 25.05.2018 8:24, Juha Nieminen wrote:
>> programming in a low-level language.
 
> That sounds like the most insane non-sequitur ever. Do I even want to
> read that article?
 
I don't really agree with the author's claim but he has some point and I
found the article quite interesting.
Melzzzzz <Melzzzzz@zzzzz.com>: May 25 02:38PM

>> read that article?
 
> I don't really agree with the author's claim but he has some point and I
> found the article quite interesting.
 
Whole article has false premise that CPU's are designed to accommodate
C... spectre and meltdown does not have to do anything with C.
 
 
--
press any key to continue or any other to quit...
scott@slp53.sl.home (Scott Lurndal): May 25 03:05PM

>> programming in a low-level language.
 
>That sounds like the most insane non-sequitur ever. Do I even want to
>read that article?
 
No. His basic premise (that Spectre/Meltdown have anything to do with
C) is wrong.
Marcel Mueller <news.5.maazl@spamgourmet.org>: May 25 07:41PM +0200

On 24.05.18 14.54, Scott Lurndal wrote:
> Spectre, Meltdown are simply microarchitectural bugs. Speculative
> execution should never cause detectable effects, particularly over
> privilege boundaries.
 
It is almost impossible to prevent side channel attacks completely.
/This/ type of attacks might be fixed at some time but others will
arise. Maybe someone detects EM emissions using the built in magnetic
compass sensor, maybe the embedded sensors of modern power supplies
compromises encryption algorithms, maybe something completely different,
but it is pretty sure that there always will be successful side channel
attacks.
 
Part of the story is the performance overkill of many devices. It makes
it possible to detect even information with a very bad SNR just by using
many repetitions. This applies for instance to row hammer as well as to
Spectre.
 
 
Marcel
Vir Campestris <vir.campestris@invalid.invalid>: May 25 09:25PM +0100

On 25/05/2018 16:05, Scott Lurndal wrote:
> No. His basic premise (that Spectre/Meltdown have anything to do with
> C) is wrong.
 
His basic premise is that C encourages single threaded programming.
(which is of course true of most languages, and I think all of that
vintage).
 
Given that there will not be many threads each individual thread must
run at the highest possible speed. Which requires caches, pipelines, and
all that gubbins, which is where the side channel attacks come in.
 
Only trouble is I've only worked on one processor which isn't like that.
SIMD, multiple threads. And a pipeline (though much shorter) and a cache
(which apart from anything works because of locality of reference, which
is nothing to do with single threaded languages).
 
Thing is though - if you've had an exception trying to access a kernel
page - why not flush the cache? It won't happen often, and bye-bye all
that side channel stuff.
 
Andy
Melzzzzz <Melzzzzz@zzzzz.com>: May 25 08:33PM

>> No. His basic premise (that Spectre/Meltdown have anything to do with
>> C) is wrong.
 
> His basic premise is that C encourages single threaded programming.
That is wrong, too.
 
 
> Given that there will not be many threads each individual thread must
> run at the highest possible speed. Which requires caches, pipelines, and
> all that gubbins, which is where the side channel attacks come in.
 
This is funny. CPU is designed to run as fast as possible i no matter
language. More so for slow and bloated languages then C.
 
--
press any key to continue or any other to quit...
Chris Ahlstrom <OFeem1987@teleworm.us>: May 25 04:20PM -0400

Melzzzzz wrote this copyrighted missive and expects royalties:
 
>> found the article quite interesting.
 
> Whole article has false premise that CPU's are designed to accommodate
> C... spectre and meltdown does not have to do anything with C.
 
C was designed to accomodate the PDP-11 (I think) instruction set.
 
--
Q: Why should you always serve a Southern Carolina football man
soup in a plate?
A: 'Cause if you give him a bowl, he'll throw it away.
scott@slp53.sl.home (Scott Lurndal): May 25 09:30PM


>Thing is though - if you've had an exception trying to access a kernel
>page - why not flush the cache? It won't happen often, and bye-bye all
>that side channel stuff.
 
flushing the cache is a side effect of the exception, thus a covert
channel - useful to determine valid kernel addresses, for example.
andrei@erdani.com: May 25 08:16AM -0700

Hi everyone and thanks Brian for bringing this to my attention.
 
Clearly the time-honored notion of "a value or the absence thereof" has many good uses, many of which distinct from "a value of any type whatsoever" or "a value of a known set of types". So nothing wrong with having and using each of the above where applicable.
 
My remark about std::optional has to do with it having introduced (for the first time in std) the pointer syntax for a non-pointer value. That is questionable in and of itself - are we really after more undefined behavior in standard library APIs? -, but the worst of it is it has created a precedent - now new loosely-related artifacts (such as of course std::expected) need to integrate the pointer syntax as well, or carefully justify not doing so.
Sky89 <Sky89@sky68.com>: May 25 10:28AM -0400

Hello...
 
 
I have thought more about C++, and I think C++ is really powerful
because STL vectors perform bounds checking when the .at() member
function is called, but do not perform any checks on the [] operator
when out of bounds, the [] operator produces undefined results,
and for integer overflow or underflow or more efficient strict-type
safety, here is how to do it with SafeInt here:
 
https://github.com/dcleblanc/SafeInt
 
 
I have just written the following program using SafeInt, please look at
it and try it to notice that C++ is powerful:
 
===
 
#include "SafeInt.hpp"
using namespace std;
#include <climits>
#include <iostream>
#include <sstream>
#include <stdexcept>
 
class my_exception : public std::runtime_error {
std::string msg;
public:
my_exception(const std::string &arg, const char *file, int line) :
std::runtime_error(arg) {
std::ostringstream o;
o << file << ":" << line << ": " << arg;
msg = o.str();
}
~my_exception() throw() {}
const char *what() const throw() {
return msg.c_str();
}
};
 
#define throw_line(arg) throw my_exception(arg, __FILE__, \
__LINE__);
 
 
class CMySafeIntException : public SafeIntException
{
public:
static void SafeIntOnOverflow()
{
cout << "Caught a SafeInt Overflow exception!" << endl;
throw_line("SafeInt exception");
}
static void SafeIntOnDivZero()
{
cout << "Caught a SafeInt Divide By Zero exception!" << endl;
throw_line("SafeInt exception");
}
};
 
void a1(SafeInt<unsigned __int8, CMySafeIntException> a)
{
 
cout << (int)a << endl;
}
 
int main()
{
try {
 
//throw std::invalid_argument("exception");
 
unsigned __int8 i1 = 250;
unsigned __int8 i2 = 150;
SafeInt<unsigned __int8, CMySafeIntException> si1(i1);
SafeInt<unsigned __int8, CMySafeIntException> si2(i2);
SafeInt<unsigned __int8, CMySafeIntException> siResult = si1 + si2;
cout << (int)siResult << endl;
 
 
a1(-1);
 
}
catch (const std::runtime_error &ex) {
std::cout << ex.what() << std::endl;
}
//catch (const std::invalid_argument &ex) {
// std::cout << ex.what() << std::endl;
// }
 
 
}
 
 
====
 
So as you have noticed C++ is great !
 
 
 
Thank you,
Amine Moulay Ramdane.
Sky89 <Sky89@sky68.com>: May 25 10:16AM -0400

Hello...
 
 
I have thought more about C++, and I think C++ is really powerful
because STL vectors perform bounds checking when the .at() member
function is called, but do not perform any checks on the [] operator
when out of bounds, the [] operator produces undefined results,
and for integer overflow or more efficient strict-type safety, here
is how to do it with SafeInt here:
 
https://github.com/dcleblanc/SafeInt
 
 
I have just written the following program using SafeInt, please look at
it and try it to notice that C++ is powerful:
 
===
 
#include "SafeInt.hpp"
using namespace std;
#include <climits>
#include <iostream>
#include <sstream>
#include <stdexcept>
 
class my_exception : public std::runtime_error {
std::string msg;
public:
my_exception(const std::string &arg, const char *file, int line) :
std::runtime_error(arg) {
std::ostringstream o;
o << file << ":" << line << ": " << arg;
msg = o.str();
}
~my_exception() throw() {}
const char *what() const throw() {
return msg.c_str();
}
};
 
#define throw_line(arg) throw my_exception(arg, __FILE__, \
__LINE__);
 
 
class CMySafeIntException : public SafeIntException
{
public:
static void SafeIntOnOverflow()
{
cout << "Caught a SafeInt Overflow exception!" << endl;
throw_line("SafeInt exception");
}
static void SafeIntOnDivZero()
{
cout << "Caught a SafeInt Divide By Zero exception!" << endl;
throw_line("SafeInt exception");
}
};
 
void a1(SafeInt<unsigned __int8, CMySafeIntException> a)
{
 
cout << (int)a << endl;
}
 
int main()
{
try {
 
//throw std::invalid_argument("exception");
 
unsigned __int8 i1 = 250;
unsigned __int8 i2 = 150;
SafeInt<unsigned __int8, CMySafeIntException> si1(i1);
SafeInt<unsigned __int8, CMySafeIntException> si2(i2);
SafeInt<unsigned __int8, CMySafeIntException> siResult = si1 + si2;
cout << (int)siResult << endl;
 
 
a1(-1);
 
}
catch (const std::runtime_error &ex) {
std::cout << ex.what() << std::endl;
}
//catch (const std::invalid_argument &ex) {
// std::cout << ex.what() << std::endl;
// }
 
 
}
 
 
====
 
So as you have nmoticed C++ is great !
 
 
 
Thank you,
Amine Moulay Ramdane.
Juha Nieminen <nospam@thanks.invalid>: May 25 05:21AM

> };
 
> static constexpr Bas t5();
> };
 
That's not a static member. It's a static function declaration.
Lynn McGuire <lynnmcguire5@gmail.com>: May 24 08:26PM -0500

"Stupid C++ namespace tricks" by Raymond Chen
https://blogs.msdn.microsoft.com/oldnewthing/20180516-00/?p=98765
 
Hat tip to:

https://www.codeproject.com/script/Mailouts/View.aspx?mlid=13634&_z=1988477
 
Lynn
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)