search for: sidechannel

...I think that the lack of bitcode support will prevent it. During the Developers meeting, I also talked with Hal and Johannes. They had some extra remarks: - (1) the restrict implementation deserves a separate document. (I am working on that one) - (2) they don't like the naming of 'noalias_sidechannel'. - (3) they also have some other mechanisms in mind to add the 'sidechannel' to the load/store instructions (and maybe to function calls, intrinsics; currently that is handled through llvm.noalias.arg.guard) For (2) and (3), I am waiting for a proposal from them ;) Greetings,...

...it. > > > > During the Developers meeting, I also talked with Hal and Johannes. > > They had some extra remarks: > > - (1) the restrict implementation deserves a separate document. (I am > working on that one) > > - (2) they don't like the naming of 'noalias_sidechannel'. > > - (3) they also have some other mechanisms in mind to add the 'sidechannel' > to the load/store instructions > > (and maybe to function calls, intrinsics; currently that is handled through > llvm.noalias.arg.guard) > > > > For (2) and (3), I am...

...it. > > > > During the Developers meeting, I also talked with Hal and Johannes. > > They had some extra remarks: > > - (1) the restrict implementation deserves a separate document. (I am > working on that one) > > - (2) they don't like the naming of 'noalias_sidechannel'. > > - (3) they also have some other mechanisms in mind to add the 'sidechannel' > to the load/store instructions > > (and maybe to function calls, intrinsics; currently that is handled through > llvm.noalias.arg.guard) > > > > For (2) and (3), I am...

...it. > > > > During the Developers meeting, I also talked with Hal and Johannes. > > They had some extra remarks: > > - (1) the restrict implementation deserves a separate document. (I am > working on that one) > > - (2) they don't like the naming of 'noalias_sidechannel'. > > - (3) they also have some other mechanisms in mind to add the 'sidechannel' > to the load/store instructions > > (and maybe to function calls, intrinsics; currently that is handled through > llvm.noalias.arg.guard) > > > > For (2) and (3), I am...

...it. > > > > During the Developers meeting, I also talked with Hal and Johannes. > > They had some extra remarks: > > - (1) the restrict implementation deserves a separate document. (I am > working on that one) > > - (2) they don't like the naming of 'noalias_sidechannel'. > > - (3) they also have some other mechanisms in mind to add the 'sidechannel' > to the load/store instructions > > (and maybe to function calls, intrinsics; currently that is handled through > llvm.noalias.arg.guard) > > > > For (2) and (3), I am waitin...

.../mitigate some of the scalability challenges associated with the pure-metadata solution. * The full-restrict implementation is being used, and Jerone is currently updating this implementation based on feedback from that usage, he also will update the implementation to use provenance instead of sidechannel and repost. * Johannes notes that we need more reviewers for this patch set. **** Thanks again, Hal Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory ________________________________ From: llvm-dev <llvm-dev-bounces...

...g the 'operator new' to always allocate for 2(load)/3(store) operands. Also OperandTraits of StoreInst must be modfied as we now have an optional operand. For the LoadInst, we also need to introduce an OperandTraits, to overrule the 'UnaryInstruction' one. 4) Introduce a StoreWithSideChannelInst/LoadWithSideChannelInst that inherits from StoreInst/LoadInst, together with its appropriate OperandTraits. This makes it harder to add/remove sidechannel information. Thanks, Jeroen Dobbelaere

Hi Alexey, Adding llvm-ir bitcode support means adding/adapting the tags for LOAD/STORE instructions and adding the support for the noalias_sidechannel at the right places. I had a short attempt to implement it when preparing the public patches, but I am not familiar with that part of the llvm code. When I noticed that it would take a lot longer than anticipated, I postponed it. Also because it is likely that the way how the noalias_sidechannel w...

...low is a summary of changes. More detail may be found in the ChangeLog in the portable OpenSSH tarballs. Thanks to the many people who contributed to this release. Security ======== * ssh(1), sshd(8), ssh-agent(1): add protection for private keys at rest in RAM against speculation and memory sidechannel attacks like Spectre, Meltdown and Rambleed. This release encrypts private keys when they are not in use with a symmetic key that is derived from a relatively large "prekey" consisting of random data (currently 16KB). Attackers must recover the entire prekey before they are ab...