Re: [Interest] good-compromise compatibility setting for -march=??? option (x86)?
On Monday, 20 July 2020 21:50:45 PDT Rainer Wiesenfarth wrote: > René would like to know how to set "march" when he *compiles code on* the > Celeron (N3150) that should *run on* the (probably first generation) Core > i7 mobile. Oh? I had not understood that. But I was wondering why he was asking about i7... there's no Atom that is marketed as i7. Let me reread... Sorry, I was confused then! René is looking for the maximum common denominator between a Silvermont and a SandyBridge. From some work I've been preparing to send to Qt: # Architecture Based onNew features # Core line arch=Core2 x86_64 sse3,ssse3,cx16 arch=NHMCore2 sse4.1,sse4.2,popcnt arch=WSMNHM arch=SNBWSM avx arch=IVBSNB f16c,rdrnd,fsgsbase arch=HSWIVB avx2,fma,bmi,bmi2,lzcnt,movbe arch=BDWHSW adx,rdseed [...] # Atom line arch=SLMWSM rdrnd,movbe arch=GLMSLM fsgsbase,rdseed,lzcnt,xsavec,xsaves So the common denominator of SLM and SNB is the WSM (Westmere). Not coincidentally, it's the default -march= for GCC and Clang on Clear Linux, as well as what all binaries in /usr/bin and /usr/lib64 are compiled towards. Other combinations may not match an exact CPU, like: SLM & IVB = WSM + rdrnd SLM & HSW = SLM GLM & HSW = SLM + fsgsbase GLM & BDW = SLM + fsgsbase + rdseed -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] good-compromise compatibility setting for -march=??? option (x86)?
Addendum: According to https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html, "-march=nehalem" or "-march=sandybridge" should do the trick. Both do not have RDRND instruction set support, as René already noted. Cheers, Rainer On Tue, Jul 21, 2020 at 6:50 AM Rainer Wiesenfarth < rainer_wiesenfa...@trimble.com> wrote: > Sorry for jumping into your discussion, but I think you are talking about > different topics. > > René would like to know how to set "march" when he *compiles code on* the > Celeron (N3150) that should *run on* the (probably first generation) Core > i7 mobile. > > Thiago says that "march=native" produces code that is guaranteed to run on > the *same architecture.* > > My guess would be that René has to set "march" to what the i7 supports, > using sde64 searching for Nehalem or - eventually - Sandy Bridge. As I am > on AMD and Windows, it might be Thiago's part to provide the sde64 > information... :-) > > Cheers, Rainer > > -- > Software Engineer | Trimble Imaging Division > Rotebühlstraße 81 | 70178 Stuttgart | Germany > Office +49 711 22881 0 | Fax +49 711 22881 11 > http://www.trimble.com/imaging/ | http://www.inpho.de/ > > Trimble Germany GmbH, Am Prime Parc 11, 65479 Raunheim > Eingetragen beim Amtsgericht Darmstadt unter HRB 83893, > Geschäftsführer: Rob Reeder, Jürgen Kesper > -- Software Engineer | Trimble Imaging Division Rotebühlstraße 81 | 70178 Stuttgart | Germany Office +49 711 22881 0 | Fax +49 711 22881 11 http://www.trimble.com/imaging/ | http://www.inpho.de/ Trimble Germany GmbH, Am Prime Parc 11, 65479 Raunheim Eingetragen beim Amtsgericht Darmstadt unter HRB 83893, Geschäftsführer: Rob Reeder, Jürgen Kesper ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] good-compromise compatibility setting for -march=??? option (x86)?
Sorry for jumping into your discussion, but I think you are talking about different topics. René would like to know how to set "march" when he *compiles code on* the Celeron (N3150) that should *run on* the (probably first generation) Core i7 mobile. Thiago says that "march=native" produces code that is guaranteed to run on the *same architecture.* My guess would be that René has to set "march" to what the i7 supports, using sde64 searching for Nehalem or - eventually - Sandy Bridge. As I am on AMD and Windows, it might be Thiago's part to provide the sde64 information... :-) Cheers, Rainer -- Software Engineer | Trimble Imaging Division Rotebühlstraße 81 | 70178 Stuttgart | Germany Office +49 711 22881 0 | Fax +49 711 22881 11 http://www.trimble.com/imaging/ | http://www.inpho.de/ Trimble Germany GmbH, Am Prime Parc 11, 65479 Raunheim Eingetragen beim Amtsgericht Darmstadt unter HRB 83893, Geschäftsführer: Rob Reeder, Jürgen Kesper ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] good-compromise compatibility setting for -march=??? option (x86)?
On Monday, 20 July 2020 14:56:24 PDT René J.V. Bertin wrote: > Thanks, will try though > [https://en.wikichip.org/wiki/intel/microarchitectures/silvermont] suggests > that Silvermont has the rdrand instruction that my i7 doesn't have. It's supposed to have: $ sde64 --help | grep Silvermont -slmSet chip-check and CPUID for Intel(R) Silvermont CPU $ sde64 -slm -- cpuid -1 --leaf=1 | grep RDRAND RDRAND instruction = true [http://www.intel.com/software/sde] But some CPU features relating to crypto are sometimes disabled, either on BIOS or on particular SKUs. So far, I'd only heard about the AES and PCLMULQDQ[*] instructions, but I suppose RDRAND and RDSEED fit into that category, as will the SHA, VAES and VPCLMULQDQ instructions. To fix a Qt build, you can always append -mno-rdrnd to the build options. This will disable the unconditional use of RDRAND in qrandom.cpp. GCC's -march=native should use the feature set coming from your CPUID instruction. So it should not enable RDRAND if your CPU doesn't report it. That means -march=native may result in a feature set that matches none of the other -march= options. You can check like this: gcc -dM -E -march=native -xc /dev/null | grep RDRND That does not apply to Clang. Clang's -march=native tries to find the best match to your processor and then enables that particular entry. That means it could enable features your processor doesn't have. If that's the case, please report a bug. I had to fix both GCC and Clang on the AES instructions. We may need to do the same for RDRAND. [*] pronounced "pickle-muckle-duck" -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] good-compromise compatibility setting for -march=??? option (x86)?
On Saturday July 18 2020 10:20:44 Thiago Macieira wrote: >That's a Braswell-based Atom: Or rather a Celeron (whatever the exact difference is)? https://en.wikichip.org/wiki/intel/celeron/n3150 >So -march=silvermont. Thanks, will try though [https://en.wikichip.org/wiki/intel/microarchitectures/silvermont] suggests that Silvermont has the rdrand instruction that my i7 doesn't have. > >Anyway, -march=native is supposed to work on any machine that runs the code it >compiled. If that fails, Of course it does, and no, it doesn't. R ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] wss:// on localhost
I could never get wss: working on the mobile platforms, despite being able to get https working. a) you need these for SSL to work. You could generate them and set peer verify to off, but I don't know how to do it without a certificate. b) You can't (generally speaking) do ws and wss at the same time. It follows http/https semantics, as it starts as HTTP and negotiates the protocol change to WebSocket. The encruption happens even before that - it is already assumed to be encrypted or not, though it is possible to have a plaintext http socket upgrade to a https socket (mixed mode), but no one does that. Instead the protocol/port combo gives the client the information on how to start talking to the server in the right way. I will speculate that this is done rather than have a mixed-mode socket so if you come in with the intent of being encrypted and are not, that is considered a hard fail. Same applies for unencrypted. Mixed mode only gives you additional ambiguity, potential leakage of data intended to be secure but isn't. So there isn't a large reason to support both on the same socket, and ports to bind to are not in short supply. > Sent: Sunday, July 19, 2020 at 12:50 PM > From: "Alexander Carôt" > To: "qt qt" > Subject: [Interest] wss:// on localhost > > Hello all, > > after having fixed my QWebsocketServer issue I ran into another problem: > > Beside my properly working SSL websocket I have another websocket which > serves as the technical interface between my website and a Qt application > required for the service. > > This websocket used to work insecure (ws://) and now I am as well trying to > run it in secure mode (ws://), however, I wonder if also in this case I need > an extra certificate. Furthermore, I wonder if afer deployment this implies > that users would also need a dedicated certificate (which would be be > acceptable in terms of usability). > > Alternatively I could run the application websocket insecure (ws://) but it > semms that some web browsers dislike the mixture of ws:// and wss:// for some > reason although the main site is run via https:// and ws:// the downgrade > should not be a problem. > > Can anyone tell if > > a) there is way to get rid of certificates on localhost despite using wss:// > b) there is a reliable way of having ws:// and wss:// at the same time > > Thanks a lot in advance, > best > > Alex > > > -- > http://www.carot.de > Email : alexan...@carot.de > Tel.: +49 (0)177 5719797 > > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest > ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] wss:// on localhost
On Monday, 20 July 2020 01:57:31 PDT Alexander Carôt wrote: > The problem is that my application currently has a daily pageview of > 1000 > and a user base of more than 10.000 - most of the user are non-tech-sage so > I need the most simply solution. I don't see how that affects anything. Are you saying you can't update the application? If you can't update the application, how are you going to apply the fixes we're discussing here? If you meant that they aren't able to generate the certificate, let me clarify that I meant the application should do that automatically. There needs to be no user interaction. The certificate is just something that the WebSocket client and server agree upon before start, like the port number. I mentioned "every few months" just so you don't incur the penalty of the generation on every start. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Klocwork CWE warnings in Qt5
On Monday, 20 July 2020 00:20:54 PDT Ramakanth Kesireddy wrote: > However, if we need to submit any fixes in future, can we submit as part of > Qt bug report for the findings through Klocwork? You can submit issues as bug reports, yes. Fixes shouldn't be submitted in the bug report, unless they're very small. Use the contribution model instead. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] wss:// on localhost
> > a) there is way to get rid of certificates on localhost despite using wss:// > > Yes, but then it's no better security than ws://. So either use insecure or > use a certificate. I see, however, I really don't care about security at this point because this is a localhost connection anyways. It's just that because of the other wss-based websocket it would be ideal to run the localhost websocket with wss as well. So - in front of that background it would be the ideal solution in combination with non-existing certificates. It would be great if you'd send me a pointer how to approach this. > What you can do is generate a certificate every couple of months, in each > machine that uses your application. Make the client use that certificate as > the only entry in the CA list, so it will accept the certificate from the > server without prompting a warning. The problem is that my application currently has a daily pageview of > 1000 and a user base of more than 10.000 - most of the user are non-tech-sage so I need the most simply solution. Thanks and best Alex -- http://www.carot.de Email : alexan...@carot.de Tel.: +49 (0)177 5719797 > Gesendet: Sonntag, 19. Juli 2020 um 20:41 Uhr > Von: "Thiago Macieira" > An: interest@qt-project.org > Betreff: Re: [Interest] wss:// on localhost > > On Sunday, 19 July 2020 09:50:03 PDT Alexander Carôt wrote: > > a) there is way to get rid of certificates on localhost despite using wss:// > > Yes, but then it's no better security than ws://. So either use insecure or > use a certificate. > > > b) there is a reliable way of having ws:// and wss:// at the same time > > Sorry, I don't know. > > What you can do is generate a certificate every couple of months, in each > machine that uses your application. Make the client use that certificate as > the only entry in the CA list, so it will accept the certificate from the > server without prompting a warning. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel System Software Products > > > > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest > ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Klocwork CWE warnings in Qt5
Thanks for your email.
We did review the klocwork warnings and found to be ignored.
However, if we need to submit any fixes in future, can we submit as part of
Qt bug report for the findings through Klocwork?
Best Regards,
Ramakanth
On Mon, 20 Jul, 2020, 00:18 Thiago Macieira,
wrote:
> On Sunday, 19 July 2020 09:35:20 PDT Ramakanth Kesireddy wrote:
> > Hi,
> >
> > There are 5 different CWEs of the below type thrown by Klocwork as
> warnings
> > in the below mentioned condition in findNext():-
> >
> > https://code.woboq.org/qt5/include/qt/QtCore/qiterator.h.html#144
> > inline bool findNext(const T ) \
> > { while (const_iterator(n = i) != c->constEnd()) if (*i++ == t)
> return
> > true; return false; } \
>
> > CWE-480:Use of Incorrect Operator
> > http://cwe.mitre.org/data/definitions/480.html
>
> The use of i++ is intentional and correct.
>
> > CWE-481:Assigning instead of Comparing
> > http://cwe.mitre.org/data/definitions/481.html
>
> The assignment of n = i is intentional and correct.
>
> > EXP45-C. Do not perform assignments in selection statements
> > https://www.securecoding.cert.org/confluence/x/nYFtAg
>
> Yes, the code quality is poor. That's what happens when you want to write
> short code in macros.
>
> > Please let me know if the assignment expression in conditional statements
> > in findNext() could be ignored?
>
> You decided to run a code scanning / static analysis tool on Qt. Please
> get
> your own senior engineers to review the results. If your engineers are
> uncertain, please post a detailed question (not like this email) on the
> exact
> issue and how the code should be fixed.
>
> And please submit the fixes you've needed to make.
>
> Qt is being scanned by a number of tools, including Coverity's public
> scanning
> of open source tools. Known issues are being fixed as quickly as possible.
> The
> latest releases (5.15) have all the fixes.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel System Software Products
>
>
>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
