search for: mtls

Hi Devs, consider below testcase $cat test.c __thread int mtls=1; void foo(){ mtls++; } it emits this debug info for mtls 0x0000002a: DW_TAG_variable DW_AT_name ("mtls") DW_AT_type (0x00000035 "int") DW_AT_external (true) DW_AT_decl_file ("test.c")...

...David Blaikie <dblaikie at gmail.com> wrote: > What does GCC do? > > On Mon, Dec 9, 2019 at 10:25 PM kamlesh kumar via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi Devs, >> >> consider below testcase >> $cat test.c >> __thread int mtls=1; >> void foo(){ >> mtls++; >> } >> >> it emits this debug info for mtls >> >> 0x0000002a: DW_TAG_variable >> DW_AT_name ("mtls") >> DW_AT_type (0x00000035 "int") >>...

...d process with limited privileges of the username 'nsd' It would be better, if nsd read all tls-auth client-[cert|key] data before dropping privileges. Then the files could be still limited to be readable by the root user. next question: now, the axfr request from secondary to primary is a mTLS connection. But what about notify messages from primary to secondary? the zone-statement 'notify' does not mention a tls-auth-name Are these notifies still plain, unencrypted, unauthenticated UDP packets? next note: I used an IPv6 network for my zone transfer tests and have the impression,...

...f the username 'nsd' > It would be better, if nsd read all tls-auth client-[cert|key] data > before dropping privileges. > Then the files could be still limited to be readable by the root > user. > > next question: > now, the axfr request from secondary to primary is a mTLS connection. > But what about notify messages > from primary to secondary? the zone-statement 'notify' does not > mention a tls-auth-name > Are these notifies still plain, unencrypted, unauthenticated UDP > packets? > > next note: > I used an IPv6 network for my zone...

...-std=c++11' '-I' '/home/emitrax/programming/adok/build/include/private' '-I' '/home/emitrax/programming/adok/include/private' '-c' '-o' 'source/porting/arch/arm/cortex-m3/stack.cpp.o' '-shared-libgcc' '-march=armv5te' '-mtls-dialect=gnu' '-D' '__CS_SOURCERYGXX_MAJ__=2012' '-D' '__CS_SOURCERYGXX_MIN__=3' '-D' '__CS_SOURCERYGXX_REV__=57' Any suggestions? Regards, S.

On Wed, Jul 18, 2012 at 5:45 PM, Renato Golin <rengolin at systemcall.org> wrote: > On 18 July 2012 15:46, salvatore benedetto > <salvatore.benedetto at gmail.com> wrote: >> $ clang++ -ccc-host-triple thumbv7m-none-gnueabi noInclude.cpp -c >> --sysroot=/home/emitrax/CodeSourcery/Sourcery_G++_Lite/arm-none-linux-gnueabi/libc/ > > Try -ccc-gcc-name

Hi, NSD 4.10.1rc2 pre-release is available: https://nlnetlabs.nl/downloads/nsd/nsd-4.10.1rc2.tar.gz sha256 ce2e82bc673aeff3a71aeb422fa38fb8db0a591edb76c13b0e4dde83ec8253e9 pgp https://nlnetlabs.nl/downloads/nsd/nsd-4.10.1rc2.tar.gz.asc Version 4.10.1 consists primarily of bug fixes. @bilias implemented mutual TLS authentication for zone transfers. Please consult the nsd.conf manual for details

On 18 July 2012 15:46, salvatore benedetto <salvatore.benedetto at gmail.com> wrote: > $ clang++ -ccc-host-triple thumbv7m-none-gnueabi noInclude.cpp -c > --sysroot=/home/emitrax/CodeSourcery/Sourcery_G++_Lite/arm-none-linux-gnueabi/libc/ Try -ccc-gcc-name arm-none-linux-gnueabi-g++ -ccc-host-triple thumbv7m-none-linux-gnueabi Sometimes it's better than sysroot, as it finds it

tl;dr: TLSDESC have solved most problems in formerly inefficient TLS access models, so I think we can drop TLS relaxation support from lld. lld's code to handle relocations is a mess; the code consists of a lot of cascading "if"s and needs a lot of prior knowledge to understand what it is doing. Honestly it is head-scratching and needs serious refactoring. I'm trying to simplify

...read the code, without sacrificing > > performance of lld-generated files in practice. > > > > Thoughts? > > I don't think we can do it. > > The main thing we have to keep in mind is that not everyone is using > TLSDESC. In fact, clang doesn't even support -mtls-dialect=gnu2. > Oh, okay, that is a surprise to me. There's no reason not to support that and make it default, I wasn't even try that. We definitely should support that. If everyone switches to TLSDESC, then I am OK with dropping > optimizations for the old model. > > But even...